A Case for Strongly Typed HTML Templating Languages

FTA:

> Is this full type checking overkill?

Yes.

> But considering the huge number of websites and web applications written every year, and the massive difficulties we consider with browser testing and compatibility, it sure would be nice if web developers no longer had to consider whether their HTML was valid or not, and instead have more time to focus on the things that really matter.

As a web developer I can tell you that generating valid HTML is trivial. Even when working with large, multipart systems like Drupal and Wordpress, the developers and plugin writers do a phenomenal job of creating a single, unified DOM. This is remarkable: thousands of individuals can contribute to a project that outputs a single page of perfectly valid HTML and corresponding CSS/JavaScript assets. (This code is not always optimized, but it is valid).

Generating valid HTML is a solved problem - even in complex systems. Creating a new templating engine doesn't add any value.

The time and aggravation that occurs in web development is as follows: even if I create a perfectly valid & consistent HTML/CSS/JavaScript web page it will not be rendered the same across web browsers. Let me repeat that: as a web developer even if I honor the contract outlined in a specification there is no guarantee that the same contract will be implemented in a consistent fashion across browsers.

Templates that are valid HTML are the right answer, unlike most templates which are string based because historically most server side templates have been string based (which I personally detest). No need for yet another template language!

An example is http://batmanjs.org/ , and maybe most XML based templates too.

I ended up writing my own pure HTML templates (templates implemented using cloning - super simple and fast), with declarative definitions written in JavaScript. Declarative definitions and events are linked to HTML nodes by data-nodename attributes within the template.