DEV Community

Jérémy Lal
Jérémy Lal

Posted on

template engines still ignore the power of the DOM

I need you to leave php-thinking today.
Why ?
Because that kind of thinking makes you build "string-based" template engines, and this is bad.

Obviously it's bad security-wise, string-based engines don't know where they're
merging data in an attribute, a tag name, pure text, or html.
They have a hard time keeping it right because the DOM evolves too fast for them.

The DOM should come first, then templating after.
Embrace the DOM. Don't try:

I've been trying to make something purely DOM based:

however, i recognize the API is odd.

Please help me improve it if you're motivated !

Top comments (3)

leob profile image

Well, isn't all server side templating/HTML generation going the way of the dodo, at least for "apps"? SPA/client side frameworks FTW ...

I'm never going to do another "app" project anymore that's generating its HTML server side (with the possible exception of SSR) ... only APIs and SPA, pure content based static websites are still okay but I'm not really interested in those (and then SSR/Nuxt/Next are good options).

kapouer profile image
Jérémy Lal

Not really ! Most template engines have still (even when they're made for browsers) a "string-first" approach.
That's bad, and that's really bad because it causes all sorts of security issues.

leob profile image
leob • Edited

I don't know, I'm pretty sure that frameworks like Laravel and Rails have prevention of SQL injection, XSS, CSRF etc pretty well thought out. If you develop an application using the proper features of those frameworks then you can't inadvertently inject anything into your pages, even when using a "string based template". Who in their right mind is using the old fashioned PHP "write text" approach to manually generate their pages without a framework?

But my point was that people are increasingly moving towards client side frameworks like React to build their frontend, which doesn't use string based templates (it uses JSX which is directly compiled into JS) and which runs client side, using virtual DOM.

But maybe I'm just misunderstanding the point that you're trying to make. Do you mean that everyone's got it wrong when they're building their apps using the established frameworks?

I don't see the point of having to build up your DOM tree using some sort of verbose object oriented API when frameworks and template compilers are already good at parsing, compiling and validating DOM compliant templates, in a way that's more concise and easier to use (also for non-programmers e.g. designers).