Does compiling JavaScript code using Babel make backtick literals as fast as regular quotes?

New research shows that backtick literals and regular quotes have the same performance in JavaScript

Does using Babel to compile next-generation JavaScript code improve the performance of backtick literals compared to quotes?

My recent article examined the question of whether backtick literals are slower than quote literals in JavaScript — they aren’t.

I found that backticks may be a little faster when being created, and they appear to be just a little slower when variables are interpolated.

That means, in the case of variable interpolation vs. string concatenation, using the older quote style could perform a tiny bit better.

It led to the following great question, written in response to my article:

“Doesn’t transpiling code (by ex. Babel) nullify any performance differences?” — Michał Bargiel

Thank you Michał this is a fascinating question!

On its face, this would make a lot of sense — Babel will replace all of the backticks with quote literals and string concatenation.

I wrote a whole follow-up article in trying to answer your question. The summary is that in this case, transpiling does not make a difference.

Check it out, and please let me know what you think:

I summarize this article in the next section if you want to continue on.

`Backticks are fine`

Here are the results of the above follow-up article, showing once again why I use backticks in my code — they improve readability of my JavaScript with the same performance as other quote literals:

Sometimes Babel is slower

This appear not to always be the case — obviously, some new features are going to be faster than their equivalent code in vanilla JavaScript.

Really the difference comes down to compiling vs polyfilling.

Compilation is a translation, so there is usually no performance hit.

Polyfilling is adding brand-new code, which may be slower — especially when the code is actually being executed in older browsers like Internet Explorer.

For example, I recently examined the performance of the ES2017 padStart() method compared to its MDN polyfill or a naive alternative:

It turned out that the polyfill’s performance is about 20% better than the Array method, but still almost 9 times slower than padStart():

Interested in learning more about padStart()?

Those performance results were taken from my new article about string padding in JavaScript. In it I explain the use of .padStart() and .padEnd(), two high-performance features added in ES2017.

Note — This article is published in my new publication, Coding at Dawn:

I already summarized the performance results above if you want to skip it.

One more `data point`

Brian Mearns also examined backticks using a shell script in response to my article. He found basically the same results — all of the quote literals have the same performance in JavaScript, so it doesn’t matter:

Wrapping up

It seems that it really does not matter which quote literal I choose to use in my code, although backtick literals have some advantages, as I wrote about in The Bit Theories:

Tyler McGinnis has a great video on his blog about backtick literals:

Personally, I probably have a bit of a crush on backtick literals:

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.