Hacker News Reader

Comment by shadowmint | Hacker News Reader

Obviously if Node doesnt come 'batteries included' then you have to re-invent-from-scratch all the tools like package management, dependency management, MVC libraries, etc.

That doesn't mean the community is amazing and wants to contribute! ...it means, that those features didn't exist, and someone had to do them (and yes, it's really great that they're all coming out open source, but it's not revolutionary)

Any language in that situation will have a strong initial growth as people port their favorite toys across.

I'd be much more interested to see the rate of change over-time, year by year.

Is it still growing? Is it slowing down now there are some mature frameworks?

That's interesting stuff. "Changing the face of open source?" --> selfimportantness gasbagging.

View on HN

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.

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.

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.

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.

I like the fact that Node comes with a small core. I'm tired of vast, bloated, incomprehensible libraries that are going to take me more time to learn how to use than they'll be worth.

But because it comes with a small core, the time you saved will be spent searching and learning userland modules, written with wildly varying degrees of stability and coding styles. Unless, of course, you just use your own, then your time has been spent there. Much more of it.

I'm not trying to put node down, I'm a fan (switched to Go for most of my needs about a year ago, though), but this argument (small core so less to understand) just isn't valid if you're going to do anything more involved than learning the language and writing hello worlds.

I'm sure eventually node will have it's very own Tornado/Twisted/Boost/etc that you can then apply to your argument.

Meteor?

Obviously if linux doesn't come "batteries included" then you have to re-invent-from-scratch, or borrow, all the tools like compilers, web servers, package management, archive utilities, etc.

That doesn't mean the community is amazing and wants to contribute! ... it means, that those features didn't exist, and someone had to do them (and yes, it's really great that they're all coming out open source, but it's not revolutionary)

Any OS in that situation will have a strong initial growth as people port their favorite toys across.

I'd be much more interested to see the rate of change over-time, year by year.

...

If you have a point, make it clearly instead of hiding it.

It's pretty obvious. Your criticisms would have been exactly as justified with regard to linux. That doesn't mean node.js is guaranteed to be as wildly successful as linux, but it does mean that merely dismissing it because so much of the work on it is "just porting things" is misplaced.

Oh the sweet irony. This attitude is exactly what I'm talking about.

You're right, node is great. :)

node.js is like any other open source language in this case.

It's not so much like Linux (implied thesis: everyone will be running things on top of node.js like they are run on top of Linux)

So you are saying it is no different than other open source projects?

> you have to re-invent-from-scratch all the tools

If they are in standard library, they must be invented before too! The difference is that there isn't standard solution (hence the name) and anyone can offer his/her own solution to the problem.

Package and dependency management (with npm) are two things that do come included with the node distribution these days. I would also argue that npm is one of the primary reasons why the node ecosystem is thriving in the way that it is.

Reply on news.ycombinator.com