I form DOM nodes as strings and append them to DOM tree like below using jQuery.

var dom = '<div><div style="display: inline-block">first name</div>'
             '<div style="display: inline-block">last name</div></div>';


The above code is a small sample. In most of my cases dom will hold big strings.

When I recently read about JS performance tutorials, I saw this post. It mentioned that this way of string concatenation is not a good practice. It mentioned the use of .join() instead of concatenation. That seems like an old post, so which one is efficient in these days?

  • \$\begingroup\$ this used to be the case, but these days they are saying concatenation is faster than join now. \$\endgroup\$
    – chovy
    Commented Dec 16, 2012 at 7:38

3 Answers 3


Strings are immutable. It means that when you allocate memory while creating a string, you are not able to reallocate it. So, this code:

var a = 'a';
a = a + 'bc';

Will allocate a new block of memory for 'a' variable, instead of reusing already allocated.

When you do something like 'a' + 'b' + 'c' + 'd' each concatenation allocates a new block of memory for every temporary string.

When you use something like this:

var a = 'a';
a = [a, 'b', 'c'].join('');

join function calculates memory for result string and allocates it only once for a complete string.

As it is shown in the post that you mentioned, it is easier to handle and to avoid memory leaks in JS interpreter (it seems that IE6 and IE7 just not handle garbage collection for the first variant correctly).

If you are interested for the speed of string concatenation for different browsers you can try and view it here.

UPD: Not advocating join, just trying to explain why it was assumed as an optimized variant. As seen at jsPerf tests new browsers optimize string concatenation, so it is faster.

  • 3
    \$\begingroup\$ +1 for the updated note about how join isn't necessarily the best way to go with new browsers. Just ran the jsPerf test for Chrome 23.0.1271.95 and join was actually the slowest option. \$\endgroup\$
    – Agent_9191
    Commented Dec 11, 2012 at 12:43
  • 1
    \$\begingroup\$ Likewise in Firefox 12, join is quite a bit slower than any of the other options. \$\endgroup\$
    – Izkata
    Commented Dec 11, 2012 at 12:51
  • \$\begingroup\$ I do think there is some notion of size that needs to be considered, though. If one were to required to build a very large string incrementally over wildly varying code paths, at some point, pushing to a dynamic array (with reasonable growth rate implementation, which I assume most js. imps. have) and joining is always going to be faster than always conjoining. Suppose you have a string that's 10K characters long, and you want to create a new string appending 50 strings (10 characters each) to it. One way creates one 10K+500 characters at once, the other creates fifty 10K+ strings. \$\endgroup\$
    – JayC
    Commented Dec 11, 2012 at 17:44

Considering this jsperf, I would stick to

var a = "asd" + "Foo" + "bAr";
  • \$\begingroup\$ The referenced test uses static strings which allows the JS engine to optimize the direct concatenation essentially into a NoOp. I tried to fix this to get results that are a bit more realistic: jsperf.com/string-concatenation/34 (Now Array.join wins on Firefox) \$\endgroup\$
    – x4u
    Commented Dec 11, 2012 at 15:54

Since it appears that you're working with the DOM you might want to think about using HTML fragments rather than strings.

Here is one article on the subject: http://ejohn.org/blog/dom-documentfragments/

For your example, try using something like

$("<div />").css("display","inline-block").html("first Name");

Another related question on using fragments vs. strings: https://stackoverflow.com/questions/2217409/jquery-best-practice-for-creating-complex-html-fragments


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.