39

Is there a reason (performance or other) not to use backtick template literal syntax for all strings in a javascript source file? If so, what?

Should I prefer this:

var str1 = 'this is a string';

over this?

var str2 = `this is another string`;
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
Joshua Breeden
  • 1,844
  • 1
  • 16
  • 29
  • 4
    The token replacement operation is not free, you know -- even if there are no tokens to replace. – Frédéric Hamidi Jun 12 '16 at 18:28
  • 2
    Is that seemingly small performance penalty reason enough to alternate between different syntaxes, though? – Joshua Breeden Jun 12 '16 at 18:35
  • 1
    I believe so. Use the right tool for the right job. There is also the issue of having to escape the embedded tokens if you want the string to contain them verbatim. – Frédéric Hamidi Jun 12 '16 at 18:41
  • Thanks for the perspective! – Joshua Breeden Jun 12 '16 at 20:27
  • if you are using babel js, you are gonna end with a transpile code with the form of `'' + ''` syntax so for brevity and easy way to code I think using template literals is a better approach. – ncubica Jun 12 '16 at 20:49
  • you should rephrase your question to "Is there a downside to using ES6 " at all in your production code at this moment. – Bekim Bacaj Jun 12 '16 at 20:55
  • 5
    The code will be easier to read if you only use template literal syntax when actually required, because then you can tell at a glance which literals are supposed to have token replacement and which aren't. – nnnnnn Jun 12 '16 at 20:57
  • It seems that there actually is no performance difference, or at least the difference is so miniscule that it's not easily measurable: https://jsperf.com/es-string-vs-template. I wonder how this is possible, since I would think the parser has to check for either `\`` or `$` for every character in a template literal, whereas for a non-template string it only needs to check for the closing `"` or `'`', but I can't argue with actual benchmarks... – Matt Browne Jan 04 '19 at 01:26

5 Answers5

19

Code-wise, there is no specific disadvantage. JS engines are smart enough to not have performance differences between a string literal and a template literal without variables.

In fact, I might even argue that it is good to always use template literals:

  • You can already use single quotes or double quotes to make strings. Choosing which one is largely arbitrary, and you just stick with one. However, it is encouraged to use the other quote if your string contains your chosen string marker, i.e. if you chose ', you would still do "don't argue" instead of 'don\'t argue'. However, backticks are very rare in normal language and strings, so you would actually more rarely have to either use another string literal syntax or use escape codes, which is good.

    For example, you'd be forced to use escape sequences to have the string she said: "Don't do this!" with either double or single quotes, but you wouldn't have to when using backticks.

  • You don't have to convert if you want to use a variable in the string in the future.

However, those are very weak advantages. But still more than none, so I would mainly use template literals.

A real but in my opinion ignorable objection is the one of having to support environments where string literals are not supported. If you have those, you would know and wouldn't be asking this question.

Timo Türschmann
  • 4,388
  • 1
  • 22
  • 30
  • I believe this to be the most useful answer, and it is what I was looking for. Do you have any actual stats/proof to back up your claim that there's no performance difference between string literals and template literals with no interpolation? Also, regarding the use of single/double quotes when needing apostrophes, I always use single quotes and use the actual right-single-quote character for an apostrophe, i.e. `’` which is usually more appropriate for presentational text strings anyway. – spikyjt Jan 29 '21 at 14:14
  • @spikyjt I had a JSPerf at the time I made this answer, but I can't find it anymore. A quick google search gave this though which comes to the same results: https://medium.com/javascript-in-plain-english/are-backticks-slower-than-other-strings-in-javascript-ce4abf9b9fa – Timo Türschmann Feb 03 '21 at 16:20
15

The most significant reason not to use them is that ES6 is not supported in all environments.

Of course that might not affect you at all, but still: YAGNI. Don't use template literals unless you need interpolation, multiline literals, or unescaped quotes and apostrophes. Much of the arguments from When to use double or single quotes in JavaScript? carry over as well. As always, keep your code base consistent and use only one string literal style where you don't need a special one.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • 19
    Downvote because the OP would not ask this question if he was not already using backticks (and with that ES6). On top of that you talk about consistency while advising two styles of quotation. Your answer does not seem to have a compelling argument to not use backticks all the time and it does not highlight the trade-offs of using one versus the other. – EECOLOR Jul 26 '18 at 19:24
  • 4
    @EECOLOR There are really no arguments specific to template strings other than that they were introduced in ES6 (which is indeed not very compelling any more in 2018), the trade-offs are very much the same for every quote style. That's why I linked the other question - you can find some explicitly spelled-out arguments in [this answer](https://stackoverflow.com/a/18041188/1048572). – Bergi Jul 26 '18 at 19:31
  • 1
    Consistency > YAGNI – DollarAkshay Sep 29 '21 at 22:25
7

Always use template literals. In this case YAGNI is not correct. You absolutely will need it. At some point, you will have add a variable or new line to your string, at which point you will either need to change single quotes to backticks, or use the dreaded '+'.

TigerBear
  • 2,479
  • 1
  • 21
  • 24
1

I'm fairly convinced by other answers that there's no serious downside to using them exclusively, but one additional counterpoint is that template strings are also used in advanced "tagged template" syntax, and as illustrated in this Reddit comment, if you try to rely exclusively on JavaScript's automatic semicolon insertion or just forget to include a semicolon, you can run into parsing issues with statements that begin with a template string.

// OK (single (or double) quotes)
logger = console.log
'123'.split('').forEach(logger)

// OK (semicolon)
logger = console.log;
`123`.split('').forEach(logger)

// Not OK
logger = console.log
`123`.split('').forEach(logger) // Error
MattTreichel
  • 1,418
  • 3
  • 18
  • 35
0

Be careful when the values are for external use. We work with Tealium for marketing analysis, and it currently does not support ES6 template literals. Event data containing template literals aka string templates will cause the Tealium script to error.

sb333
  • 37
  • 5