The problems with creating a new template language | Hacker News Reader

The problems with creating a new template language

utcc.utoronto.ca

25 pointsjsnell17 comments

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.

Funny thing, I have created a few template languages (one of the first I created was used to build a local EU commission site and was programmed in ansi C because Java was not mature yet for web, this was time of Altavista for those who remember..) and the more I have seen and created them the more I tend to think that less is more.

IMHO the best templating language available widely at this moment is mustache (and/or handlebars) as it's almost as simple as it can get and that's the way it should be. Logic should be at code and templates should just render text given to them.

A lot of these problems are mitigated by just keeping it simple. You don't, for example, need to design the templating language. Use an existing, successful language, and invert how it parses strings, and add a nicety for expressions. You can probably even reuse most of the parser, and then output code that runs by the language's eval. This gives you all of the language's constructs nearly for free. Python/Ruby/Lua/Elixir/Julia would be great for this. This also produces a better result: I can't tell you how maddening it is to not have basic language constructs in, say, Django templates, because the template designer decided to write a whole second much crappier language inside the language you're using. And this method will likely be more performant.

My company uses a variety of templating languages, and we've been able to create a really nice work flow by building a custom asset pipeline around them.

Recently however we had to push something out really quickly, and opted to avoid our own pipe line in order to put out some raw html, css, and js, very quickly.

Although I cannot imagine how it would be, I wonder if their will be some kind of process in the near future that abstracts away the build pipe line an allows me to continue to write jade/scss/es6 without having to put any effort in putting it in production..

Just invent shorthand syntax for XSLT, output your data for the template as XML and let the xlst transformer do the template instantiation for you.

Why use template languages after all? We can use just Javascript to create components and glue them together, why do we still need to do the extra parsing?

I was thinking the same thing. Why not use the Wordpress model and have your template language be a bunch of api calls to the parsing engine.

The main reason is so you can statically analyze the template source code. For example, pair Gumbo [1] with an HTML-based templating language and you can identify every image referenced in the HTML and automatically coalesce them into a sprite sheet. You can replace dynamically-generated images with data: URLs and load the data at the end of the page, minimizing latency. You can validate your templates to make sure they never generate invalid HTML. You can run any inline scripts found through Closure Compiler or Babel to minify them (or, in Babel's case, support ES6 directly in templates). You can do CSS renaming automatically on all elements.

A secondary reason is to constrain your users so they don't end up writing constructs that will be impossible to manipulate with tooling. Early in Bazel's [2] history at Google, BUILD files were just ordinary Python, and you could use any Python code you wanted, and all that mattered were the calls you made into the build rules. This worked great, with people writing all sorts of list comprehensions and conditionals to minimize code duplication. And then tools came out to reformat BUILD files, and automatically query for dependencies, and detect dead binaries, and all sorts of other cool stuff. The tools were a lot more useful than the ability to include arbitrary code, but (because of the halting problem) they would choke whenever they encountered arbitrary flow constructs. So now arbitrary code is limited to the portions of the build system that explicitly allow it.

The EDSL approach (where you just use a regular programming language and a bunch of calls into the engine) can be a good idea, but you give up a lot in tooling. Usually it's most useful in the early stages of a project, where you don't have manpower to write the tooling anyway, and then becomes a legacy hassle as you assign more engineers, write more code, and get more leverage from writing tools.

[1] https://github.com/google/gumbo-parser

[2] http://bazel.io/

Because you might want Google to index your website.

Because you might want an integer or a float type.

Because you might want to be able to test the logic of your code on one environment, the only environment where it will be run.

Because you might want a reasonable dependency tree.

Because you might not want to rewrite portions of your code to run them on the server side.

I could go on.

But if we are talking about server code it could run js on the server and solve most of these points.

But if we are talking about server code it could be written in a better language.

Reply on news.ycombinator.com