DEV Community

loading...

template engines still ignore the power of the DOM

kapouer profile image Jérémy Lal ・1 min read

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:
https://github.com/kapouer/matchdom

however, i recognize the API is odd.

Please help me improve it if you're motivated !

Discussion (3)

pic
Editor guide
Collapse
leob profile image
leob

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

Collapse
kapouer profile image
Jérémy Lal Author

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.

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