The Problem
I’ve been asked a lot recently about what template engine I prefer and most people seem shocked when I say that I do my best to avoid them and just generally don’t like the idea of templates. Let me first define what I mean by templates before I get into my explanation so there’s no confusion. When I refer to “Templates” here I’m talking specifically about user-interface templates and primarily HTML templates. My definition of a template in this context is a mechanism for allowing dynamic content to be incorporated into design.
The Good
To your average designer or developer I’m sure the immediate response is, “But templates can save so much time!” and they are correct. Templates are definitely an improvement over developers generating UIs dynamically. Templates exist for the specific need of collaboration between designers and developers. This has always been a big problem as designers generally don’t know the programming languages the developers are using and the developers don’t have the creative design skills to be creating user interfaces. The solution provided by templates is a dumbing down of the dynamic contents (developer side) that allows designers and developers to interact via templates so both can continue to work effectively and collaboratively.
The Bad
Here are the primary points I have against templates:
- Templates are a dumbing down of your programming language by definition. You cannot accomplish everything you can in your language of choice in a template. This leads to multiple layers of abstraction and increases the complexity of your application.
- Templates often try to solve #1 by incorporating WAY too much of the language and thus become increasingly complex and painful for designers to utilize.
- Templates are yet another “language” you have to learn and maintain.
- Templates never find the right balance. Templates either focus too much on keeping it simple and thus create severe pain for developers for their lack of capabilities or they incorporate way too much and become impossible for designers to understand.
- Templates generally require (though not always) a server-side technology to process and populate data into. This means your designers can’t work on the user interface without requiring a server to run it on. This not only makes set up for a designer much more complicated, but it decreases their ability to make quick changes and see the results.
The Awesome
Hopefully I’ve effectively shown the problems with Templates, but I have yet to offer a better alternative. Yes, I believe one does exist and I’ve been developing this way for over a year and it is being utilized effectively with several production sites (ex. http://www.projectspeaker.com). The idea is to allow designers to work with HTML and create representations of the content for the site independently of the developers. The developers then manipulate the content in code before delivery. Hyperscala was an ideal framework to support this type of development since it allows interaction with HTML, CSS, and JavaScript in a type-safe infrastructure so you can manipulate the DOM without impacting the designer’s work. For an example of this take a look at my post comparing Hyperscala to Play Framework (https://matthicks.com/2013/01/30/hyperscala-why-not-play/).