41–50 of 132 posts
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)
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.…
> I ended up opting for Flask and Python 3x instead Yap good choice. Python to me is more readable (so I can understand my own code and others' better) and I find the echo system to be friendlier and more mature.
Uhh, wait, wasn't nodejs 4.0 only like a month ago? So are there going to be breaking changes every few months now?
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
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 they continue this pace with breaking changes then the ecosystem is either going to only be latest or are going to stick with 4.2.x forever.
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.x comes in, say, 6 months and also breaks another API. Now I have 3 hacks or I only support 4.2.x or 6.x.
This is the first major version since the io.js and node.js merger so I'm not that concerned yet but if they continue this pace then I will be very concerned (just like I was concerned when npm was supporting io.js and node.js when they had differences in their APIs; it forces module developers to choose and limit their availability). I would like to see some path of deprecation for node.js APIs that take multiple major versions to get away from unless it's a major security risk.
Edit: just to clarify my worry: I'm not worried yet. But, and this is a big but, ECMAScript doesn't include any standard libraries for interacting with systems, http, etc so node.js has kinda assumed the role of a standard, defacto library for JavaScript when dealing with a system on a level outside of a web browser. So if the breaking API changes are going to occur every year or faster, to me that's like a language's standard libraries changing every year or sooner.
Yes it's kinda not fair as node.js is NOT a set of standard JavaScript libraries but that's the role it's essentially been given due to the lack of one in ECMAScript.
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)
In a real application, using ecosystem packages, it is fine to decide on a fixed target. But, if the core system is moving quickly, chances are the better packages will be moving quickly too. The fear is that there'll be a necessary change in a package (a security issue, or a bug that only surfaces under rare situations, for example), which can cause a cascading upgrade to the whole app. One that needs to be performed quickly.
This has happened to me once, and it wasn't pretty.
It is a concern for any platform, of course, but fast moving ones do 'feel' like they increase the risk. It's therefore a valid question to ask if there are people deploying code in long-term projects, and what the burden is in practice. Since we don't have empirical data (that I know about).
A lot of the Node community does seem to be made up of people creating apps, and enjoying the latest and greatest functionality. There is fewer information from folks running apps long term in mission critical scenarios. That's not a criticism, at all, just an observation: if you are in the latter camp, or considering whether to be, getting good information is harder.
Technical debt, in terms of platform choice, is important.
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.…
Earlier quoted context omitted.
JS in general moves fast and packages range from great to WTF in quality. I would suggest using Babel(or something similar) for all future JS development. That way you can use ES2015/2016 features now and have them work in most environments. I have a built a small API using express and passport and so far these node changes have not impacted my code. Another option for fast API development is Java 8 with SpringBoot a…
Babel does some other magic that you might not realize, such as converting anonymous functions to named functions (and then assigning those to a variable of the same name).
Earlier quoted context omitted.
But then you have to keep up with Babel changes too... http://babeljs.io/blog/2015/10/29/6.0.0/
Why this urge to keep up to the latest and greatest? Especially for a transpiler? If it is converting your code just fine, why update?
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.…
This may end up deviating a bit from semver, but node and npm have long done that themselves. Ideally, of course, one could simply avoid using unstable portions of the API. That's not always possible, but it should be possible to isolate that instability in a module like "readable-stream". Actually I suspect that any time one is tempted to use the "engines" option, it's time to break that specific API use out into a separate module.
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)
And in 2 years, when we take a peak we see that the changes amassed in between by the non LTS releases are so big we have to pretty much rewrite all of our codebase if we want to continue getting support....