The appeal of text templating systems for generating HTML

November 1, 2019

One of the things that some people love in web frameworks and other people hate is HTML page generation that's based around some form of evaluation of text-based templates. In systems that I'm familiar with, both Django and Go have such a templating system. From some perspectives, such systems aren't ideal; for example, as I mentioned in my entry on XHTML's implications for page generation, truly text based templating systems can't easily enforce strict correctness in the results. My view is that text templating systems have a deep appeal for good reasons; fundamentally, they're a good match for both our tools and how we often think about and write HTML.

There are two ways to view a HTML document or document fragment. One of them is that it is a bunch of text with some greater or lesser degree of markup; another is that it is a tree of nodes (we can call this the DOM based view). The tree based view is how the browser will actually deal with our HTML, but for people it has two connected problems. First, we mostly lack the tools to deal with trees of nodes, while we have plenty of tools for working with text (I think it's telling that common browser web development tools generally show us the page's DOM tree in a textual representation). Second, we mostly don't create documents as trees or think of them that way; instead we create and view them as some mixture of running text (which we add markup to) and structural blocks (possibly nested ones). The actual tree structure is an emergent property of putting together the marked up text and structural blocks in sequence.

All of this makes a text based templating system very natural. It works well with our text based tools and matches how we write and view HTML. For running text, we can read or write the whole thing at once and mostly skip over the markup. In fact we can write the text first, then go back to add the markup it needs to make it come out right in HTML. It's easy to change our mind if we decide that some bit should or shouldn't be emphasised, or link to something, or whatever; it needs no structural rearrangement, just some markup added, deleted, or changed.

This is not true with current tools for dealing with trees. They are not universal in the way that text is, and they necessarily force structural rearrangement if you decide to change the markup because often changing the markup changes the tree structure. If you add markup, you must split a tree node and often create sub-nodes; if you delete markup, you must merge sub-nodes back in. And if your editing environment insists that the tree is always correct, you often get extra hassles as you write and periodic interruptions of your flow to rearrange your tree. Perhaps someday all of these issues may be fixed, but they aren't today; the tools are just not up to the level and the universality of editors and other things that deal with text.

(All of this should sound very familiar from attempts to make programming languages that aren't represented in text but are instead always dealt with as some form of parse trees.)

Written on 01 November 2019.
« Some thoughts on the pragmatics of classifying phish spam as malware
Using personal ruleset recipes in uMatrix in Firefox »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Nov 1 23:53:11 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.