[tmanderson]

This is, in my opinion, even worse than writing straight HTML in JavaScript. Before I get into anything, I just want to point out that with jQuery, you can do the same thing:

$('<div id="foo"><span>bar</span></div>').appendTo('.baz');

I'm not one to condone the over-use of the bloated jQuery, but in this case I sure would.

Anyways, my biggest gripe with this whole thing is the fact that writing any markup in your JS, or anywhere other than an HTML file, is just plain ugly. Beyond that, it's a pain to manage, and totally screws up the whole "separation of duties" paradigm that the web community seems to be quickly forgetting as of late.

Keep your markup where it should be, in your HTML files, because as we all know, HTML is XML and XML is meant to give semantic meaning to data. JavaScript should be a means of transport for data to its relevant structure, not means of giving visual structure to data. Leave that to the HTML and CSS.

Even templating doesn't do it for me 100% of the time and there are better ways. I'm a heavy believer in separation of duties, and any JS programmer should be too. Every time I come across any heavy-handed DOM manipulation in JS I cringe.

As for this article, there's 523637483723526334632 other libraries/frameworks/micro-frameworks that do this same thing, and if you're going to do it, just use what you're already probably using: jQuery. You're probably already abusing it anyways.

[perfunctory]

Constructing DOM with javascript doesn't preclude the separation of duties. Nothing stops you from separating the presentation logic and the business logic into separate javascript files. In fact I believe this article describes a very viable approach. Especially if one is building a complex highly interactive web-app (as oppose to web-site). The term "presentation logic" has the word "logic" in it. And the best way to handle logic is with a proper programming language.

P.s. Didn't they mention XSS

[NathanRice]

Actually, if you read between the lines a little bit, what the article suggests is somewhat analogous to a viewmodel/presenter. Creating an entire DOM in the way suggested would be bad form, but creating an abstracted viewmodel then transforming it programmatically is actually quite elegant.

Viewmodels let you use the same skeleton structure for different mediums. You can take a viewmodel and generate a native (read "app") interface easily, as long as you have transformations from abstract viewmodel to concrete view. Of course that would require the ability to compile Javascript to native on your platform of choice, but I don't think that is a pipe dream.

[MatthewPhillips]

That jQuery snippet is the best possible way to make your site sluggish.

[tmanderson]

http://jsperf.com/tmandersondomtest

The best possible way? Well, that's not true at all. In fact, that was even faster* than whatever method this article was talking about (genDom).

Either way, my point wasn't to say 'just toss it all over to jQuery!' My point was, if you think this technique is cool, you're probably using jQuery and you could've been doing this for years. Years!

Anyhow, this is a huge deflection from what I was really trying to convey. Basically, I don't think this (the 'sugared dom' method from the article) is solving anything. HTML should define your markup and JS should just be filling in the blanks (and not creating them).

*Please note that I do realize my DOM creation was particularly minimal (however, hardly differing from the 'sugared dom' test mentioned in the article) and is hardly a sufficient test. Really, I just wanted to show that you'd have to be doing a ridiculous amount of DOM manipulation to see any significant drop in performance.