Be Pragmatic: DHTML vs. DOM

In the beginning, only the browser’s support for the DHTML object model provided JavaScript
developers with the ability to update the page contents dynamically. The success of DHTML
led to the definition of a standard document object model—the W3C’s DOM. Quite obviously,
the DOM evolved from DHTML and became much more generalized than DHTML. As mentioned,
the DOM provides a tree-based model for the whole document, not just for an individual
HTML tag.

Most browsers, though, support a mix of DOM and DHTML. Which one should you use? In
particular, to update some contents, should you obtain a reference to the textual child node of
the node that matches the intended HTML tag (the DOM way) or just grab a reference to a
node and use innerHTML (the DHTML way)? Likewise, to add a new element, should you create
a new element or just stuff in a chunk of updated HTML via innerHTML? Admittedly, one
of the most interesting debates in the community is whether to use DHTML to manipulate
pages or opt for the cleaner approach propounded by the DOM application programming
interface (API).

The key fact is that the DOM API is significantly slower than using innerHTML. If you go
through the DOM to generate some user interface dynamically, you have to create every element,
append each into the proper container, and then set properties. The alternative only
entails that you define the HTML you want and render it into the page using innerHTML. The
browser, then, does the rest by rendering your markup into direct graphics.

Overall, DHTML and DOM manipulation are both useful depending on the context. There are
many Web sites that discuss performance tests and DHTML is always the winner. Anyway,
DOM is still perfectly fast as long as you use it the right way—that is, create HTML fragments
and append them to the proper container only as the final step.