Hacker News Reader

Comment by MetaCosm | Hacker News Reader

I honestly think it might be (changing the face of open source), I am not a part of the node.js community, but I do look at the way NPM works with a bit of jealousy.

Born at the right time, defaulting to the "right" (according to me) license, with the right mix of tools that make it easy to publish and share -- and bluntly I hope other communities (like Erlang, one close to my heart) follow suit.

View on HN

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.

npm publish lets you create something new and share it trivially and in a useful manner.

This might end up being a negative in the long run, but for now it seems like a huge positive.

If it's trivial to create packages, I suspect we'll end up with a lot of trivial packages.

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.

[1]: eg, if I need a redis client, I can see the redis project is active and broadly used: https://npmjs.org/package/redis

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.

Can anybody tell me what NPM does that e.g. Maven / CPAN / Gems e.a. don't?

I haven't seen anything in NPM so far that goes beyond Maven's capabilities so I'm really curious what NPM's big advantage is.

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.

This is amazing. I'm actually surprised NPM is one of the few that gets this right. I guess we are still in the early days of Software engineering.

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.

There is something to be said for requiring developers to make things work right rather than work around their screwups, however.

Reply on news.ycombinator.com