4 ms·

> 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 qui

> 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).

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).