We Keep Coding

Print an array(object?) without comma seperator

I am currently writing a large amount of code, but I will keep it simple. I have a javascript array (possibly an object, still unsure exactly of the conventional naming), here is the initialization code:
var myArray = ["assignS" , ";" , "S"]
This is what I get as a console.log() from firebug on the element. There is too much code to post as it is assigned multiple values through many for loops. So this array (or object) is printed later as follows:
document.write("S -> " + myArray);
output:
S -> assignS,;,S
I do not want these commas in the result, it poses problems as some elements in the array may be commas themselves. I have ruled out the .join() method because of this, and am unsure how to proceed.

You ruled out the join method why, exactly? It takes a parameter, the separator, which you can then use to specify no separator:
myArray.join("");
I recommend reading up on the documentation for .join().
Also, I wouldn't recommend you use document.write, it has very few good applications.

The .join method on an array will by default concatenate all items with a comma, but it takes one argument to override this to be any other string to use as the glue - including an empty string.
myArray.join(''); // is "assignS;S"

var a=[1,2,3,4]
var result="";
for(i= a.length-1; i>=0;i--){
result=a[i]+result;
}
document.getElementById("demo").innerHTML=result;

Use this code:
document.write("S -> " + myArray.join(" "));

different ways to append html?

I just wanted to know the differences between the methods of adding html in jquery.
both will do samething right?
$('body').append($("<div><img src='somesource' alt='something'></div>"));
and
var div = $("<div>");
var img = $("<img>").attr({"src" : "somesource", "alt" : "something"});
div.append(img);
$('body').append(div);
which is the best practice to follow?

The second is better. Because you often see people doing this:
var alt = 'This is " the title containing a double quote';
$('body').append($('<div><img src="somesource" alt="' + alt + '"></div>'));
and then wonder why something got eaten :-). Whereas when you use the second you have absolutely nothing to worry about:
var alt = 'This is " the title containing a double quote';
var div = $('<div>');
var img = $('<img>').attr({ src : 'somesource', alt : alt });
div.append(img);
$('body').append(div);
UPDATE:
I was too hasty in saying that you have nothing to worry about with the second approach. As others have already pointed out you have to worry about performance.

The second method looks better and there are lesser chances of error. But performance wise, the second method is slower. So if you're going to be doing a lot of appending, I would recommend going with the the first case - albeit, carefully.
Here's a small test case up on JS-Perf comparing the two methods

Normally I would say DOM-scripting is the better option (the second approach); it's more structured, and easier to catch issues than by inserting a mass of HTML prepared as a string.
That said, there are performance concerns. Inserting loads of elements via DOM-scripting, particularly in a loop, can cause significant slowdown and there are cases where inserting as a string is much quicker.
Also, the fewer inserts you do - by whatever means - the fewer repaints/refreshes you force the browser to make. Again, these all require browser attention, so the fewer the better.

I believe you are better off using template libraries for inserting objects. An example of one such library is here: http://api.jquery.com/category/plugins/templates/
Those libraries are build for performance and ease the burden on parsing HTML blobs.

Adding a string of HTML content is about 10 times faster
than using second method
Here is a reference

See also my answer on When do you use DOM-based Generation vs. using strings/innerHTML/JQuery to generate DOM content?
The difference is that you have two variables pointing to the jQuery instances. You might can need them for eventListener-adding or manipulating them lateron in the code.
Also, DOM-based element generation has the advantage of automatically escaping the strings, which is especially useful when designing functions with parameters and absolutely needed for user input.
Therefore, the second method is most often preferred. You can also nest the appending process to make the structure clear (OK, in this example the one-liner would be clear as well):
var div = $("<div>");
var img = $("<img>", {"src":"somesource", "alt":"something"});
$('body').append(
div.append(
img
)
);

I would prefer the second one as the first one could lead to very long lines and if you need to bind events to certain elements you already have a variable that is pointing to it.

Which way is better in Javascript, string concatenation or with array? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why is string concatenation faster than array join?
Usually we need to generate html contents dynamically in Javascript.
Two ways like below:
var s = "", a = [];
for (var i = 0, l = data.length; i < l; i++) {
s += "<a href='#'>" + data[i].name + "</a>";
a[i] = "<a href='#'>" + data[i].name + "</a>";
}
container.innerHTML = s; // or
container.innerHTML = a.join("");
Which way is better? Mainly foucus on performance, or the differences can be ignored.

This answers your question: High-performance String Concatenation in JavaScript

The array method is better.
When you concatenate strings, you will be copying the entire previous string to a new string for each iteration. In the end you will have copied a lot more data than the size of the resulting string. For each additional iteration the amount of data that you have copied roughly doubles, so it will get really much really fast.

This is pretty far from clearcut, as a legacy from having to support IE6/7 I always thought that the array method was much faster, but that appears to really not be the case.
Here is a test using a small string 'a':
http://jsperf.com/concatenation-vs-array-join/16
Here is a test using a large string (first paragraph of lorem ipsum):
http://jsperf.com/concat-vs-array-join-longer-strings
In all modern browsers (I tested IE9/Chrome19/FF12) the concatenation is faster, and much faster when using the longer strings.
It is important to note though that in IE7, the array method is much faster, so if you have to support that (and I would think twice about supporting IE7 now), then you should likely be using the array method, as IE7 is so slow with string concatenation as to be ridiculous.
Actually, if you have to support IE7, I would just steer away from using any sort of heavy client side JS!

Javascript - get strings inside a string

var str = '<div part="1">
<div>
...
<p class="so">text</p>
...
</div>
</div><span></span>';
I got a long string stored in var str, I need to extract the the strings inside div part="1". Can you help me please?

you could create a DOM element and set its innerHTML to your string.
Then you can iterate through the childNodes and read the attributes you want ;)
example
var str = "<your><html>";
var node = document.createElement("div");
node.innerHTML = str;
for(var i = 0; i < node.childNodes.length; i++){
console.log(node.childNodes[i].getAttribute("part"));
}

If you're using a library like JQuery, this is trivially easy without having to go through the horrors of parsing HTML with regex.
Simply load the string into a JQuery object; then you'll be able to query it using selectors. It's as simple as this:
var so = $(str).find('.so');
to get the class='so' elememnt.
If you want to get all the text in part='1', then it would be this:
var part1 = $(str).find('[part=1]').text();
Similar results can be achieved with Prototype library, or others. Without any library, you can still do the same thing using the DOM, but it'll be much harder work.
Just to clarify why it's a bad idea to do this sort of thing in regex:
Yes, it can be done. It is possible to scan a block of HTML code with regex and find things within the string.
However, the issue is that HTML is too variable -- it is defined as a non-regular language (bear in mind that the 'reg' in 'regex' is for 'regular').
If you know that your HTML structure is always going to look the same, it's relatively easy. However if it's ever going to be possible that the incoming HTML might contain elements or attributes other than the exact ones you're expecting, suddenly writing the regex becomes extremely difficult, because regex is designed for searching in predictable strings. When you factor in the possibility of being given invalid HTML code to parse, the difficulty factor increases even more.
With a lot of effort and good understanding of the more esoteric parts of regex, it can be done, with a reasonable degree of reliability. But it's never going to be perfect -- there's always going to be the possibility of your regex not working if it's fed with something it doesn't expect.
By contrast, parsing it with the DOM is much much simpler -- as demonstrated, with the right libraries, it can be a single line of code (and very easy to read, unlike the horrific regex you'd need to write). It'll also be much more efficient to run, and gives you the ability to do other search operations on the same chunk of HTML, without having to re-parse it all again.

is the + operator less performant than StringBuffer.append()

On my team, we usually do string concatentation like this:
var url = // some dynamically generated URL
var sb = new StringBuffer();
sb.append("<a href='").append(url).append("'>click here</a>");
Obviously the following is much more readable:
var url = // some dynamically generated URL
var sb = "<a href='" + url + "'>click here</a>";
But the JS experts claim that the + operator is less performant than StringBuffer.append(). Is this really true?

Your example is not a good one in that it is very unlikely that the performance will be signficantly different. In your example readability should trump performance because the performance gain of one vs the other is negligable. The benefits of an array (StringBuffer) are only apparent when you are doing many concatentations. Even then your mileage can very depending on your browser.
Here is a detailed performance analysis that shows performance using all the different JavaScript concatenation methods across many different browsers; String Performance an Analysis
More:
Ajaxian >> String Performance in IE: Array.join vs += continued

Internet Explorer is the only browser which really suffers from this in today's world. (Versions 5, 6, and 7 were dog slow. 8 does not show the same degradation.) What's more, IE gets slower and slower the longer your string is.
If you have long strings to concatenate then definitely use an array.join technique. (Or some StringBuffer wrapper around this, for readability.) But if your strings are short don't bother.

Yes it's true but you shouldn't care. Go with the one that's easier to read. If you have to benchmark your app, then focus on the bottlenecks.
I would guess that string concatenation isn't going to be your bottleneck.

Agreed with Michael Haren.
Also consider the use of arrays and join if performance is indeed an issue.
var buffer = ["<a href='", url, "'>click here</a>"];
buffer.push("More stuff");
alert(buffer.join(""));

Try this:
var s = ["<a href='", url, "'>click here</a>"].join("");

Like already some users have noted: This is irrelevant for small strings.
And new JavaScript engines in Firefox, Safari or Google Chrome optimize so
"<a href='" + url + "'>click here</a>";
is as fast as
["<a href='", url, "'>click here</a>"].join("");

JavaScript doesn't have a native StringBuffer object, so I'm assuming this is from a library you are using, or a feature of an unusual host environment (i.e. not a browser).
I doubt a library (written in JS) would produce anything faster, although a native StringBuffer object might. The definitive answer can be found with a profiler (if you are running in a browser then Firebug will provide you with a profiler for the JS engine found in Firefox).

In the words of Knuth, "premature optimization is the root of all evil!" The small defference either way will most likely not have much of an effect in the end; I'd choose the more readable one.

The easier to read method saves humans perceptible amounts of time when looking at the code, whereas the "faster" method only wastes imperceptible and likely negligible amounts of time when people are browsing the page.
I know this post is lame, but I accidentally posted something entirely different thinking this was a different thread and I don't know how to delete posts. My bad...

It is pretty easy to set up a quick benchmark and check out Javascript performance variations using jspref.com. Which probably wasn't around when this question was asked. But for people stumbling on this question they should take alook at the site.
I did a quick test of various methods of concatenation at http://jsperf.com/string-concat-methods-test.

I like to use functional style, such as:
function href(url,txt) {
return "<a href='" +url+ "'>" +txt+ "</a>"
}
function li(txt) {
return "<li>" +txt+ "</li>"
}
function ul(arr) {
return "<ul>" + arr.map(li).join("") + "</ul>"
}
document.write(
ul(
[
href("http://url1","link1"),
href("http://url2","link2"),
href("http://url3","link3")
]
)
)
This style looks readable and transparent. It leads to the creation of utilities which reduces repetition in code.
This also tends to use intermediate strings automatically.

As far I know, every concatenation implies a memory reallocation. So the problem is not the operator used to do it, the solution is to reduce the number of concatenations. For example do the concatenations outside of the iteration structures when you can.

Yes, according to the usual benchmarks. E.G : http://mckoss.com/jscript/SpeedTrial.htm.
But for the small strings, this is irrelevant. You will only care about performances on very large strings. What's more, in most JS script, the bottle neck is rarely on the string manipulations since there is not enough of it.
You'd better watch the DOM manipulation.