That people produce HTML with string templates is telling us something
May 25, 2023
A while back I had a hot take on the Fediverse:
Another day, another ‘producing HTML with string
templates/interpolation is wrong’ article. People have been writing
these articles for a decade or more and people doing web development
have kept voting with their feet, which is why we have string
templates everywhere. At this point, maybe people should consider
writing about why things have worked out this way.(I don’t think it’s going to change, either. No one has structured
HTML creation that’s as easy as string templates.)
One of my fundamental rules of system design is when people keep
doing it wrong, the people are right and your system or idea is
wrong. A corollary to this is that when you
notice this happening, a productive reaction is to start asking
questions about why people do it the ‘wrong’ way. Despite what you
might expect from its title, Hugo Landau’s [[Producing HTML using
string templates has always been the wrong solution (via)
actually has some ideas and pointers to ideas, for instance this
quote from Using type inference to make web templates robust
against XSS:
Strict structural containment is a sound, principled approach to
building safe templates that is a great approach for anyone planning a
new template language, but it cannot be bolted onto existing languages
though because it requires that every element and attribute start and
end in the same template. This assumption is violated by several very
common idioms, such as the header-footer idiom
in ways that often require drastic changes to repair.
Another thing to note here is that pretty much every programming
language has a way to format strings, and many of them have ways
to have multi-line strings. This makes producing HTML via string
formatting something that scales up (and down) very easily; you can
use the same idiom to format a small snippet as you would a large
block. Even Go’s html/template
package doesn’t scale down quite that far, although it comes close.
String templating is often very close to string formatting and so
probably fits naturally into how programmers are acclimatized to
approach things.
(Hugo Landau classifies Go’s html/template as ‘context aware
autoescaping HTML string templating’, and considers it not as good
as what the quote above calls ‘strict structural containment’ that
works on the full syntax tree of the HTML document.)
I don’t have any particular answers to why string templating has
been enduringly popular so far (although I can come up with theories,
including that string templating is naturally reusable to other
contexts, such as plain text). But that it has suggests that people
see string templating as having real advantages over their alternatives
and those advantages keep being compelling, including in new languages
such as Go (where the Go authors created html/template instead
of trying to define a ‘strict structural containment’ system). If
people want to displace string templating, figuring out what those
current advantages are and how to duplicate them in alternatives
seems likely to be important.
(I’ll pass on the question of how important it is to replace the
most powerful context aware autoescaping HTML string templating
with something else.)