Live data from Hacker News

Node.js 5.0 Released

github.com

91–100 of 132 posts

Re: Node.js 5.0 Released

#91

So there seems to be folks complaining about how fast this release was and other folks saying it's not a big deal because 4.2.x is LTS. But I don't see anyone addressing the actual issue of breaking changes in node: npm. What does a module author do? If my module uses an API that was changed in 5.x, do I only support 4.2.x, do I only support 5.x or do I write in some hacks to try and check between the two? What if 6.…

I dislike they jumped from 0.1x (and io.js) to 4 and a months later the realise v8 semver is 5 and jump to 5 - stupid.

They could have though about version numbers last months, and choose 5.

A bit more conservative version numbering would be great. Nodejs up to 0.1x was to slow, and now it's way to fast - a application runtime is not a browser. Mind the library compatibility - not every dev has time to test for 0.1x, 4.x and now 5.

Re: Node.js 5.0 Released

#92
post #91

So there seems to be folks complaining about how fast this release was and other folks saying it's not a big deal because 4.2.x is LTS. But I don't see anyone addressing the actual issue of breaking changes in node: npm. What does a module author do? If my module uses an API that was changed in 5.x, do I only support 4.2.x, do I only support 5.x or do I write in some hacks to try and check between the two? What if 6.…

I dislike they jumped from 0.1x (and io.js) to 4 and a months later the realise v8 semver is 5 and jump to 5 - stupid. They could have though about version numbers last months, and choose 5. A bit more conservative version numbering would be great. Nodejs up to 0.1x was to slow, and now it's way to fast - a application runtime is not a browser. Mind the library compatibility - not every dev has time to test for 0.1x,…

Yes, it's important to conserve integers lest we run out

Re: Node.js 5.0 Released

#93
post #48

Earlier quoted context omitted.

Because if you don't, then a year or two down the road you're left with an unsupported legacy hell.

Node.js modules: from brand new to "unsupported legacy hell" in "a year or two." There's no way this is sustainable, but I'm at a loss of how to fix it, especially when the ECMAScript language itself is evolving at such a rapid pace. Any ideas?

>but I'm at a loss of how to fix it, especially when the >ECMAScript language itself is evolving at such a rapid pace. >Any ideas?

Avoid Javascript on the server, problem fixed.

Re: Node.js 5.0 Released

#94

Earlier quoted context omitted.

If by "match V8" you mean "skip most V8 changes"? V8 revs on par with Chrome, at a pace about four times what you say. Turns out that despite pillorying Joyent for sticking to V8 major versions, it is the only reasonably-correct thing to do for the ecosystem to remain usable.

"V8 Major versions"

io.js made a lot of noise about this, and has reached a "compromise" position that is indistinguishable to the end-user - or is LTS going to take V8 version bump over its 2.5-year life?

No?

Then take your scare quotes and bang your drum elsewhere, because from where I stand, the new boss is pretty much the same as the old boss.

Re: Node.js 5.0 Released

#95
post #63

Earlier quoted context omitted.

hey! do you have a specific problem in mind or is this just a hypothetical musing? 'cause the actual changes that break between npm 1 and 2 are very small. (the changes to npm run, mostly, and the cache.) so it's Very Strange(tm) modules that break, and the new run behavior is much more useful - npm team member

By "npm" I assume the author meant "packages in npm", not npm itself.

Right, but packages _in_ npm are still managed by npm. If it were to change the package format between major versions, there could be problems. At least, that's how I read the OP.

Re: Node.js 5.0 Released

#96
post #92
post #91

Earlier quoted context omitted.

I dislike they jumped from 0.1x (and io.js) to 4 and a months later the realise v8 semver is 5 and jump to 5 - stupid. They could have though about version numbers last months, and choose 5. A bit more conservative version numbering would be great. Nodejs up to 0.1x was to slow, and now it's way to fast - a application runtime is not a browser. Mind the library compatibility - not every dev has time to test for 0.1x,…

Yes, it's important to conserve integers lest we run out

He's talking about the speed of code-breaking changes... and now a fragmented install base (similar to the Android problem).

Re: Node.js 5.0 Released

#98

I'm not sure why so many people are freaking out. Looking at the changelog, it looks like they decided to commit a bunch of breaking changes that were previously marked as deprecated. If your code was running before without warnings, upgrading shouldn't have a negative impact. The pace of change is fast because node ES6 support is progressing fast enough to maintain near 1:1 feature parity with v8. A bunch of ES6 fea…

> I'm not sure why so many people are freaking out.

Probably because you don't use any binary packages that haven't even made it to 4.x yet. My app requires one so I'm still stuck on node 0.12 until they update. I've filed a bug report but before they could even respond 5.0 is out. Not they have a quandary: do they support 4.x or 5.x when they update? Npm doesn't support forks, so they can't get one version for users of 4.x and one for 5.x.

The only sensible way to fix this that I can think of is to build in an extension layer into node so that binary packages don't use raw v8 APIs (since those seem to change a lot). Then that layer can be made (more) stable, even in the face of constant v8 upgrading.

Re: Node.js 5.0 Released

#99
post #69
post #56

Earlier quoted context omitted.

i have an app that was written for 0.8 three years ago. it is running on 4.2 with no modification. (it doesn't use any binary add ons). javascript is almost entirely backwards compatible because they can't break the web. Other apps that require binary add ons required me to install the latest versions from NPM -- one one of them required ANY changes to how the API was called and it was extremely minor. Waiting 2 year…

Yeah, but the pain comes from: binary packages, and even pure-js projects that move fast and break things -- you can easily end up with 50 or 200 dependencies for a large node project (not merely some micro-service), especially as packages depend on each other with wild abandon even for trivial stuff they could have wrote themselves.

This is the fundamental problem. As an engineer you have to weigh every single dependency as a cost. If you take a dependency on 200 packages, then NOTHING is going to save you long term as things break.

More or Less, Joyent was mostly doing what they were doing for a reason. What the io.js team is doing also has validity but fundamentally you will always see these issues to some extent because of the philosophy behind it.

Post reply on HN