DEV Community

loading...

Discussion on: template engines still ignore the power of the DOM

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