Live data from Hacker News

Node.js 5.0 Released

github.com

101–110 of 132 posts

Re: Node.js 5.0 Released

#101
post #93

Earlier quoted context omitted.

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.

Pretty much. It's not like we're stuck for options.

Re: Node.js 5.0 Released

#102
post #7

I recently looked at using Node for a simple API backend. ES6 seems like it's not there yet, the stability of Node makes me wary. Constant changes seem exhausting to keep up with. For a simple microservice api you don't want to be upgrading it every 3 days. The continuous change doesn't make sense to me. Trying to get up to speed on all the Node.js ecosystem feels exhausting, only to have it change a few weeks later.…

No need to always be on the latest version. v4.2 is an LTS branch that will be supported for the next two and a half years. And with tools like nvm, it's incredibly easy to swap out different versions and go for a test drive.

"n" is another good node version manager that makes switching versions painless. https://github.com/tj/n

Re: Node.js 5.0 Released

#104

Earlier quoted context omitted.

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.

I read it as: how do authors publishing packages on npm maintain compatibility between multiple versions of node with breaking standard library changes?

Re: Node.js 5.0 Released

#105
post #6

Earlier quoted context omitted.

Node now follows Semver. If you look through the changelog, there's more than a dozen changes that are breaking.

That doesn't answer the question. Node 4.0 was released a month ago. Why are there so many breaking changes in 1 month?

> Why are there so many breaking changes in 1 month?

Because that's when the planned functionality was coded, tested, and ready to deliver.

Node's development model is a form of the fairly common model where you avoid wasted work (that is, work not delivering value for customers that want it) by delivering features as soon as they are ready and tested, while periodically splitting off and committing to support long-term-support releases for customers that are more concerned with longer-term stability than having the latest and greatest the moment its ready to use.

Re: Node.js 5.0 Released

#106

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.…

ISTM one could keep developing for the old nodejs under the current major version, or even the current major version plus a few more major versions. Then simultaneously release under a different major version for the new nodejs. The "engines" option of package.json makes it possible to partition one's releases this way. This may end up deviating a bit from semver, but node and npm have long done that themselves. Idea…

Does "engines" actually make it possible to partition your releases? I thought by default the engines part of packages.json was ignored.

Re: Node.js 5.0 Released

#107

Good lord people... 1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+ 2. 5.0 followed 4.0 so closely because 4.0 was the iojs/node merge and 5.0 was to correspond with the new V8 release, future major bumps will be closer to 6mo (to match V8)

If you are at 5.x today, and 6.x sometime next year, as a library author why would you - next year - decide to write a package for something for 4.x? That is 2 major versions outdated. If it's really major bumps every 6 months and 7.x comes out next year too, who's going to be writing new stuff for 4.x? Most new packages will probably support the current version, and then your LTS window of 2 years doesnt mean much.

> If you are at 5.x today, and 6.x sometime next year, as a library author why would you - next year - decide to write a package for something for 4.x?

Because the target user community of what you are writing consists of the kind of users that are likely to use LTS releases.

> Most new packages will probably support the current version, and then your LTS window of 2 years doesnt mean much.

You don't choose LTS because you want support for every new packages that haven't been written yet on the day they come out, you choose LTS because you've got something for which you want to have a stable platform with bug fixes, rather than an unstable platform with breaking changes, and are willing to not have access to the newest platform features or the newest third-party libraries that depend on them to get that stability.

Re: Node.js 5.0 Released

#108
post #7

I recently looked at using Node for a simple API backend. ES6 seems like it's not there yet, the stability of Node makes me wary. Constant changes seem exhausting to keep up with. For a simple microservice api you don't want to be upgrading it every 3 days. The continuous change doesn't make sense to me. Trying to get up to speed on all the Node.js ecosystem feels exhausting, only to have it change a few weeks later.…

javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.

You jest, but this week i've been developing my first java web app using play framework, coming from a decade of PHP and javascript, and i found the experience surprisingly nice. You can get a good edit-refresh cycle going using incremental recompilation, and the api's are elegant and flexible. My preconceived notions of the verbosity and ugliness of java web app code proved unfounded.

Re: Node.js 5.0 Released

#109

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.…

There are still major libraries that haven't updated their engine requirements in package.json to reflect that "proper" Node.js is now above 4.x (versus 0.10.x or 0.12.x), for example. It is a little bit surprising to me that they are at 5.x already.

You know, it's pretty funny that all the io.js people (myself included) were complaining about how glacial the pace was from Joyent, and now here we are, seeing some grumbling about how quick the pace has picked up. :)

Re: Node.js 5.0 Released

#110
post #21

Earlier quoted context omitted.

Yeah, why not? Just because they upgrade node, doesn't mean you have to use that version. If you want a stable version, you'll be on the LTS release that will be supported for a long while

The only problem with that is npm is used across all versions. So each version of node that has breaking changes, what do you do as a module author? You might have to drop support for one version or the other or you add in some hacks to try and figure out which APIs you can and cannot use. Moving fast is one thing and this is the first major version after the io.js and node.js merger so maybe this is a one-off thing;…

> You might have to drop support for one version or the other or you add in some hacks to try and figure out which APIs you can and cannot use.

If this happens, there will probably be compatibility modules like https://github.com/nodejs/readable-stream.

Post reply on HN