1.js

// All of the following are ways that template literals are *NOT* `strictly better` than " or ' delimited strings
// RE: https://ponyfoo.com/articles/template-literals-strictly-better-strings

// valid syntax, but doesn't turn on strict mode
`use strict`;

// invalid syntax
const x = { `hello world`: 42 };

// invalid syntax
const { `hello world`: a } = x;

// invalid syntax
import foo from `foo.js`;

The bottom 3 examples are invalid syntax so you won't have a shippable program. While it's important to know that this happens (and understand why this happens), I don't think they break the "strictly better" assertion.

I'm interested in whether template literals are strictly better, in places where you can use them. Using this criteria, you've caught a brilliant edge case with the first example.

Also, and this is just conjecture, but:

I could imagine that `- delimited strings might end up being deferred in their processing until run-time (even if they have no internal tokens) instead of being processed at compile time.

@colingourlay

The bottom 3 examples are invalid syntax so you won't have a shippable program.

That's precisely my point. The article advocates, essentially, a find-n-replace (not exactly). Moreover, the article claims that wherever you could use a " or ', you should be using ``` because it's always "strictly better" there. I'd say using them in any of the bottom 3 fails as "strictly better" since doing so means you have a broken program.

The article even goes so far as to say, don't ever use " or ' strings. Clearly, this advice is not sound.

in places where you can use them

Had the article caveated its advice with that nuance, I wouldn't have brought the bottom 3 of them up. It didn't, which is part of my complaint.

@getify

I can see someone reading the article and being motivated to do a (non-automated) find-n-replace, but I didn't feel like that's what Nicolás was advocating.

You can gradually upgrade code like the above into interpolated expressions over time, getting to a more consistent code base.

I know people ship broken programs all the time. Such is the nature of a language that is 100% runtime errors. But if you ship a broken program, it's not because liberal usage of template literals is ill-advised, it's because you have no quality control process and/or don't realise without understanding that a isn't _always_ a .

Re: the " and ' advice: I think we're on the same page when I say that "never use this thing (except in the places where you absolutely must use them)" is pretty bad advice, as we've already been down that path with semicolons.

I really hope Nicolás updates the post with these caveats, as they're a great lesson, and an even greater jumping off point for those wanting to understand why your examples break programs.

@getify P.S. crying

Added a note about use strict. While I wasn't concerned about it, you guys raise a valid point about people mistakenly changing 'use strict' directives.

I don't think invalid programs count, though. In my mind that fits the same scenario as JSON requiring ". It's just an artifact of a progressively designed language. Any linter will catch these invalid programs and if you're using something like Atom's or Sublime's built-in linters then you will hardly even scoff.

@bevacqua

With all due respect, what your article is saying is, "use backticks everywhere because they're always better" and then letting unsuspecting devs stumble (with linter errors) to figure out several places where they're invalid.

I wasn't claiming that tools wouldn't/couldn't find such errors. I am claiming that it's a poorer learning experience for them to learn by breaking code (which can just lead to more frustration) and having to back track. I prefer to teach by affirmatively telling learners what to look out for, not letting them accidentally figure out the exceptions to what I taught.

Moreover, those 3 examples aren't just contrived edge cases... I use string literals in all 3 places regularly (well I don't use modules yet, but will), so I bet readers of your article will probably run into them quickly and often.

I use string literals in all 3 places regularly

You regularly write invalid programs?

@bevacqua

I said string literals not template literals. The point is that if (like me) many people use regular strings in those places (which is valid) and they just start changing all strings to templates as you suggest, they're going to accidentally discover these cases the hard way.

If I didn't know these cases already, and I followed your blog's advice and then tripped over these cases, I'd be frustrated that the advice was less-than-complete, lacking nuance/context, and/or border-line link-baity & disingenuous.

Just to be clear, my feedback isn't for you to rewrite your article or even change its conclusion. It's to add caveat/clarification to your "strictly better" claim that there are multiple cases in valid reasonable JS (not just JSON) where backticks aren't legal.

Take that feedback as you will. I'll drop the subject.

I have to agree with @getify. I ran --fix on my React repo and was surprised by how many strings were not converted: module imports would be invalid, and JSX props require a {} wrapper around template literals.

For now, it's easier (for me) to just use backticks when I need the features of a template literal.