NPM is amazing. I used to use Python, which had the right idea with its modules but got so much of the implementation horribly wrong, and it has multiple package managers. Node, however, got modules right. Files and modules are in completely separate namespaces, and npm is a single package manager that "just works". The fact node isn't "batteries included" doesn't matter, because requiring modules is easy and dependencies "just work". You stop worrying about setting up dependencies, so you stop worrying when you want to add another dependency. It's great.
Let's say your application depends on two libraries A and B. And let's say that these 2 libraries depend on different versions of library C. In Maven if library C is not backward compatible, you're stuck. Only one version of library C can exist in the classpath and so one of your 2 libraries might fail. However, in node, library A and B use their corresponding versions of library C. There are no conflicts.
No conflicts, but a tradeoff of loading two versions of library C. I assume at some point, the cost of multiple versions of everything (in terms of memory usage, for example) becomes an issue?
That's the tradeoff, with the crux being that adding more memory for a bit of JIT-compiled bytecode is preferable to having an app that just won't work.
Which is perfectly fine. I mostly want to be able to trivially use packages which solve my trivial problems, so I can move on to something more fun.
The issue eventually becomes a one of search; when I'm looking for a package, how do I know which are maintained, which never picked up broad adoption, etc?
Between the npm registry[1] and node-toolbox[2], there's already decent visibility into it. I often find the output of 'npm search' daunting to the point of mental paralysis, though.
Now, take that observation and go back and read the original post.
I'd observe that the new languages all seem to have been accelerating their rate of package production over time. This is probably because over time the set of easily-copyable packages goes up. It's much easier to release a simple Rails clone after Rails has made the idea popular. It seems like every year there's another Brilliant HTML Templating Idea, and a new language can rapidly develop clones of the entire history of HTML templating ideas, whereas one that was new ten years ago had a much thinner pool of copyable ideas.
This isn't a criticism of Node (which I am certainly prone to, but this is not one of those times), this is an observation that it seems like each new language rapidly builds up packages faster than the last one and this probably isn't actually an attribute of the language.
Do you know of a wicket-like approach to "templating" in python (or indeed anything other than java)? I'm currently in the process of building my own clone in python, and I feel really bad about doing so, but it's so much better than all the approaches to html generation in python that I could find that I'd rather do this than struggle with vanilla django templates, or even genshi.
