Comments on: DHTML versus DOM: Comparing Both Approaches

By: Dave Stewart

Dave Stewart — Wed, 10 Oct 2007 08:59:35 +0000

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?

Grrrr…..

By: jack

jack — Mon, 29 Jan 2007 03:55:42 +0000

Personally i think DOM is a better way

By: Mike

Mike — Tue, 19 Dec 2006 00:45:38 +0000

Very useful article, thanks!

By: Ed Purkiss

Ed Purkiss — Mon, 05 Jun 2006 19:56:40 +0000

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.

By: Chris Heilmann

Chris Heilmann — Tue, 18 Apr 2006 11:08:59 +0000

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. :-)

By: Paul Smith

Paul Smith — Sun, 16 Apr 2006 16:36:43 +0000

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 http://www.developer-x.com/content/innerhtml/dom_vs_innerHTML_perf_test.html 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.

By: Joseph Annino

Joseph Annino — Sun, 16 Apr 2006 16:12:03 +0000

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.

By: Andrey Skvortsov

Andrey Skvortsov — Sun, 16 Apr 2006 12:41:21 +0000

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.

By: Scott Schiller

Scott Schiller — Sun, 16 Apr 2006 01:57:52 +0000

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.

By: Gabriel

Gabriel — Sat, 15 Apr 2006 18:27:24 +0000

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).

By: Jason Haley

Jason Haley — Sat, 15 Apr 2006 13:44:25 +0000

Interesting Finds

By: Matthew Ratzloff

Matthew Ratzloff — Fri, 14 Apr 2006 23:31:58 +0000

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.

By: Chris C

Chris C — Fri, 14 Apr 2006 17:29:16 +0000

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.