Provide information to users about code size, speed, etc

[hzoo]

Twitter thread: https://twitter.com/TheLarkInn/status/832756703275855874

dude idea just popped in my head. Babel transpiled bloat calc.
es20xy =>es5 should output the size increase pre to post and break down by transform.
then the user better understand the worst transforms IE 'async-await' and maybe hold that sugar
Nice addition to a workflow using preset-env

• size of the code before and after the transform(s) per file (that seems easy)
  • not sure about the "break down" by transform since for that you'd need to individually do each one? sounds like a lot of time/work

Goals (that I would want)

Babel is basically there to transition users: allow us to write the future now (while being fast and correct) so that when it's natively supported it's easy to not compile those features (via https://github.com/babel/babel-preset-env).

Summary: don't use certain features until native is fast enough or help Babel be faster in those ways.

• People understand that using ES6+ has tradeoffs (whether it is native or compiled by Babel), and thus make decisions on using certain features or < Stage 4 features.
  • https://twitter.com/benjamn/status/832968859544064001, https://v8project.blogspot.com/2017/02/high-performance-es2015-and-beyond.html
  • Native ES6+ will be slow until optimized (and v8 needs to figure out what to prioritize so maybe we can help in some way here)
  • Compiled ES6 obviously incurs an increased code size and parse time (and debugging experience isn't fun)
• People would maybe actually read the compiled output and rather than just complain how much it sucks or is big maybe look at the source code and help us out? (Maybe not emphasizing enough how little resources we have as a project at this point, and there's probably lots of low hanging fruit to fix since we have never really focused on perf other than when it's completely bad). Sorry if it comes off as biased 😄
• We figure out how to balance options vs defaults (loose, spec, other options)
  • The issue is that we have to be as spec compliant as possible but also not be too slow (which is basically impossible in JS). And when we start adding options then we get more js fatigue which sucks.

Current

Code size: don't recall anything
Time to compile: Sebastian made #3659 a while ago (mostly undocumented), and the only time I've used it was in Babili babel/minify#91, babel/minify#93

cc @addyosmani, @TheLarkInn, @bmeurer?

[TheLarkInn]

Reason as I brought this up as a babel-specific feature is that although webpack can access pre and post source size via github.com/webpack/webpack-sources code, it would be a weird integration on our side to add for just babel inside of webpack. I think a good initiative for us would be to some how just show some informative +% or -% in code size in general when changes are made, etc.

[bmeurer]

Thanks for taking the time to write this down. I think preset-env is already a very good step in the right direction. But for heavy stuff like async-await that will not help for some time, so adding some mechanism to inform users about code size tradeoffs might indeed help, whether it's in Babel or in Webpack.

[yavorsky]

Also would be cool to have util to compare code size with preset-env) vs preset-latest (preset-env with all plugins). People could see actual benefits of specifying targets and play with it's configuration to understand how each supported browser affects the bundle size.

[addyosmani]

size of the code before and after the transform(s) per file (that seems easy)

I think exposing the before/after per file would make sense. Let's explore that initially? I believe break downs by transform would be pretty costly, even if you did this in the background. Perhaps explore how much value users get out of the per file top-level before/after first?

People understand that using ES6+ has tradeoffs (whether it is native or compiled by Babel), and thus make decisions on using certain features or < Stage 4 features.

There are a few different directions we could get more intelligent with this.

• If you're using preset-env and browserlist, we know what browsers you're targeting.
• If we know target browsers, we can look these up in the six-speed tables
• we can compare the transforms for features you're using to the browser speed of features in six-speed
• Give you a report, broken down by browser?, of whether it would be faster or slower to not transpile and just use native
• For most developers, I imagine they'll want the actionable advice here too. E.g recommendation: disable the async-await transform as it is faster without it. You can do this by doing foo.

[toomuchdesign]

Hi you all here, if there's anybody still listening.
Following this thread I put together a Babel performance measurement tool based on wrapPluginVisitorMethod api. I called it babel-timing.

It can run standalone or hook into external tools (like bundlers or test frameworks) to extract infos about how they use Babel.

Webpack and Jest integrations are already available.

Any feedback or idea would be extremely welcome.
Greetings!