I've always been skeptical of the JS community's mania for Babel plugins and compile-to-JS languages, and honestly, working with the Mastodon codebase and trying to shrink a 2.6MB JS bundle, I feel like my worst fears have been realized.
I've decomposed all of Mastodon's Babel presets into these plugins. If I remove a single one, I get some inscrutable error apparently caused by some other plugin in the pipeline. Feels like a big Jenga tower. 😞 #MastodonPerf
In my ideal world, we'd have two bundles:
1. ES6 without polyfills (for modern browsers)
2. ES5 fallback (using a "cut the mustard" test like fetch+Object.assign+etc.)
At this point I can't even figure out what the savings would be for #1 vs #2 because I can't get the codebase to compile *without* the Babel transforms. I wanted to try Rollup and/or Bublé too but those just feel off the table given all the JSX/spread/rest/decorators fanciness. Feeling like a JS curmudgeon here. #MastodonPerf
Like, in 99.9% of my JS projects I use vanilla ES5 and *maybe* ES6 modules, but only because then I can use Rollup to compile down to the smallest possible JS, which I then ship to consumers.
Performance is a top priority for me, and I just don't feel like syntactic sugar like arrow functions, template strings, const/let, etc. are so important that it's worth shipping a bunch of polyfills and transpiler bloat to my consumers. But I feel like I'm in the tiny minority on this one. #MastodonPerf
@Pierre Mastodon takes 15 seconds to load on a mid-range Android phone on 3G. Most of it is due to the JS bundle size: https://toot.cafe/@nolan/251039
Something somewhere needs to give. "No raindrop believes it is responsible for the flood." 😉
@nolan yes, and it is a good candidate for improvement because it often is a smell that the bundle had never been analyzed in a critical way.
However the next step (what you did) is to "remove the unnecessary"... which is where too much optimization could lead to less readable and maintainable code.
On a team this step is easier to achieve than in an open source project though.
For instance in my team arrow functions and spread operators might stay, and immutable would be removed.
@nolan I agree, I tried Bubblé / Rollup on side projects, however I am a bit reluctant to use them for bigger projects with other developers working on it and without the possibility to spend too much time maintaining the tooling over the month.
Do you have experience of Bubblé in production on large systems?
Nolan Lawson
Pierre Martin 🍵