4 ms·

A templating library that re-implements in a bad way what existing programming languages already do, yes. Honestly this is one of the few things that php/asp/et

A templating library that re-implements in a bad way what existing programming languages already do, yes. Honestly this is one of the few things that php/asp/etc got right.

TeMPOraL 6y ago
Indeed. IMHO, using a templating library is a very bad idea in the first place[0] - but if you have to glue strings to build markup, then use a regular programming language for that. If you look at popular templating libraries, it's easy to notice how, over time, they all became crappy, Turing-complete programming languages, inferior to just doing <?= ... =?> in PHP. -- [0] - HTML is a tree serialization format, and templates are assembling it by gluing raw, dumb strings together. It's a recipe for disaster. The equivalent thing in SQL is the source of SQL Injection category of bugs. You really should use a tool that respect the semantics of the language.
- mattacular 6y ago
  > You really should use a tool that respect the semantics of the language. What tool are you referring to? If one does not exist, why is that?
  - TeMPOraL 6y ago
    HTML generators that work on trees. They do exist, and they're very popular in Lisp world, though they also exist elsewhere. So instead of reading a template file and interpolating it with strings, you'd write something like (using JS / PHP syntax): const html = ['form', {action: myHandlerUrl, method: 'post'}, ['input', {id: 'key', name: 'key', type: 'hidden', value: randomKey()}], ['button', {type: 'submit'}, "Send!"]]; OutputHtml(html); With OutputHtml() being the replacement for templating engine. The above structure is semantically a tree, and you can't in any way screw it up as to leave tags incorrectly nested (it won't compile/interpret). It's composable too - you can concatenate a bunch of such representations and always get a result that represents a valid tree. OutputHtml() is relatively easy to write even by yourself, because at any given time, when turning a dynamic value into output HTML, it's apparent how the value has to be converted (and/or "escaped"). SQL also has its equivalents of this idea. The most basic of which is "prepared statements" - an API in which, instead of: query("SELECT foo, bar FROM baz WHERE bar = " + userInput " AND foo > " + anotherInput); you write: query(build("SELECT foo, bar FROM baz WHERE bar = ? AND foo > ?"), userInput, anotherInput) which against gives the API the most basic ability to recognize and encode interpolated values correctly. There are of course more complex libraries available, which let you parametrize any part of an SQL query, while making the generation template respect SQL's semantics, and that use composable representations.

A templating library that re-implements in a bad way what existing programming languages already do, yes. Honestly this is one of the few things that php/asp/etc got right.

TeMPOraL 6y ago

Indeed. IMHO, using a templating library is a very bad idea in the first place[0] - but if you have to glue strings to build markup, then use a regular programming language for that. If you look at popular templating libraries, it's easy to notice how, over time, they all became crappy, Turing-complete programming languages, inferior to just doing <?= ... =?> in PHP. -- [0] - HTML is a tree serialization format, and templates are assembling it by gluing raw, dumb strings together. It's a recipe for disaster. The equivalent thing in SQL is the source of SQL Injection category of bugs. You really should use a tool that respect the semantics of the language.

mattacular 6y ago
> You really should use a tool that respect the semantics of the language. What tool are you referring to? If one does not exist, why is that?
- TeMPOraL 6y ago
  HTML generators that work on trees. They do exist, and they're very popular in Lisp world, though they also exist elsewhere. So instead of reading a template file and interpolating it with strings, you'd write something like (using JS / PHP syntax): const html = ['form', {action: myHandlerUrl, method: 'post'}, ['input', {id: 'key', name: 'key', type: 'hidden', value: randomKey()}], ['button', {type: 'submit'}, "Send!"]]; OutputHtml(html); With OutputHtml() being the replacement for templating engine. The above structure is semantically a tree, and you can't in any way screw it up as to leave tags incorrectly nested (it won't compile/interpret). It's composable too - you can concatenate a bunch of such representations and always get a result that represents a valid tree. OutputHtml() is relatively easy to write even by yourself, because at any given time, when turning a dynamic value into output HTML, it's apparent how the value has to be converted (and/or "escaped"). SQL also has its equivalents of this idea. The most basic of which is "prepared statements" - an API in which, instead of: query("SELECT foo, bar FROM baz WHERE bar = " + userInput " AND foo > " + anotherInput); you write: query(build("SELECT foo, bar FROM baz WHERE bar = ? AND foo > ?"), userInput, anotherInput) which against gives the API the most basic ability to recognize and encode interpolated values correctly. There are of course more complex libraries available, which let you parametrize any part of an SQL query, while making the generation template respect SQL's semantics, and that use composable representations.