Does Babel Compile Backticks (``) to Quotes and Does That Make JavaScript Code Faster?

Babel will compile the ES2015 feature backtick literals using the transform-template-literals plugin

Backtick literals are useful for their ability to transform strings through variable interpolation, an alternative to string concatenation:

However, they were only added in ES2015 (ES6) and are thus not supported in any version of the old Internet Explorer browser.

Developers supporting IE or other older browsers need to compile or polyfill new features in order to use them while programming.

Enter Babel

Babel is a JavaScript tool that performs compilation (or transpilation), allowing developers to use the new ECMAScript features before they are broadly adopted by browsers or in order to support older browsers.

It is like a translation tool that translates JavaScript into ancient Greek.

Or ancient JavaScript, as the case may be.

Put another way, Babel converts next-gen JavaScript to browser-compatible JavaScript. And since backticks are a next-gen feature added in ES6, Babel can compile them to regular quotes using a free plugin.

How To Use Babel to Transform Template Literals

Babel can transform `foo${bar`} to “foo”.concat(bar) to support browsers that do not support template literals (Internet Explorer).

Doing so requires a Babel plugin called transform-template-literals:

Does Babel Speed Up Performance?

My recent tests about the speed of backtick literals in Javascript showed that string concatenation was slightly faster than variable interpolation in the jsPerf test environment.

So Babel sounds like a perfect solution — just strip the backticks automatically using the transform-template-literals plugin.

That simple change should help us gain some performance. Or will it?

Does Removing Backticks Help?

Now it is time for a speed test using jsPerf to measure JavaScript performance and answer the question:

Will compiling string literals using Babel make my code faster?

In the next section, I set up three tests comparing backtick (``) literals to string concatenation using the + operator or the .concat() method.

Of course, this is not an entirely scientific test, for the reason that actually supporting IE would require polyfills, and polyfills are probably slower than modern JavaScript without polyfills, depending on the implementations.

Supporting IE = Polyfills Too

Supporting older browsers using compilation and polyfills almost certainly results in slower code — or at least somewhat longer load times.

That is because polyfills are reimplementations of the new features, so they are more likely to be slower than compilation, which is like a translation.

That means that even if Babel helps performance regarding string concatenation, other polyfills could be slowing down the codebase.

And I did not even mention how slow those browsers’ implementations of JavaScript were 10+ years ago compared to modern JavaScript.

Now onto the results regarding Babel and transform-template-literals.

Tests Using jsPerf

I set up three code samples to compare the speed of variable interpolation using backtick or template literals vs. string concatenation:

Code snippet 1: Variable interpolation using backticks (``) — definitely the most readable, but is it slower?

Code snippet 2: Using the + operator theoretically works the same as using the concat() operator

Code snippet 3: Using the concat() operator is how Babel would compile the code using the transform-template-literals plugin

Results of the jsPerf Tests

What This Means About Babel

One thing to note is unlike my last speed test on JavaScript backticks, jsPerf decided to run this set in Firefox instead of Chrome. This is currently not a configurable setting through their awesome test suite.

But the results are basically the same: Any type of string concatenation runs at about the same speed in JavaScript, whether or not backticks are involved, and whether or not the + operator or concat() method is used.

So I should not expect Babel transpiling my backtick literals to quote strings to improve performance, though of course increased compatibility and not improved performance is the entire justification for using Babel at all.

Measurement Error Rules Everything Around Me

The cool thing about backtick literals is they really seem to be just as fast as any other quote literal in a modern JavaScript browser.

In fact, rerunning my recent simple tests, except on Firefox instead of Chrome, shows that interpolation is probably not slower at all, at least not enough to be worth optimizing for:

Chrome results — Chrome 76.0.3809 (Windows 7) — jsPerf

Firefox results — Firefox 69.0.0 (Windows 7)—jsPerf

Measurement error of ±1% means that concatenation and interpolation have identical performance in Firefox and probably in Chrome too.

Conclusion

Phew, after celebrating backtick literals in my recent article, I was worried that Babel was gonna make me look bad with a big advantage!

Actually, transpiling backtick literals probably makes no difference at all to the performance of your JavaScript code. One less thing to worry about.

To me, this just reinforces the idea that we should have open arms to adopt new features, especially because we have tools like Babel for automatically making our code more browser-compatible.

Also, I probably have a crush on backtick literals. But is that a bad thing?

Further reading

• Rajitha Abeyrathna demonstrates transpiling his ES6 code into ES5 using Babel with a great example in his 2018 blog post.

• Nicolas Johnson explains why web developers need Babel on his blog:

• Ryan Christiani wrote about backtick literals on CSS-Tricks.com:

• I wrote about the three advantages of backtick literals in The Bit Theories:

Dr. Derek Austin is the author of Career Programming: How You Can Become a Successful 6-Figure Programmer in 6 Months, now available on Amazon.