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).
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.
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).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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).
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.
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).