Should Express 5.0 require a minimum of Node.js 4?

[dougwilson]

This is a discussion regarding having Express 5.0 drop support for Node.js 0.10. One of the reasons for the delay in Express 5.0 was the announcement of the official merging of Node.js and io.js, and we were looking forward to it's outcome to determine what we should do with Express 5.0.

Here at Express, we value very long-lived major versions, allowing users to confidentially build their new server on Express and not have to worry about needing to upgrade across a major, breaking change for years. Express 4.0 has been out for over a year now and Express 3.0 was supported for over 3 years !!

When Express 5.0 comes out, Express 4.x line will continue to be fully supported, delivering our users bug fixes, new features, and more!

To this end, we have been carefully watching io.js/Node.js in relation to Express 5.0 such that we can continue this great support history without accidentally locking us into the past for a long time.

Please share your thoughts here.

[Fishrock123]

Fwiw 0.10 will be EOL'd October 2016, and 0.12 at the end of year, 2016.

The former is already in maintenance mode, and 0.12 will go into maintenance-only next April. 0.12's EOL was cut short due to OpenSSL ending support for 1.0.1 at end-of-year 2016.

More info: https://github.com/nodejs/LTS (Slightly outdated)

I'd personally vote for yes (biased I suppose), and try to encourage a larger move to 4.0.0 sooner than later for users.

[Twipped]

Dropping 0.10 for 5.0 sounds good to me. Express 4 isn't that different, right?

[alanpurple]

+1 drop support for 0.10

[hacksparrow]

Highly in favor of dropping support for 0.10.

[talon]

Open source should move as fast as possible w/ option for sponsored LTS. Drop it.

[aredridel]

What's the cost of not dropping 0.10?

[andineck]

Moving forward to node 4.0 seems more important than supporting 0.10

[dougwilson]

So, just to be clear: Express 5.x dropping support for Node.js 0.10 does not mean Express will drop support for Node.js 0.10. Just like Express 3.x has lived in parallel with Express 4.x for almost 2 years now, Express 4.x will continue to live alongside Express 5.x.

To answer @aredridel , not dropping 0.10 from Express 5.x means that 5.x would be hard-pressed to consume and support various features in the newer V8 and Node.js platform (things like Intl, generators, promises, and more). Because we want to make longtivity promises, this means that once Express 5.0 comes out, an Express 6.0 is unlikely to appear until 1 year or more later, putting it further behind the curve.

Here is a little mock-up support example:

Year             0      1      2      3      4      5      6

Express 3 (0.8 ) +--------------------+
Express 4 (0.10)               +--------------------+
Express 5 (4?  )                      +--------------------+

Typically we'll have 2 active Express majors at a time (more than that gets harder, and the benefit decreases). The idea is that we can then perhaps up the minimum Node.js version with a major, since the previous major will still be around for a long time to come after the release. If you look back at the history of the 3.x line while 4.x has existed, we continued to backport every single new feature from Express 4.x into 3.x that was possible with 3.x's design. We intend to do the same with 4.x/5.x, which means 4.x will keep up; the release of 5.x does not move 4.x into "maintenance mode", either.

[Twipped]

Perhaps a better question to ask is, what does Express gain by dropping 0.10 but not 0.12? Most of the improvements you mention cant adopted until 0.12 is abandoned.

[Fishrock123]

Perhaps a better question to ask is, what does Express gain by dropping 0.10 but not 0.12? Most of the improvements you mention cant adopted until 0.12 is abandoned.

Good point.

If we drop 0.10 we should probably also just drop 0.12.

Stats are that 0.12 doesn't have nearly the usage of 0.10, and is, quite frankly, rather buggy.

[dougwilson]

@ChiperSoft @Fishrock123 , oh, my bad. I do not like to think of 0.12 as even exiting, as there are so many issues with the V8 in that version, it's laughable that people can even use that version of Node.js without getting various illegal instruction errors from corrupted machine code generation.

Yes, this topic assumes that the minimum for Express 5 would be Node.js 4. I have updated the title to correspond :)

[aredridel]

Yeah. I've no real interest in generators, but promises I do -- that said, they work fine on 0.10, so that's not an issue.

Intl is near and dear to my heart, but I'd be intrigued to see what actual plans are before throwing out 0.10.

As it stands, if 0.10 is thrown out, that leaves basically 1.8.7, 2.3.0 and 3.3.0 as the only stable versions. 4.0.0 is not yet. It will be, and it's sure intended to be the future, but I really do value backward compatibility too.

[dougwilson]

Hi @aredridel , I understand the concerns. This is only a discussion at this point without any actual commitment. We are looking to understand what the value is, of course. As for promises, we won't be importing any third-party library to do promises, so we would have to look into how to do promises in 0.10 without a Promise global available.

When we implement any feature, we don't want it to be conditional on the version of Node.js you run on, but available on all supported Node.js versions of Express (thus allowing the user to know that running Express 5.2 on a supported Node..js version, they get all the promised features). Because of this, it makes dropping older versions more important, and hopefully should be possible since Express 4 will be fully supported, even adding all new possible features from 5 as they come out :)

If we decide to bump the minimum version of Express 5, yes, it would delay Express 5 a little longer to ensure that Node.js 4 is in a more stable condition when this occurs.

[aredridel]

Yeah. I'm just chiming in in the conversation.

What's the reason for not using an ES6-compatible shim for promises? It's usually a small dependency, and can be conditional on native not being available.

[Fishrock123]

I just want to note that native promises are still super slow.

[aredridel]

True that.

[dougwilson]

What's the reason for not using an ES6-compatible shim for promises? It's usually a small dependency, and can be conditional on native not being available.

We have tried that on a small scale in koa-related repositories, but it never worked very well, and always ended up better if we only used the global Promise function, which most have changed to doing now.

I just want to note that native promises are still super slow.

And, just to calm everyone down on promises, Express and it's dependencies will continue to exclusively use callback-based APIs. The adoption of promises would be in the public API (for those who choose it use it) as well as accepting promises, for those who choose to do so. As in, the current roadmap is a dual API externally, and a callback-based API internally. This should provide people with promises without any performance penalty for those who choose not to use them.

[aredridel]

Good good.

[Twipped]

Can you clarify what you mean by "use promises"? I was under the impression that just meant accepting a thenable as the return on middleware and routes. That shouldn't require any Promise lib, native or otherwise.

On Sep 14, 2015, at 8:39 AM, Douglas Christopher Wilson notifications@github.com wrote:

What's the reason for not using an ES6-compatible shim for promises? It's usually a small dependency, and can be conditional on native not being available.

We have tried that on a small scale in koa-related repositories, but it never worked very well, and always ended up better if we only used the global Promise function, which most have changed to doing now.

I just want to note that native promises are still super slow.

And, just to calm everyone down on promises, Express and it's dependencies will continue to exclusively use callback-based APIs. The adoption of promises would be in the public API (for those who choose it use it) as well as accepting promises, for those who choose to do so. As in, the current roadmap is a dual API externally, and a callback-based API internally. This should provide people with promises without any performance penalty for those who choose not to use them.

— Reply to this email directly or view it on GitHub.

[Twipped]

Requiring Node 4 would be a pretty huge step up, but as long as Express 4 is still maintained I don't think it's a huge problem. Just need to make it very clear that E5 is a future forward version.

[ritch]

@dougwilson What if we adopted Node's LTS Plan? It might not be perfect (and IMO it is very complicated), but at least as a user I only would have to understand a single set of legacy support semantics.

Either way it would be nice to have some documentation (what you should expect) around long-lived major versions.

[OshotOkill]

Since Node 4 & ES6 finally came out I think the next main version of Express should eye for the future to be a new brand of itself, especially the main version have a long lifecycle.

Developers who want to persist in node v0.10 just only to uphold Express 4, and you have already said that would be also maintained after Express 5 realeased. In my opinion node 0.12 should also not to be considered much about compatible in Express 5, but I know that's not realistic.

[ivarprudnikov]

Correct me if I am wrong but compatibility seems to play a bit bigger role here, think third party modules for express. Compatibility would allow quicker uptake of express 5 if it supports node 0.12 for instance as it would not require and would not rely on developers fixing their modules/dependencies to make it compatible with new express. Or would not require searching for new ones.

How would developer know if a module that was used for express 4.0 or 3.0 will work for 5.0? Would I push code to production in this case? I do not know of any automatic tool that could tell me that (idea for greenkeeper.io devs)

[dougwilson]

Hi @ivarprudnikov , nothing in here would make third-party modules not work with Express 5.0. This is simply about a minimum Node.js version for Express. Can you explain how bumping the minimum version of Node.js for Express would break third-party modules for Express? Perhaps I'm missing something critical here?

[ivarprudnikov]

@dougwilson but if module is not compatible with Node > 0.12 ? And the fact that express would require higher (supported) version means there would be additional steps involved in checking if all dependencies work. In the case of existing fleet of nodes, upgrade would require extensive QA. In the case when someone creates new apps, one needs to sanity check if all deps (developer is used to) are compatible with higher node version which on the other hand is a positive exercise.

[dougwilson]

Hi @ivarprudnikov are you not able to do this within a timeline of 1 year? Express 4 is not going anywhere for a long time.

[dougwilson]

Also, if you can point me to specific third-party Express modules that do not function with Node.js > 0.12 , that would help a lot.

[ivarprudnikov]

I am not moaning here, sure I could upgrade, it would just take a bit of time. BTW I just checked passport module and their package.json says it supports node>=0.4, also their site seems to be silent about node v4, but still this is important module which is possibly used by lots of devs. I guess it is going to work with new version of node out of the box, but that alone needs verification. My 2 cents :)

[dougwilson]

Almost all Express dependencies have "node >= 0.8" or "node >= 0.6" but those are minimum versions. They work just fine with Node.js 4, so just seeing low minimums in package.json gives no insight into working with recent versions. I have personally used passport on Node.js 4 without issue.

My point is that Node.js middleware are typically no where low-level enough to be greatly effected by Node.js versions and I have yet yo hear of a module that does not work.

I'm happy yo include that in the decision if you can point out at least one specific instance that is is an abandoned module.

[dougwilson]

Basically, if a module is not going to work with Express 5.0 right away, it's most likely because it's from an Express change, not because of any Node.js change. For example, a module is going to break with Express 5.0 because it's using an API removed in 5.0 or an API that slightly changed more than anything else.

[listepo]

+1 drop support for Node.js 0.10

[tejasmanohar]

:+1: >= node 4.x.x

[listepo]

@dougwilson >= 4.x.x :+1: or >= LTS versions https://nodejs.org/dist/v4.2.1/

[kevinSuttle]

Great example for what this might look like: https://medium.com/@clayallsopp/your-first-graphql-server-3c766ab4f0a2#.asxjuiq0g

[ximex]

+1 for dropping 0.10 and 0.12

[estliberitas]

@dougwilson :+1: >= node 4.x.x

[webdude21]

drop it like it's hot

[listepo]

Hapi.js now "node": ">=4.0.0"

[jimmywarting]

It's not like we have to support IE6 cuz people refuse to upgrade. You have the control and can upgrade whenever it's needed.

The only way to move forward with new awesome ES6 classes, generators async/wait and other modern open standards is to invalidate old technology.

Just saying: Dropping it!

[lenovouser]

@jimmywarting express is server-side which means this has nothing to do with IE6 :)

[jasnell]

There's a more practical concern: official support for both v0.10 and v0.12 expires at the end of this year. There will be no further updates to either after Dec 31st.

[Fishrock123]

At this rate, we could probably target Node v6. :)

[dougwilson]

Just because a runtime is not supported doesn't mean Express will stop supporting it at the same time. Express should support what the users need supported, which is the purpose of this discussion, to determine if users have objections or other things. Node.js 5.x still works on Windows XP, even though it stopped being supported almost a year ago now, as an example.

A good example of an objection is that I, myself, cannot use Node.js 4.x at this time in some places until some clouds are upgraded, which should happen sometime this year. It doesn't seem like there are very strong objections to 4+ for Express 5+, so with the fact that Express 4 will be supported for at least a year after Express 5 comes out, Node.js 4 may very well end up as the minimum version.

[Fishrock123]

even though it stopped being supported almost a year ago now, as an example.

[Edited: whoops, mis-understood] Support is dropping in v6, for multiple reasons iirc.

[dougwilson]

even though it stopped being supported almost a year ago now, as an example.

Not quite correct. Support is dropping in v6, for multiple reasons iirc.

I'm well aware of that. That's why I specifically said Node.js 5.x and not just Node.js in general.

[matheuslc]

We have any deal? If I want to contribute to Express 5.x, what's the version of Node that I can use?

[dougwilson]

There has not yet been a compelling "we can't implement feature x without leaving node.js 0.10", so the 5.x line continues to support 0.10 for now.

[blakeembrey]

@dougwilson I think we should look at specifying the minimum node version as 4.0, even if it doesn't impact Express.js core directly. The ecosystem impact is much more important, and it would signal things like the ability for authors to use the global Promise type instead of polyfills, or Object.assign instead of a polyfill, etc. I'm sure there's a lot of authors out there using these things today who don't want to have to deal with node 0.10 support when someone tries to use it. And sure, the module author might be able to specify 4.0 themselves but that's just moving the burden from us to them when it comes to their users.

[matheuslc]

We can improve Express code base with Node.js new features. I think that a project like it have a strong power to push Node forward.

If the only benefit was syntax, we can use Babel to transpile to old versions. What do you think?

[dougwilson]

I mean, simply changing internal syntax to more sugar which has no benefit to users is a net negative benefit to me, because now we are taking away something without any compelling user benefits. The reasons Blake outlines are much better and we can bump 5.0 once something along those lines are needed. In the meantime the 5.0 branch is just 0.10.

Another issue with changing all the syntax in 5.0 is that we will continue to maintain 4.x and merge into the 5.0 branch with every release for a year or longer after 5.0 release, so if the code is too drastically different without any user benefit, it makes simply maintaining express way harder for no reason.