Thank you for contacting us. We will get back to you shortly.
October 31, 2017 - by Colin J. Ihrig
October means two things: pumpkin spice everything and Node.js release line updates. The Node.js project makes various releases year round which include minor improvements, bug fixes, and new features. Twice per year, in April and October, the project cuts a new major release. Each major release is the culmination of six months of code changes, some of which may break compatibility with previous versions. This release process is captured in the following image.
October is particularly exciting because it's the one time per year that a major release line enters Long Term Support (LTS). You can read more about the recent Node.js 8 LTS transition in Wyatt Preul's blog post.
Before looking at Node.js 9.0.0 in detail, it's important to set some expectations:
Major releases of Node.js are generally uninteresting.
If major releases contain all of the breaking changes, how can they possibly be boring? The answer to this question has several components.
New APIs, new language features, and V8 updates typically generate the most excitement among developers. With the exception of backward incompatible V8 updates, these are usually classified as semver minor changes, or feature additions. Since semver minor releases are made on an ongoing basis, the "exciting" changes don't need to wait for a new major release line.
The project tries really hard not to break existing code. When breaking changes are made, they are typically not very drastic. Instead, they focus on small, incremental improvements that just happen to be backward incompatible. The bulk of these changes involve the deprecation or removal of legacy APIs. Furthermore, before an API is removed, the core team attempts to gauge ecosystem usage and impact. If a particular API is widely used, it may not be removed. An example of this is the
Buffer constructor. Another common breaking change is updating the wording of an error message, as there are modules that parse error message strings. Node.js is currently moving towards an error code system, which will make this type of breaking change a thing of the past.
This section lists some of the notable changes in Node.js 9.0.0. Some of the items in this list arrived very recently in Node 8, but warrant mentioning here.
httpmodule will now return a 400 status code when an incoming request cannot be parsed successfully. In the past, Node.js would simply hang up the socket, causing other servers, such as nginx, to assume the Node.js server was down.
assertmodule's methods can now throw any type of error (
SyntaxError, etc.). In previous versions of Node.js, these methods could only throw assertion errors.
Now that it is available, the 9.x release line will receive all non-breaking changes that land in the master branch until Node.js 10.0.0 is released in April. The Node.js 9.x line will never enter LTS and will reach end-of-life (EOL) shortly after the Node.js 10 release. Additionally, while it is expected that no breaking changes will be introduced in Node.js 9.x, history has shown that there will likely be some accidental breakage. As a non-LTS release, Node.js 9.x does not come with the same stability guarantees as an LTS release.
If you (or your company) can safely exist closer to the bleeding edge, tolerate possible unexpected breakage, and can easily switch between Node.js versions, then Node.js 9.0.0 is a viable option for you.
If you are running Node.js in mission-critical areas, require the utmost level of stability, or cannot easily move between Node.js versions, then Node.js 9.0.0 is not a viable option for you. If you fall into this category, you absolutely should be running an LTS release.
This post has explored the Node.js 9.0.0 release at a high level. It also detailed who is a prospective user of Node.js 9.0.0, and who should be using LTS instead. If anything in this post is unclear, please reach out. Joyent offers comprehensive Node.js support and would love to help you succeed.