If we don't care about the UX, then it would be more "convenient" for the developer to just not write the program in the first place.

Using string templating makes the DX better without compromising UX, since users just see the rendered output. Implementing bad/nonexistent web security also makes the DX easier since there's simply fewer features to implement, but this obviously has negative consequences on UX when folks have their accounts/credentials easily stolen.

Using string templating for HTML is bad/nonexistent web security, so by your argument it does compromise UX.

By your argument, everyone using string templating for HTML has bad/nonexistent web security. I disagree.

Not everyone, just the people whose pages display untrusted inputs. Which is a huge fraction of the modern web...

(The rest just have brittle websites that might break when someone uses certain punctuation for the first time.)

Ah okay I see now you were referring to failure to sanitize inputs/outputs in the original comment. I don't know if this oversight occurs more often when using string templating, but I'm pretty sure this was already a problem long before string templating came into practice.

It's literally the reason why HTML templating is done with other means than string concatenation, these days.

Isn't that why server side validation exists? What's wrong with letting the user enter whatever they want? It doesn't mean it has to be accepted.

Validation can force usernames to be a-z but it doesn't work on freeform text. Forum comments should be able to state that the HTML open comment syntax is <!--

Not really. Lots of template engines escape and/or sanitize interpolated expressions, according to the context, by default.

Well that goes far beyond what I think of as "string templates", now you're parsing the string into HTML.

Not necessarily, it just means the right way should be made easier.

I'm sure everyone is very interested in hearing about how that should be done.

Simply because you don't have an answer doesn't mean you can't point out that something is wrong.

'Something is wrong' is different from 'this can be done better', though. The first one is unfalsifiable, the second can be potentially falsified by putting forward a new way to do it. The first one is mushy language with no clear goal, the second one is an actual constructive plan forward.

The primary design constraint for all of those is security whereas for generating HTML it's done combination of simplicity/maintainability/performance.

There are also security implications for how HTML is constructed.

And which of those implications bare importance on string templating?

Of course there are examples of situations where this heuristic doesn't apply, but that doesn't mean its a bad idea that we should totally disregard. This kind of thinking has plagued engineering fields for a long time; Don Norman talks about it in "The Design of Everyday Things". Engineering teams get mad when users don't use their products the "right way", when really they just won't admit to themselves that they've implemented bad design. Simpler, cleaner designs and use patterns tends to win as time goes on.

Untrusted input has to be escaped before injecting it into an HTML document, or else there is a script injection vulnerability when text from one user is executed as script in another user's browser. Good templating systems eliminate this possibility through parameter systems, but maybe those are still considered string templating systems?

I was going to jump in with a pithy DOET quote[1], but you got the essence quite correct: if the intended users of your system can't get it right, then you, the designer, got it wrong.

[1] Maybe something about "probably won awards" :-)

And there are plenty of things that were one convention that are wrong. Along with plenty of implementations of security that actually aren't good.

If security is a goal, there is a difference between doing anything and actually having a secure system. There is also such a thing as secure enough.