#ASKTHEINDUSTRY 32: Can one use just a subset of ES6 and stop worrying about filesize?
Transpiling ES6 to ES5 is something that I don’t like to downplay. It is far too easy to lose sight of the actual code that gets shipped to the user, because the final JavaScript that goes into your bundle is very different from the one you author. This isn’t a bad thing per se, we got used to this feeling with uglify and relied on sourcemaps for debugging for a while now; the difference, though, is that with uglify you are pretty much sure that it’s for the better: code gets optimized and reduced in size. With transpilation it’s quite the opposite: the file size increases.
For this reason, I usually give up on ES6 entirely on production code. I don’t like the loss of control, and surely I don’t like the increase in size.
A couple of days ago I challenged this belief of mine. I realized that, in most cases, ES6 doesn’t introduce new features (that would need to be polyfilled) but it simply adds syntactic sugar to things we have always had in ES5. In hindsight, that is probably the whole point of transpilation!
I realized that, in most cases, ES6 doesn’t introduce new features (that would need to be polyfilled) but it simply adds syntactic sugar to things we have always had in ES5.
I started testing things out in babel’s online REPL to actually gauge with my own eyes the cost of it. And I found out I could have never been more wrong in thinking it increases file size by default!
So many ES6 features transpile to the very same code I would write anyway if I were authoring that ES5 directly.
Let’s see some examples:
- In ES5 I would never use const, and use vars directly.
- In ES5 I would never use let, and use vars directly, changing the name of variables to simulate block level scoping.
- In ES5 I would never use arrow functions, and use regular functions.
- In ES5 I would never use string template literals, and use regular string concatenation with the ‘+’ opreator.
It just makes sense then, that babel transpiles those ES6 features into the ES5 equivalent. In other words, when you write an arrow function, babel replaces it with a regular function. No difference with what you’re doing in ES5 already.
Should I jump on the babel train at once, then? Yes. Maybe. With some grain of salt.
Not every part of ES6 is syntactic sugar. We’ve got promises and proxies, class inheritance and iterators, generators and weakmaps, and so on. These ones would need either a polyfill or decently big bunch of code to make it work. We should be very careful when choosing which parts of ES6 we want to adopt, and maybe stick to a subset of it.
I am going to experiment a little bit with this idea, but I am afraid that, without a proper enforcing mechanism (linting, maybe?), it can easily get out of control in teams with more than 2 or 3 people.
Without a proper enforcing mechanism (linting, maybe?), it can easily get out of control
I am going to retract on this technique and start to add in babel in my projects. I’ll see where this leads me. In the meantime, I would love to read your thoughts. Let me know what is your take on the whole cost of transpilation topic!
If you’ve found this post useful at all, press the ❤ button! I read each and every comment, so be sure to contribute to the conversation with your thoughts!
