Templates and DOMs

In my last post, I mentioned my ideal of keeping “HTML” generation as operations on a DOM tree, instead of assigning variables to templates and using string substitution. Parse the initial template file, fill it with data, then render it once with safe encoding (where relevant) at the end.

I also know why this approach isn’t as popular: everyone hates the DOM.


Procedural programming is the easiest type, and that’s pretty much what template languages offer. Having a flows like {% foreach … %} baked right in is just… kind of like home. Or perhaps a cabin-in-the-woods retreat, where Life Is Just Simple.™

Strings are easy to understand. Strings are easy to work with. Most of the time, data being pasted into HTML won’t cause any problems.

Strings perpetuate the myth that “the designers” can go code up templates, and programmers can just fill them with data. (I should probably disclose, I have never worked in a company where a separate, non-developer team actually touched the template files. Either we were too small to have designers, or the designers deliver via a PSD-to-HTML service and the programmers must still build the templates.)

The DOM is very programmerish, though. It’s invisible. It relies a lot more on the code to fill it in. It involves a lot of extra terminology (Node vs. Element: is it an important difference?)

A lot of people also got their first experience with the DOM through JavaScript, complete with all sorts of browser incompatibilities, reference loops causing resource leaks (hello old IE), and sheer pain. Nobody who lived through that wants to do it again.

It’s kind of disappointing. The lack of interest translates to a lack of effort in building APIs more suited for “using a parsed DOM tree to build an output page.”

Even if I could develop it, could I popularize it?