That is why you should prefer Twig or other templating engine with autoescaping.
> They all start as an attempt to remove the possibility of writing meaningful code
I don't think so. Twig developers have a large list of reasons on their frontpage: http://twig.sensiolabs.org/
<?= escape($var) ?>
{{ var | escape }}
Nevertheless, I used DOM/libxml on the server side in PHP/C, since 10 years ago, and was happy about it. It avoids all the other the template issues (balancing open/close tags, etc.) very well.A few helper functions and you're good to go, with simplicity, flexibility and speed you will not get from any templating library in PHP.
Though, some coding customers don't know what to make of it. Some people have trouble with not being able to see HTML in the code, because "where do I paste my Google Analytics code?".
{{ var }}
That is a big difference because beginners always forget about escaping.> Nevertheless, I used DOM/libxml on the server side in PHP/C,
There used to be XSLT templates but they don't seem to be popular now. Constructing DOM trees in the code without using templates is probably inconvinient and produces bloated code.
Beginners also forget about balancing HTML tags, which is quite unpleasant experience when creating and changing more complicated templates with loops, conditions, etc. You can also do post-processing on the constructed DOM, even during construction.
Bloated code only happens if the programmer fails to structure the code into nicely re-usable functions. Anyway, it seems to be quite popular right now with all the react hype - React.createElement is such a helper function to help construct DOM tree.
It's pretty much the same concept on the server side. Except you don't need to care about DOM diffing, because server has no persistent DOM.
I've had decent success using an xml-object based approach, so certain structured parts of the template (navigation, form controls, etc) are built programmatically using dom methods and then serialised into the template.
The more stupid thing about them, which transcends PHP and touches all other programming languages, is the very idea of assembling HTML piecemal from unstructured text. HTML is a textual representation of a tree, and should always be constructed as such - and not by gluing strings together. It's kind of the same problem as with SQL injections, which would not be possible in the first place if people weren't gluing them together from strings.
I'll probably get flamed for saying that, but really - many of the popular tools on the web are broken on a fundamental, conceptual level.
[0] - because of a misunderstanding of the "don't write logic in your views" principle; sure, don't write business logic in your views, but that doesn't mean you don't need, or shouldn't use, a real programming language in your views.