Hacker News Reader

Comment by untog | Hacker News Reader

it's difficult to use it for anything serious without investing a lot of time into it.

Isn't that true for many platforms?

Either way, I have multiple apps running Node in production, and I've never had the issues described. You don't have to be as breakneck as Node itself - some things I have are still running v0.10x just fine.

View on HN

I use Java/Spring, Ruby, and Node.js in production, and Node.js is by far the hardest to stay up to date with without introducing major problems. The only framework I have used that is harder to update is Finagle.

It's not just Node itself to blame. There seems to be a culture of breaking things in the Node.js ecosystem. Breaking changes in third-party libraries are common. I have to specify exact dependency versions in my package.json, and almost every time I update one of them, something goes wrong.

have to specify exact dependency versions in my package.json, and almost every time I update one of them, something goes wrong.

That's where semantic versioning comes in. Most libraries follow it - if the major version number changes, it's a breaking change. If it doesn't, you're safe to upgrade.

Semantic version doesn't solve compatibility problems, it just makes it more transparent. In some ways semver encourages breaking changes that otherwise might be avoided because, how, a major version bump gives you sufficient warning.

There are some major libraries that are on version 15 or greater... there's nothing good from a user's perspective about having a library they use do a major breaking release every other month.

What's worse is many libraries take advantage of "it's the wild west until 1.0" rule in semver and simple never release a 1.0.

In my experience, Ruby (particularly rubygems) is quite a pain in the ass with regard to package upgrades, especially when the previous developer/ops has leveraged rvm to install multiple combinations of ruby/gem versions. I can't tell you how many times I've had to trace down problems in a project because a single gem fails to upgrade/pull/compile/resolve on 2 out of 4 machines even though the project has an identical gemfile and available ruby version on every server.

I contrast this with node/npm where my projects seem to behave identically across deployments (and in some cases, when in a bind, I've even been able to simply tar & scp the project src and have it run without further effort beyond installing node, something I've never been able to do with ruby).

Identical Gemfile.lock and same OS? Then you shouldn't be having any problems. What kind of errors were you getting?

> Isn't that true for many platforms?

I would say that the ROI is lower for time spent learning Node. I've found that with all the other languages I've learnt, in a couple of days I've been able to build something useful, leave it running in production and reuse skills learned a year later.

With Node, even the name of the language is not stable! A few weeks back I went to install Zombie, and now I have to install iojs and not Node. Assumedly it's now Node again. If you live and breathe the language, subscribe to the mailing lists, go to the meetups, etc, these things might be obvious. But when you're just dipping in and out, it really dents your confidence in the language.

Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack).

I'd agree with your first paragraph in that Node is a bit lower-level out of the box and probably takes more effort to get started building a web-app, but I think the time invested jumping in at that low-level is actually useful vs diving in at a higher 'framework level' with some of the other popular web languages.

Also it does have superior installer/package-manager/deployment stories compared to say ... Python & Django, which does have an impact on ROI.

> Your latter paragraph seems a bit fuddy as people 'just dipping in and out' would never have to have contended with the iojs 'name' any more than Python/Ruby/PHP people have to switch to a different VM every time one is announced (e.g. PyPy/Rubinius/Hack).

One of my main use cases for Node is Zombie, and that required io.js after v3. No mainstream PHP, Ruby or Python application has required a different interpreter.

Sounds to me like your issue is with the author of Zombie.

Actually it's with jsdom, Zombie's major dependency which dropped Node support pretty soon after IOjs was released.

That sounds political, more than anything else.

Actually, IIRC it's the exact same reason as the io.js split. The maintainer of jsdom had changes that weren't being merged into node's VM module.

So jsdom 3.x used a lib called "contextify". When io.js was released and the changes included, node support was dropped. Now node 4.0.0 is out and has those changes, jsdom now works on node again.

It was. The maintainer of jsdom decided to no longer support node after 3.x and made the library throw a condescending exception if you tried to run it with node. The docs were also filled with childish "tm" symbols whenever node was mentioned.

I see things like this all the time and it really puts me off OSS.

The io.js situation was more akin to Python 3 vs Python 2 than Python vs PyPy. It might not have looked like a major difference at first glance, but there were notable significant, which came with some breaking under-the-hood changes.

Reply on news.ycombinator.com