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

Comments on this page:

By HundredPickles at 2023-05-26 09:30:56:

I think another reason string templating is more popular than a strict system is that people need string templating anyway, just for the text portion of their websites. Things like "written on {date}" or "thank you, {username}". It's an almost universal need, so it feels very natural to just throw in the formatting tags as well.

At one point, it was popular to expect "designers" to write "templates", and assume these designers did not understand the DOM structure or "real code." The advertising and docs for Smarty or Twig would have sections oriented toward these design-only users.

In theory, there's a separation of labor possible, but in practice, I've never worked in an environment where this is reality. The templates are still code, but expressed in a different language than the host programming environment.

I had an aside drafted here, but Landau acknowledged it already: that strings were considered faster. That's pretty much all I cared about in 2007. So I can see how strings would 'win' given these cultural forces.

What it tells me is that their programming languages aren't good at structured data generation, but are good enough at string templating.

In homoiconic languages like Lisp, by contrast, structured generation of HTML (e.g., Hiccup in Clojure) works far better than string templating, and also happens to be the most common way to generate HTML there. Lisp has been doing structured generation of source code for over 50 years, so HTML is a piece of cake.

String templating is a classic New Jersey style technique, which is why it Won Big. That's the only "real advantage" it needs. You may as well ask why Unix or C or insects are so prevalent if they're so minimalist. They're prevalent because they require so little of their environment.

By Michael at 2023-05-27 01:55:41:

I would say that even if writing an entire template needs handling the «code» parts, modifying the «layout» and «text» parts can be done without learning too much about the details about the code.

Once I have chosen to use text-based auto-escaping templating and not structured options in Common Lisp exactly because sometimes for some people (not developing the system but closely working with it) just experimenting with a copy of a template and seeing the changes live was a faster turnaround than formulating each change for me to make. The code parts of the template were just moved around without modification, there discussing the changes was a better idea.

It's also a kind of scaling down: if a lot of things are not yet decided and are going to be decided by what power users are happy with, and the development team is small (or just one person)…

Written on 25 May 2023.
« Encryption for stream based protocols versus 'RPC' protocols
In practice, Grafana has not been great at backward compatibility »

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

Last modified: Thu May 25 22:28:59 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.