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.

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.

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

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

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

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.

    du -ch ./babel*

    3.2M	total

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.

> 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 [email protected]: 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

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.

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

Have you tried Minify(Babili) by the way?

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.