Any reason to continue using plain strings in ES2015?

Question

My current coding style is to use single-quoted strings as a default, and use backticked template literals whenever I need to concatenate a value into a string.

But I'm now wondering what's the point in having two kinds of string at all? Maybe it would be better to stick to template literals for everything, for simplicity. Even if you're not actually interpolating a dynamic value into the template literal, there's still the other advantage that with templates you don't have to bother escaping literal quote marks (which occur way more often than literal backticks).

So I'm considering configuring my linter to warn me when I use plain quoted strings (single or double). Aesthetics aside, is there any reason why this would cause problems?

Answer 1

If your team uses backticked strings frequently enough for its benefits (template expansion, multiline strings, different escaping, tagged templates), then you'll probably make fewer mistakes by sticking with that one syntax. That's because (1) you'll be more used to those escaping rules, (2) you won't have to (remember to) change quotes and escapes when adding ${ } template placeholders, and (3) you won't digress to decide if it's worth converting a string literal. You'll also remember about tagged templates and thus be less likely to accidentally write a tagged string. You'll be in the rhythm of using backticked strings and they'll distract you less from everything else to think about.

On the other hand, if your team frequently touches library code or client-side code that mostly/exclusively uses ' and " string literals, then you'll need to remain cognizant of which source files require that syntax. Furthermore if you rarely use the new features of backticked strings, you might make fewer mistakes by writing backticked strings only when needed (although I wouldn't suggest switching a string back after removing placeholders).

Another factor is the level of support for backtick strings in your editor/IDE. Syntax coloring might reveal the ${expression} placeholders and template tags, making mistakes more visible. A refactor command might quickly convert between formats, removing one incentive to use backticked strings just in case you later add placeholders. OTOH if backticked strings confuse your editor/IDE, you might want to use them sparingly until fixing that.

[If we cared enough about the programming process, we'd test hypotheses like these, i.e. measure the alternatives.]