Es6 support

[matt212]

1.When would expressjs will be migrated to es6
2.updated code base documentation for es6 like routes ,session management.

[dougwilson]

Hi @matt212 there is no plans to migrate the code base of Express to ES6, as there has not been any demonstrateable reason to do so at the expense of dropping Node.js version support. I use ES6 daily with Express, as the code I write that uses Express doesn't have any concern with the version of ES that Express itself uses. Perhaps you have additional insight, though. Can you share what the motivations of your questions are? Perhaps we can start there.

[inunotaisho]

As a finance developer, I would like to see es6 and/or Typescript versions of ExpressJS. Ideally these would be branches within the project itself in order to maintain backwards compatibility. My motivation, @dougwilson, would be to make it easier for the next guy who 'sits in my chair.'

[dougwilson]

Hi @inunotaisho26 I use ES6 & TypeScript daily with Express, as the code I write that uses Express doesn't have any concern with the version of ES that Express itself uses. Perhaps you have additional insight, though. Can you share what the motivations of your questions are? Perhaps we can start there.

[inunotaisho]

Hi @dougwilson, here is a good example, I had a developer come to a nodeschool we were hosting in Baltimore, MD. She wanted to try and learnyounode, but after seeing that she could already write an express server using ES5, I, as a mentor, decided she should learn ES6. By the end of the session, it turned out I was right. She was already that skilled, she just didn't know it. My overall point is by employees will have to be using ES6 and going through the hassle of installing a compiler into the project will make it difficult over the long haul. Having it pre-embedded into ExpressJS would be nice for two reasons. One it makes it easier on my developers, but more importantly it would be open source. If my company, being finance, has to develop a fork express with both compiler and https pre-embedded, I can guarantee it will not be open source. In business that's called a cash cow. You milk it for all it's worth. It would be a good idea for the express project to avoid that.

[dougwilson]

Hi @inunotaisho26 I'm not sure what you mean. I don't have to do any special installing of a compiler to use ES6 with Express today. Can you give some specific examples of what exactly in ES6 you can't do today without compilers? Perhaps some suggestions on what Express needs to change to help? I just don't understand what we need to change to help your use-case is all. A clearer outline of what we should be changing would help a lot!

[inunotaisho]

Hey @dougwilson, My original degree was in general business and management. My family involved in finance since 1977. The point I'm trying to make is having a compiler like babel added would be beneficial if they express team did it while the project open source. If a close source team was to develop an in house server, it would deny users like the girl I mentioned, @matt212 and the open-source community as a whole an extra nicety. As for examples I can't give you those as of yet, but I am telling you how the financial industry works. They are not open sourced unless you're willing to pay for it. That's not my argument boils down to. Now I'm obviously trying to change that, but by the time I'm finished, at least half the country will have wanted to lynch me at one point or another in the future.

[dougwilson]

Hi @inunotaisho26 I'm sorry, I was just trying to better understand. I just don't understand what your ask is. Node.js supports ES6 already, there is no need for Babel. I just don't understand what you're asking for, I'm sorry. Can you give some specific examples of what exactly in ES6 you can't do today without compilers? Perhaps some suggestions on what Express needs to change to help? I just don't understand what we need to change to help your use-case is all. A clearer outline of what we should be changing would help a lot!

[WORMSS]

@inunotaisho26 having express be ES5 while you develop your middlewares and route handlers in ES6 is no problem. Is that what you mean by ES6 Support?

[inunotaisho]

@WORMSS @dougwilson that and the lack of support for import statements. Import statements have some advantages over the normal keywords like let const and var. I imagine that opinion would be up for debate though. @dougwilson Sorry about being incognito. Been busy over the past two weeks.

[dougwilson]

I use import with Express today. I don't understand how it doesn't support import. Can you elaborate?

[inunotaisho]

@dougwilson I get terminal output warnings saying import statements are invalid. Thats with most recent version and LTS versions of node. The terminal output is like a bunch of upturned carets under the word import.

[dougwilson]

@inunotaisho26 for example, I am using import with Express currently without issue, but maybe not in the same way you are. Perhaps if you can show an example of what doesn't work, what you expect to work, and even better would also be maybe what changes we would need to make to Express to support them, as I just don't understand.

[dougwilson]

Oh, I see @inunotaisho26 . No, no versions of Node.js support import statements at all. You have to use babel or similar. This is a Node.js issue, not something Express can change.

[WORMSS]

@inunotaisho26 Are you referring to ES6 import within NodeJS in general?

edit: @dougwilson got there first

[inunotaisho]

@dougwilson @WORMSS import {cpus} from 'os'; ^^^^^^ SyntaxError: Unexpected token import this is what I am talking about.

[dougwilson]

Hi @inunotaisho26 no versions of Node.js support import statements at all. You have to use Babel or similar. This is a Node.js issue, not something Express can change.

[inunotaisho]

@dougwilson well, that clarifies things. thanks.

[KJlmfe]

@dougwilson ES6 has many advantages such as arrow function to avoid binding this. You must know more than me. Why don't we make full use of these pros to short code and be more elegant. It's not urgent as some ES6 features like import haven't been fully supported. But it could have a try when ES6 be completely stable. Or will you never plan to support ES6?

[dougwilson]

Hi @KJlmfe you can already use ES6 features like arrow functions in Express.js apps today. For example, here is how you would write a handler using the arrow function:

app.get('/', (req, res) => res.send('Hello, world!'))

Does that not work for you already?

[niftylettuce]

@KJlmfe if you need a reference please defer to http://node.green/

[KJlmfe]

@dougwilson Sorry, I misunderstand this issue. I mean do you have a plan to rewrite expressjs with ES6?

[dougwilson]

https://github.com/expressjs/discussions/issues/59#issuecomment-300969108

[raxell]

there is no plans to migrate the code base of Express to ES6, as there has not been any demonstrateable reason to do so at the expense of dropping Node.js version support

@dougwilson so, why keep support for node versions that are no more maintained (currently anything < node 6)? ES6 migration is not required, but support for old node version is not required too. Besides express I've seen that almost every module that express depends on keeps support for no more maintained node versions. Drop that support could make the code leaner and easier to maintain (with possible migration to ES6 too in the future). This could also allow to set a release schedule with with constant drop of old features.
I don't find the argument "still lot organizations use it" a good one. Many problems with software depend by the lack of updates, so why encourage it? If organizations want to keep not updated software than they can also use old versions of modules (thanks to semver systems would not break, otherwise, why use semver?). Why should modules obey those organization behaviours and not the opposite?

[dougwilson]

I don't find the argument "still lot organizations use it" a good one. Many problems with software depend by the lack of updates, so why encourage it? If organizations want to keep not updated software than they can also use old versions of modules (thanks to semver systems would not break, otherwise, why use semver?). Why should modules obey those organization behaviours and not the opposite?

@raxell here is a better argument, then: my organization still needs is and it is in my interest to work to keep supporting it. Frankly if Express drops it, why would I ever stay with Express to work on it, when I can't use it for my own things? I would simply fork Express and put all my effort into that fork. If that happens, who, exactly, would be doing Express?

The internals of Express.js using ES6 or not has no relation to the users who use it using ES6 or not.

Drop that support could make the code leaner and easier to maintain

You're saying "could" here. That is fine, but that's not even saying it will, just like a "maybe". Moving to ES6 will drop support for old Node.js versions. But moving to ES6, will, what, exactly?

[wesleytodd]

The internals of Express.js using ES6 or not has no relation to the users who use it using ES6 or not.

While I agree with most of the rest, this is the most important part of this discussion. If there is no benefit to the users, then why would there be any discussion around doing more work for no benefit?

Also, supporting the versions of node which were in use when the major version was released is required to be "semver"-ish. So as we have discussed in many other forums, version support changes will come with 5.0, but they will be based on the supported versions of node at that time. Once we have dropped support in name we can start considering patches which include usage of new language features, but they would have to be beneficial, not just vanity usage of const for no other reason.

The one thing I think we should start doing is updating the examples to be more modern. Because many of the examples are integrated into the tests, we would have to extract that first. But we could start updating the website and readme without that much effort.

[WORMSS]

Symbols was a great reason to use ES6. Rather than polluting the res/req with common use property names. And especially in the bug with morgan which can actually cause incorrect times to be stored if using two instances of morgan at two different parts of framework.

[wesleytodd]

@WORMSS Yeah that would be a case to make once we can use them in all the versions supported. But again, it is case by case and an argument will need to be made which is more than just "oh it is new so it must be great" or "look how clever I am that I can use feature ${X}" :)

[raxell]

my organization still needs is and it is in my interest to work to keep supporting it. Frankly if Express drops it, why would I ever stay with Express to work on it, when I can't use it for my own things?

@dougwilson You can still use it, just choose an old version. If you can use an unmaintained version of node (which is not worse than using an unmaintained lib), why can't you use an unmaintained one of express? Semver also serves this purpose, why use it otherwise, just keep backward compatibility forever.

You're saying "could" here. That is fine, but that's not even saying it will, just like a "maybe". Moving to ES6 will drop support for old Node.js versions. But moving to ES6, will, what, exactly?

Well, I'm more interested in the node version thing here (I'm a bit off topic maybe, sorry for that). If you drop support for old node lots of code in lots of modules can be refactored in favor of built-in node api functions. So dropping support here is not a bad thing as you stated from my point of view.
Are you worried more about the huge changes needed in the various libraries code bases or about the drop of versions of node itself? ES6 would make the code more concise too, but this is more a matter of maintainers preferences I think, so it's a relative thing.

[dougwilson]

Symbols was a great reason to use ES6. Rather than polluting the res/req with common use property names. And especially in the bug with morgan which can actually cause incorrect times to be stored if using two instances of morgan at two different parts of framework.

This is a good case, but the morgan module is it's own module and can make that change independent of Express.js itself if that is something it needs to solve :) That was one of the main drivers to split the modules apart in Express 3 -> 4.

@dougwilson You can still use it, just choose an old version. If you can use an unmaintained version of node (which is not worse than using an unmaintained lib), why can't you use an unmaintained one of express? Semver also serves this purpose, why use it otherwise, just keep backward compatibility forever.

Your argument would make sense if I was purely a consumer of the module, but I am, myself, a maintainer of the module. If in your example I were to use the old version, then that would be the only version I would maintain, removing a lot of momentum from ever changing the current version, which would in turn make using the older version better since that is were I'd be landing new features and bug fixes.

If you drop support for old node lots of code in lots of modules can be refactored in favor of built-in node api functions.

So Node.js API is not related to using ES6 in express. Node.js API is completely separate from the language version (like ES5, ES6, etc.), as it's related to the Node.js version.

This issue is specifically about changing the express source code to ES6, and so, yea, talking about using Node.js APIs would be a different topic, and if you have specific cases in mind, you're welcome to open a separate issue to discuss such a thing.

And to re-iterate what @wesleytodd noted above:

supporting the versions of node which were in use when the major version was released is required to be "semver"-ish. So as we have discussed in many other forums, version support changes will come with 5.0, but they will be based on the supported versions of node at that time.

[raxell]

Your argument would make sense if I was purely a consumer of the module, but I am, myself, a maintainer of the module. If in your example I were to use the old version, then that would be the only version I would maintain, removing a lot of momentum from ever changing the current version, which would in turn make using the older version better since that is were I'd be landing new features and bug fixes.

I'm not sure I've understood this point, do you mean "since I use an old node version, as a maintainer I want to keep express support for it"?
Otherwise maintaining different express versions seems normal to me, it is what is done with LTS releases.

talking about using Node.js APIs would be a different topic, and if you have specific cases in mind, you're welcome to open a separate issue to discuss such a thing

I've seen modules that keep dependencies and non built-in functions just to keep support for old node versions. I would be happy to contribute to update them, but it would make sense only if you agree to drop node support (obviously that would require cascading semver updates too).

[dougwilson]

I've seen modules that keep dependencies and non built-in functions just to keep support for old node versions. I would be happy to contribute to update them, but it would make sense only if you agree to drop node support (obviously that would require cascading semver updates too).

It's hard to really know what you mean, specifically. Can you open a new issue with a proposal of what, specifically you're looking to update? For example you mention using non-built-in functions vs built-in ones. Which specific built-in functions can Express.js use where it is currently not using one? It's really hard to argue for or against something non-specific. This issue, for example, is specifically about using ES6. The answer has basically been "just someone provide a concrete change + benefit to the express code base so we can evaluate it". It is not been a "no" or this issue would have been closed long ago...