Skip to main content

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.

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!
John Slegers said…
I don't need Babel because I prefer to avoid languages features that aren't supported by IE10 and I prefer to use polyfills whenever I make an exception. There's little in ES6 or ES7 that you can't already do with ES5.

Popular posts from this blog

Tragedy of the WebKit Commons

With Opera announcing that their future products will be based on WebKit, the Internet is abuzz with discussion about what that means and whether it's a good thing. Looking at it as a jQuery developer, it's a good thing if it gets WebKit participants to fix bugs and update older implementations. I can't be optimistic without some evidence that things are really going to change. We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging:  "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions."  I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different. Opera did  land their first WebKit patch  so they wanted to make a statement that they weren't gettin

Please Stop the jsPerf.com Abuse!

According to many of the tests on jsperf.com , jQuery is slow. Really slow. The jQuery team gets bug reports from web citizens who've discovered these egregious flaws via jsperf and want them fixed. Now, jsperf.com can be a great tool when used knowledgeably, but its results can also be misinterpreted and abused. For example: Why doesn't jQuery use DOM classList for methods like .addClass()? There are at least three good reasons. It doesn't make any practical performance difference given its frequency of use. It complicates code paths, since classList isn't supported everywhere. It makes jQuery bigger, which makes it load slower for everyone, every time. But this jsperf shows classList is much faster! How can you say that? Well it's possible that test is running afoul of microbenchmark issues , and not measuring what it is supposed to measure due to the increased sophistication of today's JavaScript compilers. This is a big problem with a lot of t