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.
Node.js 5.0 Released
101–110 of 132 posts
Re: Node.js 5.0 Released
#102I 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.
Re: Node.js 5.0 Released
#103Re: Node.js 5.0 Released
#104Earlier 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.
Re: Node.js 5.0 Released
#105Earlier 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?
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
#106So 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…
Re: Node.js 5.0 Released
#107Good 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.
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
#108I 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.
Re: Node.js 5.0 Released
#109So 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.…
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
#110Earlier 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;…
If this happens, there will probably be compatibility modules like https://github.com/nodejs/readable-stream.