Let's talk about String in JavaScript. There are 2 ways developers can define a string:
a. Using String Literal
const str = "Hello " + "world!";
b. Using Template Literal
const worldText = "world!"
const str = `Hello ${worldText}`;
So, have you ever wondered what the difference between the tow? Which one do you usually use? Is the one you're using better?
Let's find out by doing performance test.
Benchmarking
Here are the test case and String Literal and Template Literal
used for benchmarking.
Test Case
const iterations = ITERATION_TOTAL // 10, 100, 10000, 1000000
const stringText = 'string'
let text = ''
const start = performance.now()
for (let i = 0; i < iterations; i++) {
// String or Template literal test case here
}
const end = performance.now()
console.log(`It took ${end - start} ms.`);
String Literal
text = "text"
Template Literal
text = `text`
String Literal concatenating a String
text = "text " + stringText
Template Literal concatenating a String
text = `text ${stringText}`
String Literal concatenating Two Strings
text = stringText + " text " + stringText
Template Literal concatenating Two Strings
text = `${stringText} text ${stringText}`
I ran the tests on Node Js v18.17.0 with different loop iterations: 10, 100, 10,000, 100,000, and 1,000,000. I measured the average times for each iteration.
Result
Here are the results for each iteration (the lower is better):
10 Iterations
100 Iterations
1,000 Iterations
100,000 Iterations
1,000,000 Iterations
Conclusion
It's still good to use both String Literal
& Template Literal
in simple iteration, displaying a limited items. The results showed a slightly different between the two which is still acceptable.
When dealing with processing large datasets, complex algorithm, generating long strings, using React components that frequently re-render that require a large number of iterations, String Literal
is the only one to go.
It's important to understand that not every method is the best fit for every case and project. There might be some trade-offs to consider.
Top comments (24)
You should really test in more than one environment. What holds true in NodeJS may not hold true in other JS engines.
Yeah, that is possible. I chose Node JS because it's currently the most popular JavaScript runtime used by many developers.
Thanks for the suggestion. I'll make a note of it.
Isn't Chrome probably the most popular JavaScript runtime?
yeah, it can also, but Chrome is different thing. I meant between Node, Deno, and Bun.
They both use the same engine, V8, so much of a muchness, really.
It's amazing! I never think about the difference
I'm glad I could help!
My tests show that concat is faster if the strings being concatenated are longer. There is a lot less work going on and a lot less memory allocated using concat - therefore less garbage collection.
My test case is indicative of the kinds of volumes a website concatenating articles might face, possibly smaller. I would point out that all of them are very fast and this should probably not be the first point of optimisation.
It's interesting, I checked that concat is the lowest now. This is the reason I didn't use neither measurethat nor perflink, because the result is always different.
Anyway, I hardly ever use
concat
, nice reference.Π‘ongratulations π₯³! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up π
I suggest to watch this, you will change your mind about the benchmark results:
It's interesting, so much magic behind V8. Regardless, this post just shows the perspective of using
performance.now()
forstring literal
andtemplate literal
. From this, we can also do other things to improve the accuracy.Anyway, thanks for sharing. I got new ideas from the video.
Amazing , a good read .
This was a good read!
Thank you for your work! Youβve helped me deepen my understanding of JavaScript!
Happy to help!
Interesting post!
Itβs odd, I am pretty sure I saw similar post about comparision string and template literals and the outcome was different (in favor of template literal) π€¨
I'd love it if you could share it