Closed mattcollier closed 4 years ago
I can only assume there's overhead when backticks are encountered that isn't otherwise there. I'm -1 to allowing backticks when there are no variables to process in the string and +1 to just doing strings in one consistent way in that case: single quotes. No reason to have extra options for the same thing here, especially when the only difference is one option has unnecessary overhead without any other perceived benefit in readability, etc.
There's a blog post for that: https://medium.com/javascript-in-plain-english/are-backticks-slower-than-other-strings-in-javascript-ce4abf9b9fa
Yeah, I get different results on my machine and in different browsers. I suspect the difference is largely in the noise. But, as I stated, with no benefit articulated for doing the same thing in two different ways, let's go with the way we (and most others) have already been doing it: single quotes.
looking into this, so far it looks like the need for this rule has not come up in eslint. There was an issue raised: https://github.com/eslint/eslint/issues/12866
but it did not make it the rule stage
It might be possible by setting this: https://eslint.org/docs/rules/no-implicit-coercion
i.e. not allowing implicit conversion to a string in favor of String(x)
however I don't think that would catch backtick foo just ${x}
https://eslint.org/docs/rules/no-useless-concat
does not cover it
I've been experimenting with permutations, but so far nothing covers it.
OK, thanks for investigating @aljones15, we'll just accept this as convention. No backticks for string literals.
It is my position that backticks and single quotes are interchangeable in this case.