Investigating the overhead cost of compiled ES2015


There are a lot of tools to compile es2015 to es5. When choosing your compile stack you should be aware that tools that perform tree shaking and topological sorts of your code dependencies will result in smaller code bundles and faster js execution times.

###Summary of findings:

Ignoring the outlier of traceur, people should heavily consider using a tool that does tree shaking (removal of unused code) and topological sorting of dependencies (ordering the dependencies so that you do not have to worry about import wrapping code). The difference between the final output size between a tool like browserify and rollup can well over 20%, even for a trivial app like TodoMVC.

I’m not really a hardcore Javascript developer (having just got into it when Meteor launched) and I’m not sure what Meteor is using in 1.3 (or aiming to use).

it’s worth noting that since this benchmark babel released v6.5, which is waaaaay faster. webpack@2 with babel@6.5 is a pretty solid solution. In development, you can use source-map alternatives (like eval) & leave out the uglifying step for a really fast build. After all, does anyone care how big their development payload is? Or that their production build took an extra 2 seconds? I only care about build time in development and size in production.
For example, I’d rather download 50Kb per route instead of a one time dump of 500Kb on the landing page, so the gzip size is kinda irrelevant for tools that can break up routes. I like what the author did & think a visual like this is real useful to point out glaring anomalies, but all these tools do very different things. It’d be more useful to see something I care about, like “build time in development mode” or “time to paint above the fold” and fine tune each tool to do what it does best.