Saturday, February 13, 2016

You Might Not Need Babel

Babel is great, and by all means use it if it makes it easier to develop your application.

If you're developing a library on the other hand, please take a moment to consider whether you actually need Babel. Maybe you can write a few more lines of utility code and forego the need to pre-process. If you're only targeting some platforms, you may not need anything more than plain old ES6.

At the very least, make sure you know what Babel is doing for you, and what it's not. Some developers believe that Babel is protecting us from a great demon of code complexity when, in truth, browsers and node are pretty easy to deal with on their own. Let's take a look at some of the strategies for not needing Babel.

ES5 is pretty okay: In the days when we used tables for layout and the debugger was named alert(), we would have been so grateful if JavaScript had the features that ES5 has today. If you truly need Babel you are not only a weak programmer, but also an ingrate. Face it, you don't yet understand why ({}+[])[2] === 'b' and you're already moving on to ES6.

Supported environments: With Babel you can mindlessly use any ES6 feature and run on any browser or version of node. To avoid Babel, track the progress of ES6 in all platforms and just use the features they all support. So, Node 4.x doesn't support modules, proxies, unicode regexp extensions, and destructuring. As ES6 support improves in each environment, simply return to all your older code and rewrite it to use the newly enabled features.

Shareable code: ES5 is the common denominator that lets developers share their work. It gives code a greater "reach" and makes JavaScript easy to consume via CDNs or package repositories such as npm. All that is overrated. If you can keep track of your supported environments, people who want to use your code can do it too. If ES6 features in their supported environments are not the same as yours, they can run Babel on it.

Performance: JavaScript engines have gotten really good at optimizing ES5 code. But hey, it's still ES5 and looks like something your mom or dad would have written. As Douglas Crockford probably said once, "It is much better to look good than to run good." Sure, ES6 can be a lot slower than equivalent ES5 but that doesn't make Babel an optimizing compiler. At least not on purpose.

New language features: Did I say ES6 above? I meant ES7. Yeah, ES7, the one with the new exponentiation operator that will cause a syntax error in your ES6 if it's not supported. Just avoid that. Oh, also avoid sweet new syntax like the proposed function-bind (::) operator since that doesn't work yet.

So in summary, You Might Not Need Babel in any of these cases:
  • You respect your elders and want to honor our shared ES5 heritage.
  • Your code just needs to run on Microsoft Edge, Chrome Canary, and Firefox Nightly.
  • Other developers don't ever want to use your code via npm.
  • The low native performance of ES6 features is worth the pretty code.
  • JavaScript features beyond ES6 don't interest you.

2 comments:

Malachii said...

FYI: ({}+[])[3] === 'b' is false since the array of chars has an index that is zero-based

in this case, ({}+[])[3] === 'j' or ({}+[])[2] === 'b' would be true...

"[object Object]"

[
'[', <-- index zero
'o',
'b', <-- index two
'j',
...etc...
]

otherwise great article!

Dave Methvin said...

@Malachii Thanks, corrected!