
The problems with creating a new template language - jsnell
https://utcc.utoronto.ca/~cks/space/blog/web/TemplateLanguageProblems
======
jasim
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.

~~~
nercury
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.

~~~
jasim
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.

~~~
nercury
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.

------
mikkom
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.

------
iamsohungry
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.

------
jonesb6
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..

------
scotty79
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.

------
cttet
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?

~~~
iamsohungry
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.

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

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

