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`;

@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.