Hacker News Reader

Comment by my123 | Hacker News Reader

On the web browser side, I don't recommend using ES6 yet, without any kind of fallback. Internet Explorer 11 is still used, as are devices on older iOS versions. (without counting people using the default browser on pre-Lollipop Android)

View on HN

Also - for anyone writing code where performance matters, the question isn't when browsers support the syntax, it's when each JS engine's optimizations support it.

E.g.: until some months ago just putting "let foo" into a function would cause V8 to bailout (meaning the whole function gets executed slowly, even if the actual let statement gets removed as dead code).

Unfortunately I've never found any good references on the optimizability of ES5+ features, so I've been avoiding them so far.

This is a real concern, but it definitely carries the usual caveats about premature optimization and needing to measure regularly to confirm that it is a real concern and that the performance landscape hasn't shifted since the last time you measured it.

The best suite I've seen is https://kpdecker.github.io/six-speed/ which measures node and the various modern browsers which Sauce Labs supports and appears to be run semi-regularly.

Must be careful with the results on that page. It shows map-string as being slower for ES6 (using `new Map()`) compared to ES5 (using `{}`), and yet I found the opposite, that ES6's Map() is faster in my benchmark[1].

[1] https://gorhill.github.io/obj-vs-set-vs-map/

That is a great reference, but in general I don't find myself caring much about the raw performance of individual statements that way. My concern is that this or that new syntax will prevent a function from getting inlined, or prevent the engine from guessing type information it otherwise would have guessed, or whatever - just because those bits of the optimizing compiler are newer and less robust.

I agree that this is a valid concern. And I do not trust the six-speed test to do the right thing here. See for example https://github.com/kpdecker/six-speed/pull/42 where the test claims to be measuring the speed of destructuring, but in Firefox the result is entirely due to the effects of destructuring on the engine's ability to eliminate dead code. While that is relevant to performance, all it means in the end is that if you destructure something and then pointlessly throw away the result, that it will run much slower than using an ES5 assignment to pull out the field and then pointlessly throw it away. It says nothing about actual code that destructures and then uses the result vs ES5 code that pulls out the field and then uses the result. And that PR was closed because it's showing up an optimization gap, and kpdecker wants to force vendors to implement optimizations -- which is fine, except this is an optimization for something that is irrelevant to production code.

This might just be an isolated incident, but it shakes my confidence in the utility of the six-speed suite. I actually do want to know whether there's a speed difference between const { a } = obj vs const a = obj.a, and the suite does not test that. (Worse, it kind of claims that it does, but reports something else instead.)

If 'let' prevented inlining, I would want to know, but I'd have to look very closely at the six-speed benchmarks to figure out whether it's detecting that. And the range of subtle reasons for deoptimization is vast, so despite working on a JS engine myself, I doubt I'd be able to tell whether a given microbenchmark is meaningful or not.

(Note that the Firefox devtools does have a "Show JIT Optimizations" that can tell you why things aren't getting optimized, but it's incredibly cryptic, undocumented, and scaremongering.)

I'd assume the author would be receptive to pull requests for things like the `let` deoptimization.

`let` doesn't deoptimize anymore - actually V8 has made great strides here, and a lot of new syntax will go through the optimizer. More generally though, I wouldn't think the stuff I'm worrying about would show up in microbenchmarks.

https://docs.google.com/document/d/1EA9EbfnydAmmU_lM8R_uEMQ-...

That's the planning doc for v8 optimization of ES2015+ and an interesting read.

This is an important distinction, and as far as I know, none of the new features are very optimized. If you really want to write performant JS without a build step, you basically have to write it ES3-5 style, use for loops over maps and foreaches, etc

> none of the new features are very optimized

I think for-of is getting pretty good. It's a bit of a pain to optimize because the iteration protocol in ES6 is designed in such a way that you have to do heroics (scalar replacement) to have any hope of optimizing it well. But engines are getting there.

For anyone who wants to use ES6 in production, https://babeljs.io/ is amazing.

It's both amazing, and 600MB worth of dependencies. We use it for server-side code. It's high quality, and we only have a few issues with it, but I can't wait to be able to ditch is (pretty much when async/await lands in a stable node).

600MB worth of development dependencies, which don't effect the code being sent to the client. Just wanted to clarify.

I'm using it server-side, so yea, you're not wrong.

Doing

    du -ch ./babel*

from my `node_modules` directory yields

    3.2M	total

so I'm gonna need a citation on that 600MB claim.

Admittedly, if you're using a flat structure like NPM3 does, then everything else is at the same level :)

It caught those! doing `du -ch ./babel` says it's only 20k, babel-core is 148k, and babel-cli is 104k.

537M here. babel* matches the following packages:

node_modules/babel node_modules/babel-core node_modules/babel-eslint node_modules/babel-plugin-array-includes node_modules/babel-plugin-transform-runtime node_modules/babel-preset-node5 node_modules/babel-register node_modules/babel-runtime

Of course you can just pretend I'm lying.

I believe that you're getting that number, but there might be something wrong with your install. I just installed all of those packages and ended up at 6MB.

I don't think it's such a stretch. From facebook's yarn announcement[1]:

> or example, updating a minor version of babel generated an 800,000-line commit that was difficult to land and triggered lint rules for invalid utf8 byte sequences, windows line endings, non png-crushed images, and more. Merging changes to node_modules would often take engineers an entire day.

I just did a fresh install in a new directory and ended up with 114M worth of dependencies, so I'm not entirely sure what the difference is.

My point is. 50MB, 114MB, or 500MB worth of javascript dependencies is a massive footprint. It works and I'm relatively happy with what it does, but I don't see this as a stable, long term thing.

[1]: https://code.facebook.com/posts/1840075619545360

    mkdir babel-size-check
    cd babel-size-check
    babel-size-check yarn init -y
    yarn init v0.16.0
    warning The yes flag has been set. This will automatically answer yes to all questions which may have security implications.
    success Saved package.json
      Done in 0.05s.
    babel-size-check yarn add babel babel-core babel-eslint babel-plugin-array-includes babel-plugin-transform-runtime babel-preset-node5 babel-register babel-runtime
    yarn add v0.16.0
    info No lockfile found.
    [1/4]   Resolving packages...
    warning babel@6.5.2: Babel's CLI commands have been moved from the babel package to the babel-cli package
    [2/4]   Fetching packages...
    [3/4]   Linking dependencies...
    [4/4]   Building fresh packages...
    success Saved lockfile.
    success Saved 80 new dependencies.
    ...
      Done in 1.94s.
    babel-size-check du -ch -d1
    17M	./node_modules
    17M	.
    17M	total

600MB is a huge exaggeration. Looks like about 34MB for babel-cli, babel-preset-es2015, and babel-preset-stage-0.

even once all the language features you want are in, Babel is amazing for other things such as optimizations, transforms, injecting assertions depending on environment, inlining stuff, static analysis, etc. If you use Flow its used to strip out annotations, and if you use JSX (not just in React) its great there too.

We get a lot of millage out of it even when our target platforms support all the language features we need. Your millage may vary.

buble is a good alternative - small and fast. Doesn't support all of ES2015, but it does support the examples in the article.

https://buble.surge.sh/guide/

Have used it in production and it's amazing.

Have you tried Minify(Babili) by the way?

Indeed. Are there any 'good' strategies for this (loading ES6 for supported browsers)? I imagine you'd have to do UA sniffing on the server side, and I suppose it's kind of a moot point if you're using React/JSX.

There's no need unless you need runtime-only concepts, like new string methods. Use https://babeljs.io/ to turn nice es6 into es5. (I imagine you already know this, if you're using react/jsx)

Just try to eval a sample of ES6 syntax you use, and if it throws error, load ES5 code. You'd need to feature check all the features that you use, to cover the browser versions with incomplete ES6 support.

Working on https://github.com/babel/babel-preset-env right now which should help with this

You should be using babel to serve all your target browsers. But you can still use ES2015 during development; it's an absolute joy.

If you're developing a desktop-only app (or you're making a native app for the mobile frontend) ES6 works pretty well.

At least I haven't received any complaint yet, and if you can optimize early on without any short-term cost then it's the best thing you can do.

Thank god Chrome and Firefox dominate the market.

For developing browser extensions I think ES6 is currently can be used safely (at least for Chrome).

Reply on news.ycombinator.com