5 ms·

The last 2 ECMA releases (2017 and 2016) have felt pretty dull honestly. I wonder if their approval process for features is too slow. In 2016 we got almost not

by coltonv 10y ago

The last 2 ECMA releases (2017 and 2016) have felt pretty dull honestly. I wonder if their approval process for features is too slow. In 2016 we got almost nothing, power operator and array.includes(). 2017 We finally got async functions, which have been in consideration for years now, a few helper functions, and shared memory. Object Rest/Spread would have probably made up for it, but now we'll have to wait at least another year even though it's been stage 3 for quite some time. With the language moving this slow compared to faster releasing languages like Python, Elixir, and Go, I wonder if Node.js will start to see a decline in hype since the language hasn't improved much in the last 2 years. What do you guys think?

13years 10y ago
Still seems quite speedy to me coming from the Java world :-) I'm curious as to what is happening with SIMD. That has been at stage 3 for a long time.
spankalee 10y ago
async/await is dull? They completely change how we write async functions. Much, much better code will be the result. ES2018 is likely to be a bigger revision for classes. I hope we'll see class properties, private state and decorators, and maybe BigInts.
- mistercow 10y ago
  I love async/await, but it's really syntactic sugar for a thing you could already do in ES6 with generators. The coroutine pattern is absolutely the right way to go with async handling, but we already had it. Now we have a slightly nicer syntax for it.
  - zubi 10y ago
    I don't think it can be considered syntactic sugar. For one, writing .then( .. => return ..) everywhere is too verbose and using co means that you are using a library to achieve something that the language should have first class support in the first place. Moreover, async/await will have different semantics than generators, the runtime will have native support and no generators will be involved. Calling these solutions "we already had it", IMHO, is like saying we didn't need functional programming features like .filter, .map etc, or newer features like Object.create, Object.assign etc we already had polyfills or other ways to a achieve their functionality. For that matter, even a simple "for loop" is redundant as you can use a while loop and use your own counter to achieve the same results. Async/await as a language construct feels so much better and fulfills a very common pattern than verbose solutions or solutions with different semantics using libraries.
    - mistercow 10y ago
      I'm not positive, but I'm pretty sure that async/await is currently implemented on top of generators in all major engines. I know it's true of at least some engines. Which makes sense. It's not a perf critical feature, so transpiling is the smart move.
thomasfoster96 10y ago
> The last 2 ECMA releases (2017 and 2016) have felt pretty dull honestly. It’s not exactly surprising. ES6 came out almost 6 years after ES5, so there was quite a few changes then. The yearly release cycle was always going to mean fewer features being standardised each release. While I do follow from a distance some of the work TC39 does, I can only assume that most people involved have realised that having an orderly process for feature proposals - and not trying to rush heaps of features into a single release - is a much better way to do things. > With the language moving this slow compared to faster releasing languages like Python, Elixir, and Go Python, Elixir and Go have the advantage that they have one main/reference implementation and can break backwards compatibility whenever they want (although that hasn’t gone brilliantly for Python) by just incrementing a version number. ECMAScript runtimes have to be able to run programs that were written almost two decades ago - backwards compatibility can’t be broken - and you have several major implementations (V8, Spidermonkey, etc.) to deal with. The tail call feature from ES6 is already being revisited because it caused problems [0]. > I wonder if Node.js will start to see a decline in hype since the language hasn't improved much in the last 2 years. Tools like Babel mean that people who really want to use new or experimental language features can do so. There are dozens of language features in the proposals pipeline [1] and many (if not a majority) can be used via a compiler like Babel or via a polyfill. Node.js also has the advantages of having it’s own 'standard library’ and an enormous package ecosystem to use. I think it will be fine. [0] https://github.com/tc39/proposal-ptc-syntax https://github.com/tc39/proposal-ptc-syntax [1] https://github.com/tc39/proposals https://github.com/tc39/proposals
- hajile 10y ago
  > The tail call feature from ES6 is already being revisited because it caused problems Proper tail calls being in the spec don't cause problems. Safari shipped with them a while ago. Chrome/node has them behind a flag. Google wants them to be explicit and everyone's bikeshedding about which bloated syntax is the correct one (or if it should even have its own syntax). The actual debugging issues they talk about are non-issues in my book. Catering to new devs who don't understand tail calls is stupid (by that metric, we should get rid of a lot of other things too). We don't need stack traces for tail calls that loop (just like we don't need them in a for loop). A shadow stack works just fine for CPS (continuous passing systems) and is still better than the debugging tools we have for stuff executing across the event loop (aka nothing worth mentioning).
pjmlp 10y ago
So what? We still have customers that require browser versions that don't fully support ES 5.
- rootlocus 10y ago
  This is something that irritates me. Clients don't mind running old version of X (browser, operating system, hardware, w/e), but they require the latest version of your product. If they're going to stick with windows XP, they should be happy with the software which was written for and when windows XP was supported.

by coltonv 10y ago

13years 10y ago

Still seems quite speedy to me coming from the Java world :-) I'm curious as to what is happening with SIMD. That has been at stage 3 for a long time.

spankalee 10y ago

async/await is dull? They completely change how we write async functions. Much, much better code will be the result. ES2018 is likely to be a bigger revision for classes. I hope we'll see class properties, private state and decorators, and maybe BigInts.

mistercow 10y ago
I love async/await, but it's really syntactic sugar for a thing you could already do in ES6 with generators. The coroutine pattern is absolutely the right way to go with async handling, but we already had it. Now we have a slightly nicer syntax for it.
- zubi 10y ago
  I don't think it can be considered syntactic sugar. For one, writing .then( .. => return ..) everywhere is too verbose and using co means that you are using a library to achieve something that the language should have first class support in the first place. Moreover, async/await will have different semantics than generators, the runtime will have native support and no generators will be involved. Calling these solutions "we already had it", IMHO, is like saying we didn't need functional programming features like .filter, .map etc, or newer features like Object.create, Object.assign etc we already had polyfills or other ways to a achieve their functionality. For that matter, even a simple "for loop" is redundant as you can use a while loop and use your own counter to achieve the same results. Async/await as a language construct feels so much better and fulfills a very common pattern than verbose solutions or solutions with different semantics using libraries.
  - mistercow 10y ago
    I'm not positive, but I'm pretty sure that async/await is currently implemented on top of generators in all major engines. I know it's true of at least some engines. Which makes sense. It's not a perf critical feature, so transpiling is the smart move.

thomasfoster96 10y ago

> The last 2 ECMA releases (2017 and 2016) have felt pretty dull honestly. It’s not exactly surprising. ES6 came out almost 6 years after ES5, so there was quite a few changes then. The yearly release cycle was always going to mean fewer features being standardised each release. While I do follow from a distance some of the work TC39 does, I can only assume that most people involved have realised that having an orderly process for feature proposals - and not trying to rush heaps of features into a single release - is a much better way to do things. > With the language moving this slow compared to faster releasing languages like Python, Elixir, and Go Python, Elixir and Go have the advantage that they have one main/reference implementation and can break backwards compatibility whenever they want (although that hasn’t gone brilliantly for Python) by just incrementing a version number. ECMAScript runtimes have to be able to run programs that were written almost two decades ago - backwards compatibility can’t be broken - and you have several major implementations (V8, Spidermonkey, etc.) to deal with. The tail call feature from ES6 is already being revisited because it caused problems [0]. > I wonder if Node.js will start to see a decline in hype since the language hasn't improved much in the last 2 years. Tools like Babel mean that people who really want to use new or experimental language features can do so. There are dozens of language features in the proposals pipeline [1] and many (if not a majority) can be used via a compiler like Babel or via a polyfill. Node.js also has the advantages of having it’s own 'standard library’ and an enormous package ecosystem to use. I think it will be fine. [0] https://github.com/tc39/proposal-ptc-syntax https://github.com/tc39/proposal-ptc-syntax [1] https://github.com/tc39/proposals https://github.com/tc39/proposals

hajile 10y ago
> The tail call feature from ES6 is already being revisited because it caused problems Proper tail calls being in the spec don't cause problems. Safari shipped with them a while ago. Chrome/node has them behind a flag. Google wants them to be explicit and everyone's bikeshedding about which bloated syntax is the correct one (or if it should even have its own syntax). The actual debugging issues they talk about are non-issues in my book. Catering to new devs who don't understand tail calls is stupid (by that metric, we should get rid of a lot of other things too). We don't need stack traces for tail calls that loop (just like we don't need them in a for loop). A shadow stack works just fine for CPS (continuous passing systems) and is still better than the debugging tools we have for stuff executing across the event loop (aka nothing worth mentioning).

pjmlp 10y ago

So what? We still have customers that require browser versions that don't fully support ES 5.

rootlocus 10y ago
This is something that irritates me. Clients don't mind running old version of X (browser, operating system, hardware, w/e), but they require the latest version of your product. If they're going to stick with windows XP, they should be happy with the software which was written for and when windows XP was supported.