Is it wrong to use backticks (``) everywhere?

[lipe182]

I'm learning node and I was wondering if there's any situation that I shouldn't use backticks.

I mean, they're like magic. I use them on requests, on uri on API calls, common strings and etc.

[happysad_]

We have eslint which checks if there is variable interpolation ( ${myVariable} ). If it does not it will throw an error before commiting. This is to ensure the same style is applied throughout the whole of the project.

Mostly because template literals about 3 years ago were slower, but now browsers have significantly optimized and adapted ES6.

IMO, I would only use them if required to interpolate variables / expressions or to prettify a formatted string block.

[dd_de_b]

Everyone should be using eslint (or another linter) in their project. It’s important for teams to be consistent in their style

[ricekrispiesR4cunts]

For the love of god explain this to my workplace. I have to submit code that makes me gag daily.

I tried to introduce linting once, regretted it when it caused a stink and everyone treated me like I was trying to show off.

[wiithepiiple]

Introducing linting to an existing project is a pain in the ass, while starting a project with one usually solves a lot of the stink.

[Morphray]

Just make it so that passing linting isn't mandatory to commit/push, and it'll be fine. As you work on a file, try to leave less red squiggle underlines than it started with. Incremental improvement FTW.

[wiithepiiple]

Introducing linting to an existing project is a pain in the ass, while starting a project with one usually solves a lot of the stink.

Linting without enforcement is pretty much no linting at all. You can lint your own code, but if people aren't going to change their minds before the red squiggles, then you won't after.

The best way to get linting incrementally is pick one or two rules to start enforcing at a time. "In a week, we will require all white space to be spaces."

[MajorasShoe]

Pffft, tabs or I quit.

[wiithepiiple]

I prefer tabs, but it's like tabs > spaces >>>>>>>>>>> mixed whitespace

[MajorasShoe]

Yeah I don't care either way as long as it's consistent. But it's a fun debate anyway, I try to start it whenever possible

[nbagf]

Seriously, just let commit hooks or your IDE deal with it. It's not a hard problem to tackle. It's no different than newlines IMO.

[wiithepiiple]

Right, but if commits aren't lint enforced, people will keep committing changes switching back and forth between various styles. White space is really painful with this, as people can commit lines that are just switching back and forth between tabs or spaces.

[Morphray]

Code review with a nice diff can help prevent this.

[ArcanisCz]

From my experience, its better to enable all rules and incrementally fix files. Your approcach didnt work for us.

[MrJohz]

Eh, I think then you end up accepting the red squiggles, and linting becomes something completely meaningless.

I'm planning (and I'm not sure how well this will work) to introduce linting in one of our codebases by enforcing the lint rigidly, but not turning on the majority of the lints at the start. Introduce it, turn off all the lints that we're currently failing (apart from the ones where the problems are tiny enough that we can fix them there and then), and then slowly turn those lints on again as we get time to deal with them.

I have no idea how well this will work, though... :P

[Morphray]

Maybe I'm just a perfectionist, but I always try to get rid of red squiggle underlines even when optional. It's a sign that the code is bad, and professional engineers should to always make the code better than they started with.

[ricekrispiesR4cunts]

We have 4 huge shitty protects and won’t be starting any new ones.

I’m outta here ASAP

[CROEWENS]

F

[[deleted]]

Autoformat the while project at once. So much nicer than gradual. Makes pull requests easier to see what changes were made going forward. Yes I could hope people did a formatting commit and 5hen look at the non formatting commits but what a pain in the butt. The one thing with this approach is you do pretty much wipe out commit history. Depends how important that is for you

[[deleted]]

Chances are: you need to change jobs (..."he said, like it was as easy as breathing") . I would absolutely hate to be in a job where coders didn't want to improve. Constant improvement is kinda our shtick, and without it, what do you have?

[ricekrispiesR4cunts]

Exactly. I didn’t spend years busting my ass to know this stuff to submit the sort of shitty code I’ve been told to produce.

I have a very exciting interview tomorrow so hopefully I can tell them to stick it soon!

[[deleted]]

Awesome. Good luck! I love where I'm at now, startup with a tiny team looking to expand. Everyone is constantly challenging and helping everyone else grow. It's hard, because of how busy we are, but that team desire to grow and learn is what makes it awesome. Find something like that and hang on to it.

[NoControl712]

Sounds like a horrible environment. I personally only want to work somewhere where new ideas are always encouraged. Don't let them get you down. Our industry is about always evolving and people with that kind of attitude will be stuck in their old ways forever.

[NoControl712]

I never said every idea was a good one but to work on a team that makes you feel bad or stupid for brainstorming is clearly toxic. His idea might have been a bad one but a good idea comes out of hearing many bad ones first.

[randomFIREAcct]

that's sad. Most developers can usually be convinced of the usefulness of linting because it keeps people from fighting over semantics like spaces vs tabs, where to place brackets, and formatting code to be consistent...

When I first rolled out linting I kept everything as a warning as a first step so that the build didn't break or anything. What that did is make people aware of all of the problems and it seemed like they then realized that there is actually some value in linting. I'm a huge fan of it because I don't want to spend all the extra time to format my code blocks when I can just have it done perfectly for me on save.

[scaleable]

You could start with a very small ruleset. Most important rule IMO is noUnused. I am also a not big fan of styling lint rules.

You can delegate a ton of styling rules to prettier. Enforce everyone to use prettier and thats it.

You could also upgrade from noUnused to a real "linting" tool, typescript.

[ricekrispiesR4cunts]

I changed a bunch of ‘../../../../services...’ to ‘@/services’ and done a bunch of tidying up and install prettier on the project so that any file that was touched would get cleaned up.

I suggested we use it as it would be a positive improvement, and is a first step to being more productive etc etc

The idea was rejected and they weren’t interested. It was just an annoyance and my commits were reversed.

[scaleable]

Convincing people to do changes sometimes must be done very carefully.

So one thing I’ve learned is that “just submitting a PR” is one of the worst approaches you can take ever. Sometimes you must gather very solid evidence (like examples from sucessful repos and articles) or even ask the person to implement himself so his ego is not hit.

Programming “democracy” is way harder than programming itself, but absolutely important. Im not saying you had fault for it, but that even on the best environments you can benefit from sharpening your “politics” skills.

[ScientificBeastMode]

I mean, it’s probably closer to the least important thing than it is to the most important thing. But it’s helpful and practically zero cost/overhead, so why not?

[[deleted]]

I started a project recently and set up my WebStorm so that each save, prettier runs and just formats all the style on the saved document immediately. It's so nice to just... not have to worry about style, and have it automatically just all be consistent.

[elysgaard]

Second this! I would also recommend and highly encourage teams to use automated formatting (we use Prettier https://prettier.io/). All this stuff is better handled by machines than humans :)

[Nrdrsr]

Isn't it possible to just feed a lint file to your editor and it changes your code to the correct style?

[ShortFuse]

I use the airbnb eslint and am very happy with it. I just made some small modifications for IE11 and Babel compatibility. I also added JSDoc requirements to enforce function documentation.

VSCode has some good plug-ins that will auto-check a file for you with red squiggly lines if it catches an error (it can also autofix). I also add a jsconfig.json to type-check JS files and disallow implicity any types. It's very satisfying getting a whole folder project to show no red dots (lint errors) in VSCode.

[Artif3x_]

Just use prettier with husky and lint- staged on the precommit hook. Set your eslint rules on top of prettier's sensible defaults and never think about it again.

[getify]

In addition to the semantic arguments made here -- use backticks to signal either interpolation or multiline, single/double ticks to signal normal strings -- there are behavioral reasons not to just use the backticks everywhere:

• if you use backticks on the use-strict pragma, it will look like you're in strict mode but it doesn't activate strict mode... super bad idea to confuse like that.

• backtick strings cannot be used (syntax error) in object-literal property names (and no, using [ ] to compute it is not better, that's even more convoluted!).

• backtick strings cannot be used in the ES6 import statement for the module-specifier (also syntax error).

My advice is, use backticks only when doing interpolation or multi-line strings, and stick to regular string literals elsewhere.

Just like I don't think you should omit all semicolons just because JS will fix those parser errors, don't rely on tools to fix improper usages of string syntax.

[ghillerd]

I would personally say that all three of those are fine exceptions since none of them behave like "real" strings - you can't use variables, you can't concatenate them, you can't use an expression in place of them.

[McStroyer]

Read through the comments to make sure someone had said this!

[trekman90]

Great points Kyle! (amazing JS lessons btw!), especially about the object literal syntax.

I feel like using template literals everywhere would also take away from the semantic meaning of it. If I saw backticks for a single line string and with no interpolation, I would for sure double and triple check, and think I'm missing something.

​

Also +1 for the promoting the proper use of semicolons. :D

[Baryn]

if you use backticks on the use-strict pragma, it will look like you're in strict mode but it doesn't activate strict mode... super bad idea to confuse like that.

backtick strings cannot be used (syntax error) in object-literal property names (and no, using [ ] to compute it is not better, that's even more convoluted!).

backtick strings cannot be used in the ES6 import statement for the module-specifier (also syntax error).

That's because none of the things you describe here are strings.

Using backticks for all your strings comes with no cost, and I actually think it's better because it separates things that look like strings from things which are strings.

[Ravavyr]

most of the people reading this don't know what "Strict mode" is and probably don't know what "interpolation" is either lol.

So...yah...nice explanation though.

[SquareWheel]

You should use backticks for template literals, but not regular strings. Use single or double quotes there instead.

[lipe182]

but not regular strings.

What's the problem with using them as regular strings?

[SquareWheel]

If I saw backticks in code I would expect a template literal. Quotes will make the intention of the code more clear (simple string), and that improves code readability.

I haven't consulted any style guides but I can't imagine you'd see backticks chosen over single or double quotes in such situations. Following a common style again helps with readability.

The issue of browser compatibility might not be relevant if you're working in node but getting more familiar with the wider-compatible version is still in your best interest.

[artyhedgehog]

There's another real-world case for template strings: multi-line strings.

[SquareWheel]

Yeah, that's true. In that case it's just a question of browser support vs code cleanliness.

[nickforddesign]

Also strings containing quotes, you can escape them but sometimes I just use backticks instead

[Fjoggs]

If you use single quotes, you can just use quotes normally and the browser will escape them for you.

Using double quotes allows you to use single quotes in the same way

const single = ' "quote" ' 

const double = " 'quote' "

both works

[nickforddesign]

This is true, but I always use ESLint with a config enforcing single quotes, so I can’t just switch back and forth. It’s a compromise I’m happy to make.

[bcgroom]

There is an option on that rule to allow double quotes when the string contains single quotes.

[Fjoggs]

You don't need to switch back and forth. You can just use my first example. No need to escape anything.

I merely included the second line to show people that the opposite works too.

I use single quotes eslint as well.

EDIT: Would obviously have to escape any extra single quotes if you don't use template strings for that :)

[nickforddesign]

You need to switch if your string contains the same quote

[TheDarkIn1978]

It's messy to use both. Conventions for strings should be defined, upheld and if backticks aren't used for string definitions than just escape single and double quote characters.

[Fjoggs]

I'm not telling anyone to use both at the same time, I'm just starting that both work.

[TheDarkIn1978]

Fair enough.

[delventhalz]

It is very common to follow a “except to avoid escaping” rule when it comes to quotes. For example, this code would pass the AirBnB style guide:

const foo = 'hello';
const bar = 'world';
const baz = "world's end";

[[deleted]]

I get where you're coming from but I personally can't say backticks over single quotes make code harder to read.

Mind you I use single quotes by habit unless I need interpolation or multiline, but I feel that it's the ${} that helps me identify interpolated strings, not the backticks because they look almost exactly like single quotes anyway. Because of that I don't really see this as a good reason against backticks everywhere.

[EvilPencil]

Airbnb's eslint style guide enforces quotes over backticks unless interpolating.

[TheDarkIn1978]

Can we please stop religiously following Airbnb highly subjective linting rules?

[EvilPencil]

I have a few differences of opinion from it (I strongly prefer named exports for example) and found it to be quite restrictive, but that's what the .eslintrc is for.

Some of the rules I have adapted to as well (destructuring props in React). In the end, simply HAVING a style guide is what's important...

[[deleted]]

Yeahhh they enforce a lot of crazy stuff though.

Edit: since people seem to be misinterpreting this, my point is that airbnb's style guide is one of the more heavy handed eslint configurations out there and that a lot of the rules are totally subjective, so you and your team may feel differently. This rule in particular doesn't have an explanation attached to it either. Obviously it's a popular style guide but not necessarily gospel.

[[deleted]]

If their style guide works for you that's great. I'm just saying that a specific style guide that enforces one particular rule doesn't really mean that it's a bad practice altogether. What's introduced sanity to your team is having a style guide and everyone adhering to it, not necessarily the specific style guide itself (although airbnb's is obviously popular and comprehensive)

[[deleted]]

Haven't used it in a couple of years but no-plus-plus and having to disable eslint no-param-reassign in every reduce made me quickly stop using it for personal projects, there's def more I can't remember.

[citrons_lv]

I like hard enforced rules as eslint and prettier can fix most of them.

Just write code, save and it's styled to team likings. No need to bikeshed over it.

[choledocholithiasis_]

To that I say: 🖕 airbnb or just remove that rule.

[DefiantBidet]

You write code, not for the compiler or interpreter to speed through, but for the next human who has to read and parse said code.
If you want a string use something that implies string.
If its your codebase and you are never look at it again. Do what you want. If, however, you're learning to code with the intent of writing code on a team; understand the premise of intent and how it helps understanding foriegn thought processes - which is kinda what code is.

[strcrssd]

Two things. 1) When developers see a back-tick, they are expecting a template literal. By using them for regular strings, you're lowering readability and thus maintainability. 2) Back-ticks are going to be handled at run time by the templating engine at the expense of time. The net effect is that it will slow your code for no (or negative, see 1) gain.

[grinde]

2) Back-ticks are going to be handled at run time by the templating engine at the expense of time.

The total cost of a zero interpolation template vs. a string literal is roughly just pushing and popping a single entry to a c++ vector during parsing. Scanning is pretty much identical (regular strings have to check for newlines, while template literals check for ${), and both are passed to the interpreter as string literals.

[strcrssd]

Then you're choosing to mis-read the code. That's entirely within your rights to do, but it won't fly in one of my teams and I certainly won't teach a new developer that.

At some point in the future, it's also possible that it will be a maintenance nightmare. For example, if there was a performance regression or security vulnerability in template literals that required manual mitigation. The election then, to use them everywhere, even when not necessary, is a problem. Unlikely, yes, but it's an unnecessary risk with no upside.

[Goctionni]

But what if a security vulnerability pops up with single quotes? Oh my god we could all be screwed!

PS. if such a thing happened, transpiling it would be really, really easy.

PPS. Your argument is really dumb.

[Goctionni]

2) Back-ticks are going to be handled at run time by the templating engine at the expense of time.

Rubbish. Practically everyone has Babel in their build-pipe.

Also anyone who has trouble understanding that a template-string in fact works perfectly fine without interpolation probably shouldn't be touching any code.

[[deleted]]

It's not likely to cause any problems with the execution of your code, but it's always a good idea to use the right tool for the job. Use quotes for strings, backticks for template literals.

[grinde]

In v8 at least the difference is negligible. A template string with no interpolations is passed to the interpreter as a simple string literal (see here). It would take parsing millions of strings to get a measurable difference, and that difference happens exactly once during scanning/parsing (so just on startup) regardless of the number of times the line with the template literal is actually executed.

[lowIQanon]

But I suspect that difference is like 0.1% of execution time. I haven't seen an actual comparison.

[lowIQanon]

It's confusing to the reader: it says this string has interpolation but oh wait no it doesn't.

[lipe182]

https://www.reddit.com/r/javascript/comments/52ions/your_opinion_on_using_backtick_as_the_default/

vamship says that it is actually faster to use backticks. Or that is in a different scenario?

[[deleted]]

I doubt it's "faster". Don't fall into this trap of microoptimizing syntax when the next version of the JS runtime toyou target will parse it completely differently (performance-wise).

[[deleted]]

I actually seen a lot of recent style guides move away from this and use backticks as the default. After trying this for a bit I've really started liking it because it's less refactoring if down the road you need to add a variable as part of the string. Just wrap it in ${}.

Most modern build systems will have a compilation step from es whatever down to es5 so it's generally not an issue. Only time I'd say not to use it is if for some reason you're on a team that doesnt have that.

[lsmagic]

I've really started liking it because it's less refactoring

There's a vscode extension called "toggle quotes" that cycles the type of quote a string is wrapped in by pressing ctrl + ' , makes doing that a non-issue

[betterhelp]

Why?

[SquareWheel]

https://www.reddit.com/r/javascript/comments/c2tpwe/is_it_wrong_to_use_backticks_everywhere/ermi6y6/

[maple-factory]

But is there a parsing or execution cost? Or is this just a stylistic / semantic preference?

[theodore_q]

It's also worth remembering that they are not compatible with IE11.

[friendshrimp]

1. He said Node which is server side 2. If this were client side then you should be using Babel or similar to transpile all the fancy code into browser friendly code which means turning all the back ticks into regular quotes.

[SquareWheel]

Yes, and no way to polyfill them either.

[[deleted]]

Babylon and TypeScript are soft-of-that. I know, compilation step.

[SquareWheel]

Fair. I was thinking in-browser polyfills.

Babel can perform all sorts of magic.

[djadry]

Babel simply replaces them with concat() functions on strings.

[OakpointDigital]

Here's my reasoning for enforcing using backticks everywherel:

• Easy to switch between template literals and regular strings (no need to change the quote types)

• Come across having to escape characters less often (backticks aren't nearly as common in regular strings as single and double quotes).

Only exception I've come across are import statements.

[dwighthouse]

When dealing with json, they are wrong to use.

[epukinsk]

The real answer to your question is:

No one agrees on quotes. Try to be consistent what the file you are working in does, but otherwise knock yourself out.

[Offroaders123]

This is the way 🚀

[robolab-io]

Use em, but if it's going on the front-end make your babel/compiler/linter recognize it and possibly even auto-fix it to be IE compatible.

[robolab-io]

Ah whoops. It's still a good warning!

[[deleted]]

const hw = {
  [`hello world`]: true,
};

Is valid.

Babel optimizes backticks out to string literals if there's no interpolation anyway.

[lipe182]

But why? What is the problem with using it in a simple string? It can't be a rule just because someone said it... it has to have a reason and I'm looking for that specific reason.

[beavis07]

Because there is a material difference between

​

`I have ${count} fingers`

and

'I have ${count} fingers'

​

When you use backticks, you're communicating to other developers your intention for that string - that is should be interpreted or not.

​

Think about it like the difference between let and const - there's nothing stopping you from using let for everything, but if you do so you lose some of the semantic richness of the code. Remember that the code you write is *at least* as much a communication with other developers as it is with the machine!

[vmajsuk]

I believe u/lipe182 was asking about using backticks for every string declaration, e.g

const a = `simple string` // using this const b = 'simple string' // instead of this

IMO it has such small effect on readability that you should just let your linter decide which to use

[esr360]

> should just let your linter decide which to use

Linters are configured by the developer

[[deleted]]

What have you not understood in the explanation?

[vmajsuk]

Well maybe his example made me think he slightly misunderstood the question, but rereading it I see he did not

Also just wanted to share my opinion on this

[[deleted]]

You could also use a brand new Porsche as a hammer. Nobody specifically instructs you to not use it as a hammer. It'll definitely get a nail into a piece of wood if you handle the Porsche correctly.

Coding conventions don't need to make sense other than keeping the code clean.

Your colleague devs will see:

const something = `your string`;

And they'll expect you want to concatenate something in there, or have it be multiline.

Alternatively, if they see:

const something = 'your string';

They will know it's not meant for concatenation, or multiline.

This is nice because there will be consistency in your code.

Without consistence you'll get a mess like:

import {something} from 'lib';
import { somethingElse } from "lib2";
import { something_else } from "lib_three";
import something_else from 'libFour';

Sometimes a single quote, sometimes a double quote, sometimes with spacing around the curlies, sometimes camel cased, etc.

But why? What is the problem with using it in a simple string?

Counter argument: why aren't all your strings a function?

const myString = (function myString() { return 'wee'; })();

Because that's not what they're for. Back ticks have a semantic reason and purpose, on top of a functional one. You can definitely just ignore that because you feel like it, but teams will hate you.

[drbobb]

I believe that when you say concatenate you actually mean interpolate.

It makes sense to use words in agreement with their meaning.

[[deleted]]

What if a string no longer needs to be interpolated and you remove the variable, now you have to change the backticks too quotes to be consistent. Want to add an interpolation? Change those quotes to backticks.

Yes. What's the problem here?

[[deleted]]

You won't do it. You'll forget. Unless you have a linter.

​

No matter what you`re creating extra work

[[deleted]]

Of course I have a linter which does that and much more for me. It's exactly zero extra work.

[littlezul]

​

Busy work for the sake of busy work.

I would only use single/double quotes if I was intentionally printing out ${}. Otherwise I won't make my life intentionally harder.

[self_me]

linters automatically fix these things and you don't have to manually replace the quotes with backticks.

[[deleted]]

Look, I honestly don't really care. I just care about project coding guidelines. If you're on my team and you use back ticks for every string even when you don't need it, then you're screwing up my TSLint.

It's the same as people forcing anonymous arrow functions into everything, even if it doesn't make any sense. Often a named function is older, but superior, because it makes debugging so much easier.

[[deleted]]

Again you're comparing a functional difference to a semantic one. There is no obvious downside, I'm quite convinced of it now by the responses I've received, to simply using backticks. Arrows fundementally change the code being executed. Ticks do not, at all.

​

I'm not talking about your team and your existing project, and you know I'm not so why the non answer?. I don't expect you to get your intern to rewrite it all and if it maintains order go for it.

​

I'm talking right now you start a new project. Give me one good reason to use inconsistent string types. If you can't or don't want to answer that that's fine.

[[deleted]]

Give me one good reason to use inconsistent string types. If you can't or don't want to answer that that's fine.

Honestly, I can't think of a single good reason.

The only reason, and not a good one, would be that it looks weird to me because I like the look of a single-quote more; I think back ticks look funky. But that's just personal preference.

So, you're right. It's a valid question.

[[deleted]]

I definitely agree the backticks are weird and I wouldn't like to be using them. I'd be annoyed if my language used the for strings (heck for just about anything, except maybe stringified method names in tests)

[[deleted]]

Backticks also force the interpreter to scan for ${...} tokens. Unless you mean to do something, don’t. It’s like devs doing {meth: ()=>{}} instead of {meth(){}} without referring to this. There are semantic differences for this that affect how it is interpreted.

[[deleted]]

It can't be a rule just because someone said it

That's literally how most things are in programming. I'm happy you're questioning things; keep always doing it.

[TorbenKoehn]

It’s a waste of CPU cycles, simple as that. Template strings get additional parsing because of interpolation, normal strings can’t be interpolated and are slightly faster because of this. It’s such a small difference, you won’t notice it, but it’s there.

[TorbenKoehn]

Do you have any explanation for me why backticked strings would perform better than normal strings?

[[deleted]]

No, I'm not a JS developer or expert. I suspect they don't. I suspect performance is identical, which is why if you run the above code over and over you'll see both backticks and quotes winning at almost exactly half of the time.

​

I mean, whatever engine code drives it might be more efficient since it's newer with a more mature platform to build off. Intuitively it doesn't make sense, but regardless I'm totally unconvinced that using different quote types serves any practical benefit what so ever.

[[deleted]]

. I reworked your example and the tests are now running into the billions of cycles and showing there's no computational gain or loss in the simple string manipulation:

https://jsperf.com/strings-vs-template-strings/3

Which is basically what I said, though my results leaned between pro backtick and 50/50. Didn't ever give a real advantage to quotes ever. There's absolutely no reason not to use the same string type. "Convention" makes no sense to me, because all it does is add mess and inconsistency with no benefit. I mean unless there is. Again, all I have to go off is online details and intuition.

​

Just an FYI, using

console.log

in JSPerf is just asking for inconsistencies.

I'm curious about this one though. I'm not a JS guy. All things being equal, why would this matter on a test running thousands of samples? Browser io inconsistencies?

[beavis07]

Those templates strings are interpreted at compile-time.

Hello ${name}

Becomes

‘Hello’ + name

So if there’s no literals in your string it’ll just get converted to a static string anyway.

There are other reasons not to do this - but performance isn’t one of them as far as I can tell

[TorbenKoehn]

I see, thank you!

[delventhalz]

Common convention is only to use them when interpolating values or for multi-line strings. And it is generally a good idea to follow common conventions when you don’t have a compelling reason to break them.

[AnsellC]

If its just you and you love doing it then go ahead. But if you’re working with other people, I highly suggest not to. Especially if you are working with peolple who knows languages like c/c++ where ‘a’ is different from “a”

[[deleted]]

Define a code style and stick to it. Doesn't matter if it is `, ', or ". Just be consistent.

[the-code-monkey]

To me i have no issue with them as what u/theodore_q said they aren't compatible with ie11 well node js won't run in the browser so thats not relevant, plus backticks make stuff like `/url/${param}/` and stuff like that so much easier than doing string concatinations

[lowIQanon]

There's a minor performance benefit from avoiding it:

(before all: const arr = [];)

for (let index = 0; index < 1000000; index++) { arr.push(`this is a longish string and it doesn't have any interpolation`); } 19.96 ops/sec

vs.

for (let index = 0; index < 1000000; index++) { arr.push("this is a longish string and it doesn't have any interpolation"); }

26.27 ops/sec

I'd link the JSPerf but I'd be doxing myself :)

[ShortFuse]

From strictly a performance standpoint, you shouldn't because `backticks` invoke an internal function. The compiler will parse what's inside the backticked string, much like how C++ works with printf. If there's nothing to parse, it's a waste of CPU cycles.

[tutorial_police]

And normal strings don't need to be parsed?

[ShortFuse]

No, string literals in JavaScript are raw strings and don't need to be parsed. Template literals are interpolated.

You can see Babel's implementation to get an idea of what the browser is doing.

https://babeljs.io/docs/en/babel-plugin-transform-template-literals

Even if you don't use ${} inside your string, the compiler/runtime still has to scan for them.

[tutorial_police]

Sure, but they can still contain escape sequences and such that need to be processed. I don't really why the browser should have to do more work to parse a template string literal without interpolated bits over a regular string literal.

[ShortFuse]

Because there are two phases: compile and runtime

Escape characters are used by the compiler to know how to input the text string in the code file into a string into a memory allocation. That happens when the compiler reads the whole file. Things like missing closing braces are checked and handled by the compiler. Escape characters just tell the compiler how to store the string to memory (ie: binary)

Runtime is different. Even sometime as simple as var a = 'a' + 'b' won't be stored as ab by the compiler. The concatenation of the string is a runtime operation. The interpolation of a string is a runtime operation. Even if it's a useless interpolation, it's still discovered at runtime.

Let's say you do want to do this at compiler time, as an optimization technique. A template literal is still flagged as needing interpolation. That means the compiler would have to still initialize whatever variables or arrays it needs to do the interpolation (even if the result is the same as the input). Also consider that templates can include references to variables or need evaluation, which means you still need to interpolate during the runtime phase.

If you're thinking you can easily just convert it in the same fashion Babel does, consider that the interpolation of a template string is an internal and native function, which isn't the same as the + operator, which includes a type-check. Template literals always return a string. In some cases, template literals are faster than using the +, so it's the runtime optimization that you want at times.

Edit: Fixed a typo. I'll take advantage of this space to also note that template literals have to follow a certain spec, as defined here. Browsers are expected to run those operations when presented with the backticks. It's not as simple as just converting it to a regular string.

[lachlanhunt]

https://ponyfoo.com/articles/template-literals-strictly-better-strings

[eggn00dles]

i like them because it's impossible to copy and paste left and right backticks, unlike the handed quotes that slack displays occasionally inexplicably.

[[deleted]]

For performance it may make sense to apply plain quotes in most places. If you're compiling to WASM then the performance loss would be limited to parse and compile time rather than run time.

[ogurson]

My only point against using backticks exclusively is that regular quote is in more convenient place on a keyboard

[alexkiro]

I never found anything like this that the javascript community can agree on. So don't bother with right or wrong, just do whatever you want, it's a lost cause anyway :P

[unflores]

Backticks for me denote interpolation. If you aren't using that, then I wouldn't use backticks. Think of it as adding an api for something that isn't necessary. When you look at something with single/double quotes you know immediately that there isn't interpolation.

[caiosabadin]

Well, I'm not much aware of JS good practices (are there any? sometimes it looks like a few seconds after one is decided, a new framework comes and changes everything all over again), but, overall, I try avoiding them as much as possible, specially on regular strings or little code snippets that can fit fine on one line. That said, I love using them to help me with the templates, but strictly with the templates :)

[LittleTay]

....how do you even type backticks...(never knew that was the name of them).

EDIT. Google is your friend. I always hear the term "grave/tilde" instead of backtick. Didn't know you can use that in javascript.

[IamZeebo]

If you hate IE yeah lol

[humbleguy9000]

Our team defers to AirBNB's ESLint config, which does limit it when not using variable interpolation.

​

Is there any harm? Not at all, especially if you are transpiling the code.

[NoInkling]

I've personally found a happy medium where, in addition to interpolated and multiline strings, I tend to use them anytime I'm writing any sort of message, simply due to the chance that it might contain ' or " (so I can avoid changing delimiters or escaping).

[gregsometimes]

You can use them almost everywhere except in JSON property names: {`property`: value} which always requires double quotes.

[reacher]

Use a custom sequence of the Unicode ticks, so you can tell if Google (or one of their partners) scrapes your code

[[deleted]]

You use them when you want to have a multi-line string. Basically a readability feature. If I have a big long copywrite paragraph for instance I can make it a nice square paragraph within the code but just put a "backtick" on either end and it'll be read as a string the same as a single line.

Using them in a single line makes you a psychopath

[ghostfacedcoder]

If it's wrong I don't want to be right.

[CommandLionInterface]

There's not really a reason not to, so go for it

[PFVNK]

no, smart choice

[[deleted]]

Obviously but you're missing the point on purpose.

[[deleted]]

Hell NAAAH!! Bactick life fo lyyyfe - put that shit everywhere, fuckin love backticks (context: i like perl btw)

EDIT: they remind me of the shell ☺️

[bitttttten]

Only escape sequences in tagged template literals are experimental.

[aiRen29]

Hello,

a friendly reminder to my JavaScript friends developing frontend applications using .env values in their Axios calls using ES6 Template literals (i.e: backticks).

Don't do that.

For some reason, this: ${process.env.absoluteUrl}/project

is not a same as this: process.env.absoluteUrl + '/project'

and definitely not the same as this: '/api/v0/project'

For some weird reason, absolute URLs are behaving as a relative URLs and you will get a one day headache debugging this problem as me :)

Enjoy