Friday, April 14th, 2006

DHTML versus DOM: Comparing Both Approaches

Category: Articles

One of the interesting debates in the community is whether to use DHTML-ish type approaches to DOM manipulation (such as innerHTML) or to use the DOM API. Christian Heilmann has written “From DHTML to DOM scripting“, a lengthy, attractive article implementing a slideshow using DHTML techniques and then demonstrating how the DOM API could be used to implement the same functionality. From the article:

In this article we will try to help JavaScript beginners to spot old and outdated JavaScript techniques and explain what their issues are. We do this by looking at a web page that might have been developed around the millennium with development ideas that were good at the time (DHTML), but result in inaccessible or even broken pages in today’s web environment.

If you want to take a look at the code examples offline, you can download the example site as a zip.

This article is aimed at developers who are new to JavaScript, or those who haven’t touched it in a while and wonder why people tell them off for using techniques that were the bee’s knees in 1999.

We will take a demonstration page that features three dynamic elements using JavaScript, take a look at how they were achieved, and give an example of a modern way of re-creating them more future-proof and less in the way of the visitor (DOM scripting). Let’s start with a bit of background knowledge about what DHTML and the DOM are.

While we at Ajaxian are somewhat pragmatic and tend to really love innerHTML, it’s interesting to see other perspectives.

Posted by Ben Galbraith at 10:49 am

3.4 rating from 57 votes


Comments feed TrackBack URI

My only problem with using the DOM API over innerHTML is the very poor performance. Script is simply not fast. Not fast enough to generate any modest amount of UI via the DOM. Every time I’ve tried to use it to generate UI it is rediculously slow compared to the instant native C++ speed of allowing the browser to render it via innerHTML.

Comment by Chris C — April 14, 2006

Interesting. I’ve always been under the impression that all the dynamic JavaScript I write (whether via DOM or DHTML) is implied under the umbrella term of DHTML. I wasn’t aware that someone had made a differentiation at some point. Can someone send me an invite to the Web application terminology mailing list so I can keep up to date with the new buzzwords? Thanks.

Also, Chris C. is right. I use DOM as much as possible, but it is often pathetically slow in anything even mildly rigorous.

Comment by Matthew Ratzloff — April 14, 2006

Interesting Finds

Trackback by Jason Haley — April 15, 2006

I’ve found that using the DHTML method of using innerHTML is superior many times from a coding and maintenance point of view to using the DOM api. Creating every element, then appending it into a container, then setting properties on it, can end up being a nightmare to maintain when the alternative is defining the end HTML you want and painting that into an element using innerHTML.

My vote: innerHTML always, except when you can only do something using DOM element creation (which for me has been very rarely).

Comment by Gabriel — April 15, 2006

I think you can still get pretty good results with DOM provided you take the right approach – ie. creating an element structure “off-line”, making all necessary changes and finally making a single append to the body etc. Logically thinking, the browser should only have to reflow one set of elements much in the same way .innerHTML would. It is likely that looping through newly-created elements, setting event handlers and properties etc. contributes a lot to the overall difference in performance.

“.innerHTML vs DOM” might have been a more accurate title.

Comment by Scott Schiller — April 15, 2006

Scott,if you like E4X/XQuery like constructors then you like .innerHTML.
Currently,we don’t have native construction set for DOM and innerHTML nice alternative in most cases(simply “string” framework is more mature;-).I believe you need to resort to DOM API only in rare cases for very granular manipulations.

Comment by Andrey Skvortsov — April 16, 2006

I’ve found the best approach is to make up an HTML “template” that contains all the structure my page will ever need. If there are multiple alternate views, I code them all as HTML, and use CSS rules to choose which one is shown. If an element repeats, I specify it once within the HTML, inside a holder div, and copy it several times.

This is where the speed issue comes in. Using the DOM methods (cloneNode, appendChild) is really slow in IE, and also buggy (its fine in Firefox though). But if I get the outerHTML and repeat it in a string and stuff it into the innerHTML of the holder div its fast (in all browsers). Then I can go through the new children and set styles, image sources, and such.

So I never “generate” html, I always use what is already there and just throw data into it and change its display properties. The repeating elements are the one sort of exception, and I’m wondering what others have found as the best approach for doing that sort of thing.

Comment by Joseph Annino — April 16, 2006

The server keeps timing out so I can’t read the article, but most of the responses here seem to prefer innerHTML. I think that innerHTML and DOM manipulation are both useful depending on the situation.

There are many sites with DOM vs innerHTML performance tests, and DOM is usually slower, but still pretty fast as long as you create fragments and append them to the body as the last step. See for example.

DOM is nice if you want to keep around pointers to the elements you have created. With many dynamically updatable parts of the page it’s nice to already have a pointer to the object instead of needing to call slow getElementById – especially if one request can update many seperate parts.

If you use bunch of function calls to make the HTML structure, DOM is nicer (for me at least) from a coding and maintenance perspective – creating strings from a bunch of different functions and remembering to create the ending tags is a bit messier. Reminds me of the good old days of using PERL on the server – before we had nice html template librarys.

On the other hand, if your javascript is just creating a bunch of static content, then innerHTML is cleaner and faster.

Comment by Paul Smith — April 16, 2006

Hmm, it is interesting to see how many people aren’t even bothering to read an article before answering a lot about their likes and dislikes.

The article is not about DOM generation vs. innerHTML, it has so many more points why DHTML is less efficient now and what the benefits of using DOM methods are. It is not only technical, it is also about the way to approach an HTML changing task with JavaScript.

I am writing a book on the matter now and am well aware of the benefits of innerHTML when it comes to XHR returns output and heavy application development. So, please before you wrap up in the “but it is too handy to miss” cocoon, have a read and then judge the article or make assumptions as to where I am standing in the debate afterwards. :-)

Comment by Chris Heilmann — April 18, 2006

I see innerHTML to DOM as the “exec” function is to PHP. It has a very strong place in the language and is an excellent tool – to but endeavor to claim one superior to the other is like saying a hammer is superior to a screw driver.

Comment by Ed Purkiss — June 5, 2006

Very useful article, thanks!

Comment by Mike — December 18, 2006

Personally i think DOM is a better way

Comment by jack — January 28, 2007

Every time I come back to looking at code I wrote the DOM way, I just have to “trust” I wrote it well in the first place, as it’s more difficult to scan it and see what it represents. And if you want to change something even minor, it can be hard work.

The fact that it’s orders or magnitude quicker to write or edit a bit of decent HTML than it is to laboriously create a DOM structure sells it for me (almost) every time.

I don’t understand why people are saying “DOM is the better way”. Why better?
As far as I see it, if I’m writing semantically-correct markup, that works correctly in whatever application / browser I’m working in, where’s the problem? It’s way more manageable, and slashes development time (so I can go and work on some REAL bugs!) and that’s the key thing.

Any static HTML page is written using raw markup; we don’t ask people to build it node by node, so what are the “Oh you must build the DOM manually” evangelists talking about?


Comment by Dave Stewart — October 10, 2007

Leave a comment

You must be logged in to post a comment.