4 ms·
it is html templating, but php's sore points were not the html templating.
by mu53 3y ago
it is html templating, but php's sore points were not the html templating.
- berkes 3y agoI keep saying that PHP is above all a templating language. Last time I looked every file has to start with a php-mode tag still, for example. Which makes it funny to then realize that e.g. twig is a templating language written in a templating language.
- dgb23 3y agoIt’s funny but also sad. There is a very simple and productive subset of PHP that I feel got neglected over the last 1-2 decades. The simple, but relatively fast “array”, which has value semantics. The batteries included networking (HTTP, SMTP etc.) and SQL stuff. The stateless execution model and straightforward way to combine and execute scripts. And finally the in-built, seamless HTML templating. It’s unfortunate that especially the last one got neglected so developers feel the need to build a safe abstraction over it.
- berkes 3y agoYup. Unfortunate indeed. It's 2023 and there is jinja, liquid, moustache and then some. Nothing extraordinary. Nothing truly cross language. I think that if the dice fell just slightly different, PHP could have taken that niche. Be the best templating language that has bindings to all major languages. It was really good at arrays, but then piled objects, hashmaps and more on top of these arrays. It had very good and broad string manipulation std functions. But the it piled SQL on top of that. Imagine if instead of mysql_real_escape it had focused on (nested) caching. Or if instead of the umpteenth mediocre OOP class inheritance it introduced template partials as objects to be defined. If, instead of clumsy form handling, it had the world's fasted serialization (to xml, html, JSON etc). Instead of csv parsers, it offered the best stdlib for rendering data. And so on.
- dgb23 3y agoHTML templating in PHP is unfortunately unsafe. It has some nice properties: streams by default, it’s pretty fast for a templating language and you get a lot of stuff for free that you eventually need. However, you have to escape and sanitize output explicitly, which is not a thing in pretty much any modern templating language. The std lib in go for example has a very explicit security model. The problem is that you have to escape differently depending on the micro context. So it can become tedious and error prone if you have to do it explicitly all the time.
- tannhaeuser 3y ago> However, you have to escape and sanitize output explicitly, which is not a thing in pretty much any modern templating language. Idk if it has to with "modern" or not. Proper escaping contexts (whether, and which delimiters to quote in attributes, in content, in markup declarations, ...) are already defined by SGML, with HTML-aware templating or other vocabulary-specific expansion such as suppressing <script> elements injection as would be required by basic user commenting also being covered by SGML. My impression was that go/templating (and maybe pug?), while considered advanced relative to other templating packages shitting strings into markup, still requires explicit sanitation depending on the insertion context.