11 ms·

ECMAScript 2018: final feature set

183 points by Garbage 9y ago

namanyayg 9y ago
A quick summary of what's new: * Asnyc Iteration: Looping over async lists, e.g, reading lines from file or an async generator. Allows code like: for await (const x of asyncIterable) { foo(x) } * Spread/Rest (`...`): Makes FP easier. const a = { foo: 1 } const b = { bar: false, ...a } // b is { bar: false, foo: 1 } Works on arrays (spread operator for literals) or objects (rest operator for destructuring) * RegEx features like named capture groups * `Promise.prototype.finally()` - Callback function is always executed, regardless of what promise returns.
- ryanmarsh 9y ago
  I honestly thought object/array spread/rest were already in ES2017. Maybe it's because I'm in my own little Babel/React world. I literally just had to stop and go create-react-app and see if that specific use of rest/spread works and it does. Then I went to babel's docs and found it's part of TC-39. Maybe this is meta, but I wonder what it means for us in this ecosystem. Some of us have totally lost touch with whether the language features we use are supported by the runtime, or are even "canon". Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things. I'm almost 40 now and looking back on my programming career, what we do with JS and language features is truly bizarre.
  - root_axis 9y ago
    In other ecosystems you'd just use a language with features that you prefer, since you can't do that in a browser environment transpilers came along to fill the gap. It doesn't seem bizarre at all, it seems like a giant hack taken to the extreme, which is pretty common thing in the programming world.
  - shados 9y ago
    Yeah, most people don't keep track of what features are "legitimate/standard" and which are not. It's even more problematic because some influential figures in the community push those non-standard features and encourage people to use them. Some are pretty harmless (object spread back when it wasn't standard), some are PROBABLY okay (class field declaration, pushed very hard in the React community because the ES6 class syntax with React kind of suck without it and they pushed THAT too early). Some, however, are downright dangerous, such as decorators (pushed pretty hard in the MobX world) or bind operator (used to be pushed in the RxJS community, though not as much lately with pipeable operators). Those things are not standard, and in the case of decorators, the version being pushed doesn't even match the latest proposal. These are the stuff of tech debt nightmare when used at scale. Yet most people using them have no idea what kind of hole they're digging themselves into, and it's hard to blame them. Can't really keep track of all of that when you have deadlines to meet.
  - sjellis 9y ago
    "Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things." This is one of the main reasons why I am increasingly interested in TypeScript: it gives you more features than JS, but in a way that is consistent and manageable between projects. It seems inevitable at this point that any large project is effectively going to be using a particular flavour of JS, with language or library extensions.
    - WorldMaker 9y ago
      Typescript has been very good at sticking to Stage 3 proposals likely to be adopted by browsers, and providing "off ramps" if the specs change between Typescript implementation and browser adoption. (For instance, Typescript module syntax still recognizes a predecessor to ES Module import/export syntax, but it provides good warnings for the out-of-date syntax and between Typescript strict modes and tslint warnings as errors you can very quickly migrate a project over to the standard syntax.)
Myrmornis 9y ago
I couldn’t immediately see any proposals for list/set/object comprehensions at https://github.com/tc39/proposals https://github.com/tc39/proposals, are there any?
- masklinn 9y ago
  Unlikely. Mozilla had extensions which they submitted for ES6 IIRC (lists and generators) but it seems the tc39 preferred going with HoFs instead.
  - Myrmornis 9y ago
    Thanks. On the face of it it seems a bit of a shame to me. My experience writing python daily (since before dict and set comprehensions were introduced) is that the comprehension syntax is used extremely commonly in a large codebase and that the way that you can specify both the transformation and the filtering in a single comprehension is much more readable than composing a map and a filter.
- turdnagel 9y ago
  I don't think those are happening, but how about basic set arithmetic? The fact that you can't do difference / union / intersection using the standard library is frustrating.
  - pitaj 9y ago
    There's a proposal for that.
    - epmatsw 9y ago
      Two of them now. One to add Set-specific methods, and another to port the usual Array.prototype methods over to Set and Maps. Can't wait! https://github.com/tc39/set-methods https://github.com/tc39/set-methods https://github.com/tc39/collection-methods https://github.com/tc39/collection-methods
gtirloni 9y ago
I understand JS was an experiment and that there was much to add to make it a proper language, but isn't it good enough now? Can we expect the pace of changes to slow down (specially in light of WebAssembly)? I'm not a JS developer and/or language developer, honestly just curious.
- chatmasta 9y ago
  If it’s not breaking backwards compatibility then what’s the problem with improvements?
  - akvadrako 9y ago
    It obsoletes older browsers. For a while it used to be you could browse the web with almost anything, even a 10-year old Netscape. Now it's the norm that a 4 year old browser isn't supported, because of new APIs and JS syntax.
    - Digit-Al 9y ago
      If you haven't updated your browser for four years then you've got a hell of lot more to worry about than if javascript works correctly.
    - tcd 9y ago
      Why do people like you feel that's acceptable? Software can work from anywhere between a few hours to a decade before an update is required, and it entirely depends on what you're doing. Websites evolve, and that's the choice of developers around the world. You have no right to complain if you don't keep your software up to date to a reasonable level. If you want to use 4 years old software, you MUST accept things are broken and that it's your fault. Try downloading Firefox 1-10 and see if they work today ;)
      - akvadrako 9y ago
        I'm not necessarily against forcing upgrades because it comes with advantages, but I was explaining the tradeoff. It's one good thing about Apple and if say, domestic power outlets could change every few years, we could get higher voltages, DC, built in networking, more compact connectors, metering features, etc... But if everything operated like the web ecosystem, we might consume 100% of our time and money just on upgrades. And it pretty much guarantees there will only be a handful of vendors, because it's very expensive to stay current.
Alreadyobsolete 9y ago
The Rest and Spread operators are interesting, I think they're cool syntactic sugar and they've got reasonable use for some types of functional programming, but they feel like a ticking time bomb. It doesn't exactly promote resilience if objects are being passed around many different contexts. It seems like it promotes clunky boilerplate checks over more explicit logic
ridiculous_fish 9y ago
I'm not sure about this named capture group proposal. The idea behind the proposal is that regexp engines parse using the old grammar, but if a GroupName is found, re-parse using a different grammar: If the result of parsing contains a GroupName, reparse with the goal symbol Pattern[~U, +N] and use this result instead. But "the result of parsing" by definition cannot contain a GroupName because GroupName is not part of the initial grammar. Furthermore it appears that the named capture group backreference syntax `\k<groupname>` is in fact valid under the "old" (no-named-capture-group) syntax. Thus the interpretation of `\k<groupname>` depends on the future parts of the expression, similarly to how `\3` can be an octal escape or a backreference depending on the rest of the expression. JS regexp parsing is already underspecified [1] and requires two passes to disambiguate backreferences from octal escapes. Now it appears we potentially need a third pass to disambiguate named capture groups. [1]: https://blogs.msdn.microsoft.com/ie/2010/08/25/chakra-interoperability-means-more-than-just-standards/ https://blogs.msdn.microsoft.com/ie/2010/08/25/chakra-intero...
rbobby 9y ago
All I want is a datetime literal: #2018/01/31 17:00:21.2234233#. I don't even care that it isn't backwards compatible. Eventually platforms will catch up... so the sooner it's added the sooner everything will catch up.
- gmac 9y ago
  Is that because you want date/times in JSON? Shouldn't it include a timezone, and maybe implement ISO8601?
  - chrisseaton 9y ago
    Putting it into ES won’t change the JSON standard though.
    - mikewhy 9y ago
      Wouldn't it have to? It does stand for JavaScript Object Notation after all.
      - stephenhuey 9y ago
        This question seems reasonably sincere enough that you could attempt to answer it rather than downvote it.
      - chrisseaton 9y ago
        That's where the idea came from. But it's now a completely standalone standard, with its own grammar, that just happens to be compatible with a subset of ES.
        epmatsw 9y ago
        Even that's not technically true. You can represent things in JSON that can't be represented in ES object literals. There's a proposal in Stage 3 to fix that though: https://github.com/tc39/proposal-json-superset https://github.com/tc39/proposal-json-superset
a13n 9y ago
Have been using the spread operator via Babel for several months now. It's definitely convenient - saving me from writing several extra lines of code. I worry that spread operators make code less readable. You really have to squint and think more when confronted with one. They also make your code less understandable to a beginner, or people coming from other languages. One of my favorite ways to use them: const foo = {}; if (bar) { foo.bar = bar; } Turns into: const foo = { ...bar && {bar}, };
- STRML 9y ago
  Some parens would at least make that more readable: const foo = { ...(bar && {bar}), };
- masklinn 9y ago
  … Wouldn't const foo = bar ? {bar} : {}; be both more efficient and more readable?
  - a13n 9y ago
    Well typically there are more parameters being set than just the one.
- Demiurge 9y ago
  That's a good example of Abad use of the feature. The logical check and assignment are obvious, and represent the same two operation that three or more nested operations in spread and combine end up causing implicitly. If I saw anyone do that at work, I'd have a chat with them. This is on the same level the newlinephobia.
- koblas 9y ago
  Warning; a few weeks ago I ended up in a debate with a co-worker and ran the performance tests on this construct. Turns out that you would be better served by ```foo.bar = bar``` since nodejs doesn't give you the performance you expect.
- rmrfrmrf 9y ago
tomxor 9y ago
RegExp Lookbehind Assertions Finally... I've had to lookaround it's absence too many times.
- Schaulustiger 9y ago
  I've always been baffled by the absence of lookbehinds. Made a lot of regex searching unwieldy, so I'm glad they finally added it together with named capture groups.
EugeneOZ 9y ago
Thank you so much for "finally"!
behindmyscreen 9y ago
WASM will eventually completely replace the need to use JS for any web development. That will be a good day.
mproud 9y ago
Are there polyfills available for any of this?
- paxunix 9y ago
  You generally can't polyfill an operator or things that require changes to language parsing, but you can run it through a transpiler like Babel so it converts everything to an earlier version like ES5 with more widespread and stable feature support.
skrebbel 9y ago
The async iterators look very powerful to me. That's essentially Streams/Rx Observables right in the language, amirite? Pretty cool, and feels very lightweight. Like, an async generator is how you can write a map/filter/etc over existing streams (eh, async iterators), seems quite nice. But I bet I'm missing something important. Rx is pretty huge and it looks like this feature isn't really. Does anyone know more, from the trenches? What are the downsides? Does Babel compile it well? Are all important use cases covered?
- nerdwaller 9y ago
  We have had async iterators in python for a short bit now, they're truly an awesome feature for evented code. (I don't mention that as a flamewar, simply to confirm that the concept of async iterators is awesome and powerful).
- WorldMaker 9y ago
  Async Iterators are orthogonal to Streams/Rx Observables. Async Iterators are async "pull" operations (think disc I/O; pulling data record at a time from disc) and Streams/Observables are async "push" (think events like mouse clicks). They work great together, using each's strengths to specific needs in an application. Additionally, a lot of the weight of Rx is its large set of "higher order functions" beyond the basics of map/filter/reduce. Similar higher order functions are possible for async iterators. One such library for that is Ix, maintained by some overlap with the Rx team, and maintaining some consistency in operator names and APIs. I've been using Async Iterables fairly heavily lately in an application in combination with Rx-like Observables (using the xstream library, rather than Rx) and Ix operators. I've been letting Typescript do all the downlevel compilation, and have been pretty happy with it in the use cases where I've been using it.
  - skrebbel 9y ago
    Hmm I don't follow. Wouldn't a generator function producing async iterators be "push"? Without any Rx involved? I mean, ever since JS got generators, it has support for unlimited length iterables. Isn't an unlimited iterable of promises precisely what you describe as a push stream? I didn't dive deep, but I do believe I was able to cook up a generator function that produces an async iterable of mouse events. It was able to `for await` it and console log the event data.
qualitytime 9y ago
Funny how the "final feature set for 2018" is nailed near enough Feb 2018. Call me stupid, when I'll get whiteboard tested on these shiny new concepts, but I really don't (and you shouldn't also) give a rats ass about all of this.

183 points by Garbage 9y ago

A quick summary of what's new: * Asnyc Iteration: Looping over async lists, e.g, reading lines from file or an async generator. Allows code like: for await (const x of asyncIterable) { foo(x) } * Spread/Rest (`...`): Makes FP easier. const a = { foo: 1 } const b = { bar: false, ...a } // b is { bar: false, foo: 1 } Works on arrays (spread operator for literals) or objects (rest operator for destructuring) * RegEx features like named capture groups * `Promise.prototype.finally()` - Callback function is always executed, regardless of what promise returns.

ryanmarsh 9y ago
I honestly thought object/array spread/rest were already in ES2017. Maybe it's because I'm in my own little Babel/React world. I literally just had to stop and go create-react-app and see if that specific use of rest/spread works and it does. Then I went to babel's docs and found it's part of TC-39. Maybe this is meta, but I wonder what it means for us in this ecosystem. Some of us have totally lost touch with whether the language features we use are supported by the runtime, or are even "canon". Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things. I'm almost 40 now and looking back on my programming career, what we do with JS and language features is truly bizarre.
- root_axis 9y ago
  In other ecosystems you'd just use a language with features that you prefer, since you can't do that in a browser environment transpilers came along to fill the gap. It doesn't seem bizarre at all, it seems like a giant hack taken to the extreme, which is pretty common thing in the programming world.
- shados 9y ago
  Yeah, most people don't keep track of what features are "legitimate/standard" and which are not. It's even more problematic because some influential figures in the community push those non-standard features and encourage people to use them. Some are pretty harmless (object spread back when it wasn't standard), some are PROBABLY okay (class field declaration, pushed very hard in the React community because the ES6 class syntax with React kind of suck without it and they pushed THAT too early). Some, however, are downright dangerous, such as decorators (pushed pretty hard in the MobX world) or bind operator (used to be pushed in the RxJS community, though not as much lately with pipeable operators). Those things are not standard, and in the case of decorators, the version being pushed doesn't even match the latest proposal. These are the stuff of tech debt nightmare when used at scale. Yet most people using them have no idea what kind of hole they're digging themselves into, and it's hard to blame them. Can't really keep track of all of that when you have deadlines to meet.
- sjellis 9y ago
  "Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things." This is one of the main reasons why I am increasingly interested in TypeScript: it gives you more features than JS, but in a way that is consistent and manageable between projects. It seems inevitable at this point that any large project is effectively going to be using a particular flavour of JS, with language or library extensions.
  - WorldMaker 9y ago
    Typescript has been very good at sticking to Stage 3 proposals likely to be adopted by browsers, and providing "off ramps" if the specs change between Typescript implementation and browser adoption. (For instance, Typescript module syntax still recognizes a predecessor to ES Module import/export syntax, but it provides good warnings for the out-of-date syntax and between Typescript strict modes and tslint warnings as errors you can very quickly migrate a project over to the standard syntax.)

Myrmornis 9y ago

I couldn’t immediately see any proposals for list/set/object comprehensions at https://github.com/tc39/proposals https://github.com/tc39/proposals, are there any?

masklinn 9y ago
Unlikely. Mozilla had extensions which they submitted for ES6 IIRC (lists and generators) but it seems the tc39 preferred going with HoFs instead.
- Myrmornis 9y ago
  Thanks. On the face of it it seems a bit of a shame to me. My experience writing python daily (since before dict and set comprehensions were introduced) is that the comprehension syntax is used extremely commonly in a large codebase and that the way that you can specify both the transformation and the filtering in a single comprehension is much more readable than composing a map and a filter.
turdnagel 9y ago
I don't think those are happening, but how about basic set arithmetic? The fact that you can't do difference / union / intersection using the standard library is frustrating.
- pitaj 9y ago
  There's a proposal for that.
  - epmatsw 9y ago
    Two of them now. One to add Set-specific methods, and another to port the usual Array.prototype methods over to Set and Maps. Can't wait! https://github.com/tc39/set-methods https://github.com/tc39/set-methods https://github.com/tc39/collection-methods https://github.com/tc39/collection-methods

gtirloni 9y ago

I understand JS was an experiment and that there was much to add to make it a proper language, but isn't it good enough now? Can we expect the pace of changes to slow down (specially in light of WebAssembly)? I'm not a JS developer and/or language developer, honestly just curious.

chatmasta 9y ago
If it’s not breaking backwards compatibility then what’s the problem with improvements?
- akvadrako 9y ago
  It obsoletes older browsers. For a while it used to be you could browse the web with almost anything, even a 10-year old Netscape. Now it's the norm that a 4 year old browser isn't supported, because of new APIs and JS syntax.
  - Digit-Al 9y ago
    If you haven't updated your browser for four years then you've got a hell of lot more to worry about than if javascript works correctly.
  - tcd 9y ago
    Why do people like you feel that's acceptable? Software can work from anywhere between a few hours to a decade before an update is required, and it entirely depends on what you're doing. Websites evolve, and that's the choice of developers around the world. You have no right to complain if you don't keep your software up to date to a reasonable level. If you want to use 4 years old software, you MUST accept things are broken and that it's your fault. Try downloading Firefox 1-10 and see if they work today ;)
    - akvadrako 9y ago
      I'm not necessarily against forcing upgrades because it comes with advantages, but I was explaining the tradeoff. It's one good thing about Apple and if say, domestic power outlets could change every few years, we could get higher voltages, DC, built in networking, more compact connectors, metering features, etc... But if everything operated like the web ecosystem, we might consume 100% of our time and money just on upgrades. And it pretty much guarantees there will only be a handful of vendors, because it's very expensive to stay current.

Alreadyobsolete 9y ago

The Rest and Spread operators are interesting, I think they're cool syntactic sugar and they've got reasonable use for some types of functional programming, but they feel like a ticking time bomb. It doesn't exactly promote resilience if objects are being passed around many different contexts. It seems like it promotes clunky boilerplate checks over more explicit logic

ridiculous_fish 9y ago

I'm not sure about this named capture group proposal. The idea behind the proposal is that regexp engines parse using the old grammar, but if a GroupName is found, re-parse using a different grammar: If the result of parsing contains a GroupName, reparse with the goal symbol Pattern[~U, +N] and use this result instead. But "the result of parsing" by definition cannot contain a GroupName because GroupName is not part of the initial grammar. Furthermore it appears that the named capture group backreference syntax `\k<groupname>` is in fact valid under the "old" (no-named-capture-group) syntax. Thus the interpretation of `\k<groupname>` depends on the future parts of the expression, similarly to how `\3` can be an octal escape or a backreference depending on the rest of the expression. JS regexp parsing is already underspecified [1] and requires two passes to disambiguate backreferences from octal escapes. Now it appears we potentially need a third pass to disambiguate named capture groups. [1]: https://blogs.msdn.microsoft.com/ie/2010/08/25/chakra-interoperability-means-more-than-just-standards/ https://blogs.msdn.microsoft.com/ie/2010/08/25/chakra-intero...

rbobby 9y ago

All I want is a datetime literal: #2018/01/31 17:00:21.2234233#. I don't even care that it isn't backwards compatible. Eventually platforms will catch up... so the sooner it's added the sooner everything will catch up.

gmac 9y ago
Is that because you want date/times in JSON? Shouldn't it include a timezone, and maybe implement ISO8601?
- chrisseaton 9y ago
  Putting it into ES won’t change the JSON standard though.
  - mikewhy 9y ago
    Wouldn't it have to? It does stand for JavaScript Object Notation after all.
    - stephenhuey 9y ago
      This question seems reasonably sincere enough that you could attempt to answer it rather than downvote it.
    - chrisseaton 9y ago
      That's where the idea came from. But it's now a completely standalone standard, with its own grammar, that just happens to be compatible with a subset of ES.
      - epmatsw 9y ago
        Even that's not technically true. You can represent things in JSON that can't be represented in ES object literals. There's a proposal in Stage 3 to fix that though: https://github.com/tc39/proposal-json-superset https://github.com/tc39/proposal-json-superset

a13n 9y ago

Have been using the spread operator via Babel for several months now. It's definitely convenient - saving me from writing several extra lines of code. I worry that spread operators make code less readable. You really have to squint and think more when confronted with one. They also make your code less understandable to a beginner, or people coming from other languages. One of my favorite ways to use them: const foo = {}; if (bar) { foo.bar = bar; } Turns into: const foo = { ...bar && {bar}, };

STRML 9y ago
Some parens would at least make that more readable: const foo = { ...(bar && {bar}), };
masklinn 9y ago
… Wouldn't const foo = bar ? {bar} : {}; be both more efficient and more readable?
- a13n 9y ago
  Well typically there are more parameters being set than just the one.
Demiurge 9y ago
That's a good example of Abad use of the feature. The logical check and assignment are obvious, and represent the same two operation that three or more nested operations in spread and combine end up causing implicitly. If I saw anyone do that at work, I'd have a chat with them. This is on the same level the newlinephobia.
koblas 9y ago
Warning; a few weeks ago I ended up in a debate with a co-worker and ran the performance tests on this construct. Turns out that you would be better served by ```foo.bar = bar``` since nodejs doesn't give you the performance you expect.
rmrfrmrf 9y ago

tomxor 9y ago

RegExp Lookbehind Assertions Finally... I've had to lookaround it's absence too many times.

Schaulustiger 9y ago
I've always been baffled by the absence of lookbehinds. Made a lot of regex searching unwieldy, so I'm glad they finally added it together with named capture groups.

EugeneOZ 9y ago

Thank you so much for "finally"!

behindmyscreen 9y ago

WASM will eventually completely replace the need to use JS for any web development. That will be a good day.

mproud 9y ago

Are there polyfills available for any of this?

paxunix 9y ago
You generally can't polyfill an operator or things that require changes to language parsing, but you can run it through a transpiler like Babel so it converts everything to an earlier version like ES5 with more widespread and stable feature support.

skrebbel 9y ago

The async iterators look very powerful to me. That's essentially Streams/Rx Observables right in the language, amirite? Pretty cool, and feels very lightweight. Like, an async generator is how you can write a map/filter/etc over existing streams (eh, async iterators), seems quite nice. But I bet I'm missing something important. Rx is pretty huge and it looks like this feature isn't really. Does anyone know more, from the trenches? What are the downsides? Does Babel compile it well? Are all important use cases covered?

nerdwaller 9y ago
We have had async iterators in python for a short bit now, they're truly an awesome feature for evented code. (I don't mention that as a flamewar, simply to confirm that the concept of async iterators is awesome and powerful).
WorldMaker 9y ago
Async Iterators are orthogonal to Streams/Rx Observables. Async Iterators are async "pull" operations (think disc I/O; pulling data record at a time from disc) and Streams/Observables are async "push" (think events like mouse clicks). They work great together, using each's strengths to specific needs in an application. Additionally, a lot of the weight of Rx is its large set of "higher order functions" beyond the basics of map/filter/reduce. Similar higher order functions are possible for async iterators. One such library for that is Ix, maintained by some overlap with the Rx team, and maintaining some consistency in operator names and APIs. I've been using Async Iterables fairly heavily lately in an application in combination with Rx-like Observables (using the xstream library, rather than Rx) and Ix operators. I've been letting Typescript do all the downlevel compilation, and have been pretty happy with it in the use cases where I've been using it.
- skrebbel 9y ago
  Hmm I don't follow. Wouldn't a generator function producing async iterators be "push"? Without any Rx involved? I mean, ever since JS got generators, it has support for unlimited length iterables. Isn't an unlimited iterable of promises precisely what you describe as a push stream? I didn't dive deep, but I do believe I was able to cook up a generator function that produces an async iterable of mouse events. It was able to `for await` it and console log the event data.

qualitytime 9y ago

Funny how the "final feature set for 2018" is nailed near enough Feb 2018. Call me stupid, when I'll get whiteboard tested on these shiny new concepts, but I really don't (and you shouldn't also) give a rats ass about all of this.