Comment by jasim | Hacker News Reader

Comment by jasim | Hacker News Reader

The reason to not create a new template language is because they are a terrible idea that has lived this long since a) most languages lacked a nice multi-line string equivalent, b) XML, a great way to represent markup, did not have first-class support in programming languages.

Neither of these are true anymore, so it is time we let template languages go.

The essence of templating is string interpolation. That is what ERB, Jade, HAML and similar languages do. ES6's Template Strings are fantastic at this. They are multi-line, and they allow interpolation.

Even if we supposed that the notion of separation of view and view-logic was a reasonable one, the baggage that a dedicated templating language brings in is simply not worth it.

Here are examples of the baggage: 1) the choice of picking a templating language is almost of a religious nature (HAML vs ERB).

2) Custom syntax and needs for each language - the `surround`, `suffix`, and `precede` helpers in HAML.

3) Templating languages almost always reinvent programming constructs poorly. Greenspun's tenth rule is really apt here:

Any sufficiently complicated templating language contains an ad hoc, informally-specified, bug-ridden, slow implementation of a turing complete programming language.

These days I rely a lot on JSX, which is rigorous and catches errors, thanks to compile-time parsing, and well-integrated into the language so that I can use programming language abstractions without wringing them through ill-defined extension points in a templating language.

I can also say smart things:

Template language is useful not because it allows to do things, but because it limits what can be done.

It limits useful things that can be done, but comes up with worse way to do the same.

Code/view reuse for example is done through partials in template languages: you can either learn `<%= render partial: "filename" %>` syntax for ERB (with Rails), or `include filename` syntax for JADE, or the `{% include template_name %}` syntax in Django.

Or you could simply use functions: compose them, curry them, put them in objects and call them, and even remote execute them; it is all code.

Logic is similar: every template language has their own syntax for conditionals and loops. Learning these does not teach us anything new nor make us better at our craft. These are simply useless tediums.

Another pet peeve is Template Inheritance. Jade has `block` and `extends` keywords; RABL similarly has an `extend` keyword. Programming languages have an arguably better way to do inheritance.

This is my rule of thumb: if a library/template language brings its own semantics for inheritance, be wary.

I disagree that the way is "worse".

I like that in templates, string handling is _enforced_ to be different. For example, when you manipulate strings in template, you can be reasonably sure all output is escaped, unless you specify otherwise in a very few precise cases with explicit syntax.

A good template language allows you to create/limit available tools/helpers for your particular project. That is especially important in larger projects and larger teams, where everyone is not immediately expected to know intended good practice to follow. Creating DSL in template _is_ a way of documenting intended good practice.

A good template language does not pretend not to be turing-complete: instead, it provides comprehensive error handling and error messages, so that users know exactly where some error or type occurred.

One more reason to use the language is because it is a language. If someone used something like Django, the Twig will be quite familiar and easy to pick up.

Template engine can optimize-away, pre-compile things, just like languages do.

With separate template language you don't need to recompile whole build if you change a template (presuming hosting language is compiling to binary and template engine is interpreted).

Full disclosure: I am currently rewriting Twig in another language, and believe it's completely worth the effort.

I think these are different use cases. If you create a CMS and allows your users to write templates you probably want to limit them a lot. If you use a template language as a part of building a web site or an application you probably want as much features as possible.

But on the contrary, template languages are useful because it lets you trivially templatize any text-based file regardless of the file syntax (as long as the template delimiters are customizable, or at least don't conflict with the file syntax). Building HTML? Sure, use a proper builder API. But for almost anything else, templates can be quite effective.

It is a fair point. But one has to be careful where the balance is.

In the beginning, it would be a text file with a few string interpolation in between, which means we insert logic inside content, and it can remain in the native format.

But over time, as in the HTML generated for web apps, the balance of content inverses. What begins mostly as some logic inside predominantly static content, becomes some static content inside a lot of logic. At that point, it is best to make code the primary medium.

Reply on news.ycombinator.com