3 ms·

Embedding templates in code is actually quite nice. I used to think like you, but then I gave React a try and it completely won me over. Even without the trans

Embedding templates in code is actually quite nice. I used to think like you, but then I gave React a try and it completely won me over. Even without the transpilation step for JSX support, I find hyperscript [0] and friends [1] a notable improvement over other templating tools. Instead of having to jump to a separate file which magically inherits a bunch of implicit globals, you just call a function. If the system supports a component abstraction you can import them and compose views using the same programming constructs you use everywhere else. An error in the template can be caught by your linter or compiler, since it's just regular code. I'd say it's actually safer, since you typically won't have to worry about escaping values manually. And along the way you can validate the input in order to confirm you only ever generate valid HTML. Check out elm-css [2] as well, which lets you define your stylesheets with elm. This lets you take advantage of the their type system to make sure all class names are referenced correctly. A typo or accidental deletion would would cause it to fail to compile, allowing you to catch problems early. [0] https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript [1] https://github.com/developit/vhtml https://github.com/developit/vhtml [2] https://github.com/rtfeldman/elm-css https://github.com/rtfeldman/elm-css

TeMPOraL 9y ago
I still don't get why non-code templating ever became popular. Especially that I saw it becoming popular in PHP, which itself is a better templating language than the templating languages people were using. Instead, people created plethora of languages that slowly accrued Turing-completeness with them, because religious adherence to "no code in views" is stupid. That said, glue-strings-together templates are still a problem and should not be used. HTML document is semantically a tree, and if you don't treat it like that, bugs and security vulnerabilities follow. (Respecting semantics applies to other languages as well. For instance, those who recognized SQL as a language, instead of some blob you concatenated out of strings, didn't have to worry about SQL injection.)
- krapp 9y ago
  >I still don't get why non-code templating ever became popular. Because if you're working on a team, not everyone on your team may be a programmer, particularly if they're just working on layout design, and the problem that templates solve in that regard don't require complete access to raw code. Separating one from the other makes it easy to focus on one versus the other. Just look at how messy a complex Wordpress template can get and how difficult it can be, just reading it, to get a grasp of what the HTML would look like, versus a Twig template which has a lot less noise. >Especially that I saw it becoming popular in PHP, which itself is a better templating language than the templating languages people were using. I've been down the road with PHP where everyone working on javascript and CSS also had to know just enough PHP not to break the site, because everything had raw PHP mixed into it, and then somewhere in the vast tree of includes including includes someone forgot to manually escape a variable that came from the database, or else they did, but now someone else escaped it twice, or they created some weird encoding problem because they were in a javascript context. PHP is at best an adequate templating language, and a good base to build a sane framework on. But a framework is necessary beyond a certain level of complexity, because most projects benefit from features that raw PHP doesn't provide, such as context-aware and automatic variable escaping, template inheritance, template caching, etc. You will either wind up using an existing templating framework, or you will wind up implementing an ad-hoc, informally-specified, bug-ridden, slow implementation of an existing framework. >That said, glue-strings-together templates are still a problem and should not be used. HTML document is semantically a tree, and if you don't treat it like that, bugs and security vulnerabilities follow. There's no way to get that in PHP without a template framework. PHP, unfortunately, doesn't even know that HTML exists[0], despite having the sole purpose of being an HTML preprocessor. [0]I just remembered there are XML functions like DomDocument that can be used to process HTML (with... effort) but I don't know whether or not you could get something like XHR out of it, and by extension, avoid the problem of HTML as concatenated strings.
  - krapp 9y ago
    > but I don't know whether or not you could get something like XHR out of it, and by extension, avoid the problem of HTML as concatenated strings. .. I meant XHP, not XHR, can't edit it now. Oops.
  - 9y ago

TeMPOraL 9y ago

I still don't get why non-code templating ever became popular. Especially that I saw it becoming popular in PHP, which itself is a better templating language than the templating languages people were using. Instead, people created plethora of languages that slowly accrued Turing-completeness with them, because religious adherence to "no code in views" is stupid. That said, glue-strings-together templates are still a problem and should not be used. HTML document is semantically a tree, and if you don't treat it like that, bugs and security vulnerabilities follow. (Respecting semantics applies to other languages as well. For instance, those who recognized SQL as a language, instead of some blob you concatenated out of strings, didn't have to worry about SQL injection.)

krapp 9y ago
>I still don't get why non-code templating ever became popular. Because if you're working on a team, not everyone on your team may be a programmer, particularly if they're just working on layout design, and the problem that templates solve in that regard don't require complete access to raw code. Separating one from the other makes it easy to focus on one versus the other. Just look at how messy a complex Wordpress template can get and how difficult it can be, just reading it, to get a grasp of what the HTML would look like, versus a Twig template which has a lot less noise. >Especially that I saw it becoming popular in PHP, which itself is a better templating language than the templating languages people were using. I've been down the road with PHP where everyone working on javascript and CSS also had to know just enough PHP not to break the site, because everything had raw PHP mixed into it, and then somewhere in the vast tree of includes including includes someone forgot to manually escape a variable that came from the database, or else they did, but now someone else escaped it twice, or they created some weird encoding problem because they were in a javascript context. PHP is at best an adequate templating language, and a good base to build a sane framework on. But a framework is necessary beyond a certain level of complexity, because most projects benefit from features that raw PHP doesn't provide, such as context-aware and automatic variable escaping, template inheritance, template caching, etc. You will either wind up using an existing templating framework, or you will wind up implementing an ad-hoc, informally-specified, bug-ridden, slow implementation of an existing framework. >That said, glue-strings-together templates are still a problem and should not be used. HTML document is semantically a tree, and if you don't treat it like that, bugs and security vulnerabilities follow. There's no way to get that in PHP without a template framework. PHP, unfortunately, doesn't even know that HTML exists[0], despite having the sole purpose of being an HTML preprocessor. [0]I just remembered there are XML functions like DomDocument that can be used to process HTML (with... effort) but I don't know whether or not you could get something like XHR out of it, and by extension, avoid the problem of HTML as concatenated strings.
- krapp 9y ago
  > but I don't know whether or not you could get something like XHR out of it, and by extension, avoid the problem of HTML as concatenated strings. .. I meant XHP, not XHR, can't edit it now. Oops.
- 9y ago