views:

185

answers:

10

In my web application I would like to complately avoid html and use only javascript to create web-page's dom tree.

What is faster writing web content in the traditional way in html <div>Some text</div> or using javascript dom render, like this: div.appendChild(document.createTextNode("Some text"));?

+10  A: 

Stick with the traditional HTML. It's not only faster than doing everything with javascript, it's much more maintainable.

Unless there is a compelling reason otherwise, stick with the straight up HTML and use javascript for the more interactive pieces of your app.

Nathan
See also [Unobtrusive JavaScript](http://en.wikipedia.org/wiki/Unobtrusive_JavaScript)
Matt
+1  A: 

HTML is parsed and generated by the browser and then entered into the DOM. Using javascript to manipulate the dom piece by piece is more overhead.

Imagine if you had to retype an article from a magazine. Now imagine doing so if every sentence was on a new page. ALthough the end result is a copied article, you had to spend all that time flipping pages.

Dan Heberden
A: 

By far the traditional way is faster, the user downloads the file, it is there, parsed and done.

If you do the JS way the page has to be built client-side, EVERY time they load the page.

That is just a horrible way to build a page IMHO and a nightmare to manage/update/create

Mitchel Sellers
+2  A: 

Speed is a secondary concern to correctness - that is, serve the functional requirements first, then make it fast where necessary (some places, it might already be fast enough).

In this case, the decision to use static markup versus JavaScript is a question of who is consuming your document - is it only users with JavaScript enabled? If so, it doesn't matter too much. Do you need to take search engines into consideration? Disabled users? Thin clients that don't have full JS support, or paranoid users with JS disabled? In all of these latter cases, having semantic markup, not cluttered with superfluous elements, enhanced with JavaScript, is the only correct way to go.

Rex M
+1  A: 

If you're going to be doing a lot of changes to html through javascript I'd recommend using a templating library like trimpath.

Stuart
+1  A: 

I find it interesting that you would consider creating a document purely through Javascript. It's actually faster to create elements using the DOM and document.createElement than .innerHTML property. This method creates the document objects directly, whereas using innerHTML requires the parser to iterate over the HTML and create the elements.

On the other hand, using Javascript instead of writing the HTML directly would require the Javascript to be parsed and executed, creating additional overhead over the HTML parser.

Andy E
I think you may be forgetting that the HTML parser is native and pretty fast. All studies I've seen have so far show innerHTML to be fastest (http://andrew.hedges.name/experiments/innerhtml/), although JavaScript engines are getting faster all the time. I understood this question to be unconcerned with innerHTML and concerned with development speed, not execution speed. Maybe not.
Lee Kowalkowski
@Lee Kowalkowski: Indeed, hence the final paragraph of my answer. I may have confused `innerHTML` with what's written [here](http://msdn.microsoft.com/en-us/library/ms533019(VS.85).aspx#Use_the_DOM_to_Add_Individual_Elements), although the first line indicates that this applies to all HTML string based methods. I suppose `innerHTML` would be faster for very large DOM manipulation tasks.
Andy E
+1  A: 

HTML (templating) is generally considered to be a more intuitive, modular and maintainable approach for DOM manipulation.

A couple of places to get you started:

jQuery Templating Engines: http://stackoverflow.com/questions/170168/jquery-templating-engines

Google Closure Templates http://code.google.com/closure/templates/

Geoff
A: 

I already tried in the past doing a 100% javascript built component for an ajax chat. It turned out, it was less maintainable, took more time to code and the advantage where very slim even tough it was probably a project that could benefit a lot from that javascript DOM approach.

Even if you think there could be advantage, there isn't. Stick to pure HTML.

HoLyVieR
+2  A: 

The traditional approach is going to be faster because the browser only has to download, interpret and display. The approach you're suggesting would cause the browser to have to download, interpret, change * n times and then display.

That's as far as rendering goes.

As far as maintainability goes, you're creating a nightmare. That's the key to development. The number of nightmares in maintainability is proportional to the "quality" of the code, IMHO. Performance and optimization should come second to maintainability. (There are exceptions, of course. Nothing is black-and-white).

HTML was created to be an expressive language. Javascript wasn't. End of story, in my opinion.

lewiguez
A: 

IMHO I think compile javascript is a good solution to create fast applications to web.

That's a good view point!
Rizo