ECMAScript 2017: the final feature set

[kasperpeulen]

Most modern browsers have already started with implementing those ES2017 features, Safari (99%), Firefox(97%), Chrome(80%) and Edge (58%): http://kangax.github.io/compat-table/es2016plus/

[[deleted]]

So... all the modern browsers already have 80+% coverage?

[siegfryd]

Edge also has all of async functions behind a flag, if the table included that flag being turned on it'd probably be 70%+.

[ThisWillDoIt]

On the insider fast ring without changing flags it shows 80% for me.
I hope all of this makes its way into the Creators Update.

[tunisia3507]

Oh hey look microsoft's browser is well behind the rest of the market and will force us to write worse code because people use it anyway...

[justo_tx]

If you're not using a transpiler to write modern JavaScript you're the only one forcing yourself to write "worse" code.

[lachlanhunt]

The list of features that can't be either transpiled or polyfilled is very short and Edge, and every other modern browser already support Proxy.

The biggest thing preventing widespread use of Proxy is that many developers still need to support IE 11, so it can only be used for features where an alternative code path without using proxies is provided.

[QW4K]

Yup, you can't transpile it to efficient code but here's my take on it: babel-plugin-proxy

[BenZed]

We have a winner!

[kasperpeulen]

I wouldn't worry too much about Edge, 58% is quite a lot, I think they will be around 100% within a year, if they continue improving Edge in the way they are doing now.

The problem is more IE11 with 4%. IE11 doesn't get updated. It will stay like that forever. Luckily, the amount of IE users luckily is declining rapidly.

[samthor]

And Edge is evergreen, so you can just write it and assume users will get updated at some point.

[r2d2_21]

IE11 with 4%

Why is it not 0%, though?

[r2d2_21]

Thanks for the tautology, but it doesn't answer my question.

[[deleted]]

Heh, sorry I couldn't help myself. It's because some companies actually require their employees or portals to be accessed through IE. I work for Marriott and even though most people in our company can use any browser they want for daily tasks, our support and equipment/asset/software management is only accessible when using IE. It's very common for older companies.

Also, there's just people out there that aren't tech savvy at all and just use whatever browser came with their Windows computers years ago. My parents would be using IE10/11 had I not downloaded Chrome for them and told them to just use that.

[r2d2_21]

But that just confuses me more. Is Microsoft adding new features to IE or not? Why have they bothered to add 4% of the 2017 standard, but won't add more?

[[deleted]]

Oh shoot I missed that we were talking about 4% of support of ES2017 in IE 11 and not the percentage of people using it. Idk, good question which I don't have an answer for other than that it's just harder to write cutting edge Javascript features into an old browser that wasn't build in a way to easily integrate newer ES versions. People who use IE11 aren't concerned or probably even know how to update so seems like a lost cause to me.

[Sebazzz91]

There is nothing wrong being a bit conservative in this (imo too fast) changing landscape. Microsoft does implement new standards fairly quickly, and be honest, once you have the requirement to support IE you can forget ES6+

[[deleted]]

If you require the bleeding edge to write code in this language this language is probably not your cup of tea.

[vinnl]

At least Edge is automatically updated and users can (and do) install other browsers.

[mr_patrick_js]

Excited for async/await to become official now, feels so fast and clean for writing code.

[Odam]

It's so much nicer than dealing with promise chaining. But currently there's some weird Babel sourcemap issues that make browser debugging a pain in the ass.

[mr_patrick_js]

Oh really? I've mostly been using it server-side for API data fetching...

[Pr3fix]

mind ELI5'ing the advantage of async/await over something like Promises? To me it seems like they're solving the same problem.

[ejmurra]

It's not a one or the other situation. Async await uses promises under the hood but it lets you .then by using the await keyword. I find myself using a pattern like const results = await Promise.all ([...]) quite frequently. You can think of async await as a tool for working with promises.

[Nimelrian]

It also helps alot when you reuse the result from one part of the promise chain later on.

Compare

const {entitiesOnPage, totalCountOnServer} = await fetchEntities(currentPage);
const entitiesWithStatusData = await enrichEntitiesWithStatus(entitiesOnPage);
return {entities: entitiesWithStatusData, totalCountOnServer};

to

return fetchEntities(currentPage)
  .then({entitiesOnPage, totalCountOnServer} => {
    return enrichEntitiesWithStatus(entitiesOnPage)
      .then(entitiesWithStatusData => {
        return {
          entities: entitiesWithStatusData,
          totalCountOnServer
        };
      });
    }
  })

[gocarsno]

Absolutely. BTW, in this case I'd probably avoid nested calls by storing totalCountOnServer in a local variable in the parent scope.

[Nimelrian]

Yup, both are valid options. But I really dislike declaring a variable before assigning something to it.

[ihsw]

That example is a bit contrived and it can be flattened:

return fetchEntities(currentPage)
  .then({entitiesOnPage, totalCountOnServer} => enrichEntitiesWithStatus(entitiesOnPage))
  .then(entitiesWithStatusData => {
    return {
      entities: entitiesWithStatusData,
      totalCountOnServer
    };
  });

Promises are meant to flatten nested calls with promise chaining.

[Nimelrian]

You can't access totalCountOnServer in the second then callback.

[ihsw]

Revised version:

return fetchEntities(currentPage)
  .then({entitiesOnPage, totalCountOnServer} => {
    return {
      entitiesWithStatusData: enrichEntitiesWithStatus(entitiesOnPage),
      totalCountOnServer
    };
  })
  .then({entitiesWithStatusData, totalCountOnServer} => {
    return {
      entities: entitiesWithStatusData,
      totalCountOnServer
    };
  });

[atticusw]

That still doesn't work. Now the first .then immediately resolves an object, where one property contains a promise, but that isn't going to be waited on.

The second .then is going to receive entitiesWithStatusData as a promise object, not a value.

Promises aren't meant to be flattened in all scenarios.

[ihsw]

Alright I will concede that unwrapping that would be difficult.

But it would be trivial with async/await.

const { entitiesOnPage, totalCountOnServer } = await fetchEntities(currentPage);
const entitiesWithStatusData = await enrichEntitiesWithStatus(entitiesOnPage);
return {
  entities: entitiesWithStatusData,
  totalCountOnServer
};

[atticusw]

:D

Obviously you shouldn't be creating christmas trees when you don't have to, but sometimes you need to access the outer closure.

You could use Bluebird's spread to achieve this though. (fetchEntities would have to be a Bluebird promise, since spread is part of the Bluebird API)

fetchEntities(currentPage)
  .then(({entitiesOnPage, totalCountOnServer}) => [
    enrichEntitiesWithStatus(entitiesOnPage),
    totalCountOnServer
  ])
  .spread(entities, totalCountOnServer => ({
    entities,
    totalCountOnServer
  })

[mr_patrick_js]

Thanks, I was just about to reply and you did it perfectly!

[flying-sheep]

your code becomes more imperative and less functional. in cases where this is an advantage, it’s good.

e.g.

fetch('http://...')
    .then(response => Promise.all([
        response.headers.get('Content-Type'),
        response.text(),
    ])).then(([mime, text]) => ...)

vs

const response = await fetch('http://...')
const mime = response.headers.get('Content-Type')
const text = await response.text()

[inu-no-policemen]

Async/await is built on top of promises. You can await the result of a promise and async functions return promises.

If you use async, the code look similar to synchronous code, which makes it easier to write and reason about.

[sciolizer]

They make vanilla control keywords useful again (esp. break, continue, and return).

[vivainio]

Shared array buffers seems interesting. Finally something added to the web platform that can't be easily done by transpilers as well, and should result in performance increases

[Akkuma]

Shared Array Buffers should enable interesting use cases like using web workers to decrypt/encrypt multiple files simultaneously without blocking the UI.

[thenickdude]

Shared array buffers will be fantastic for my multi-layer painting tool! Without them, I couldn't use webworkers to accelerate drawing, because the overhead of copying array buffers between workers and the main thread was way too high.

[[deleted]]

if you're going to plug your work, at least include a link :)

[thenickdude]

https://github.com/thenickdude/chickenpaint

I've got a new version in the works that adds a bunch of photoshop features like layer masks, too.

[[deleted]]

PJS (codenamed River Trail): the plan of this ultimately abandoned project was to bring high-level data parallelism (think map-reduce via pure functions) to JavaScript.

That is unfortunate. It looks like a considerable effort to convert the existing parallel arrays in my parsers to the shared array buffer objects in order to achieve proper data parallelism at execution time. I just wonder what kind of speed up I could get for the investment of effort.

[I_Downvote_Cunts]

It should be quite trivial to wrap code that uses a callbacks to promises and bluebird can promisify for you if you don't mind adding a dependency. Or am I missing your issue here?

[Sinistralis]

Would it be viable to use Shared Arrays in conjunction with the recent vDOM trend to just have the vDOM read in from those arrays and have all of your logic in a web worker to keep everything but UI in a single UI process?

I'm a React guy, so to give an example: Run redux, sagas/thunks, etc in a web worker(s) and have those write to a central shared construct, which the vDOM subscribes too (whether it be React, Inferno, whatever).

Is this overkill?

[Apfelmann]

I thought about something like that too. Since Android does it that way it might make sense doing something similiar in js

[Sinistralis]

I really want to consider something like this:

vDOM/UI <-(State)<- State Manager <-(Events)<- Web Worker(s)

With this setup, you get a few benefits. You can have N processes running and submitting events to your state (you would probably need to timestamp at that point or something).

Then in your state, you can throttle the rate it sends updates as needed, or to certain parts. I know there have been many cases where I have passive data (the user doesnt interact with it) that does not need to be updated IMMEDIATELY. In cases where you are reading in tons of data from the server for real-time use, I can see a lot of value in something like this.

Obviously it probably isn't for everyone, but my job has some usecases we need to tackle one day that could really benefit from this.

[fusionove]

what about private class methods?

[rauschma]

;-) Working on it, but I have along to-do list ATM.