I’ve been thinking about templating systems a lot recently. By templating systems I mean technologies that allow you to mix some data with some fixed text to produce some kind of output. One obvious use is in creating dynamic web pages where, for example, you would create a row in a table for each item that you pulled out of a database table. Templating systems form the view component (the ‘V’ in ‘MVC’) of many web frameworks.
There seem to be two schools of thought on templates. Some people think that the best language to use for templates is the same language that you use for the rest of the system. This is the approach taken by Ruby on Rails, where the you templates will contain a lot of Ruby code. Other people, and I’m one of them, think that it’s better if your templating language is completely different from the rest of the system. We believe that presentation logic is (or, at least, should be) much simpler than the rest of your code and that using a deliberately simplified language forces you to separate your business logic from your presentation logic and that leads to cleaner systems. Also, it’s often the case that templates are written by a different set of people than the rest of the system and you shouldn’t really require the template developers to be experts in the programming language that is used for the rest of the system.
It seems that this separate language approach is starting to catch on. Perl has the Template Toolkit which has its own presentation language. PHP now has a separate templating language called Smarty. Django (a web framework written in Python) has uses a similar approach. And even Ruby on Rails has just gained a new separate templating language called Liquid.
But that’s not all. As I noted when I wrote about the recent web frameworks night, all of these templating languages look very similar. And that’s what got me thinking.
Consider the (common) case where the templates are written by a different team of people to the backend code. We’ve already established that this team shouldn’t need to know whatever programming language the rest of the system is written in. If we assume that this is a web-based system then those people will already be experts in HTML, XHTML, CSS and JavaScript. There’s really no reason for them to be experts in Perl, Python or Ruby as well.
But the way things are currently they might not need to know Perl, Python or Ruby, but they do need to know whatever templating system is being used. So the choice of backend language is effecting what the frontend developers are using. And that seems wrong to me. Given that many of the templating languages seem to be converging on a similar syntax, isn’t it worth giving them that extra push so they just become the same language? That way, frontend developers can just become experts in “templating” and it doesn’t matter to them what language is being used at the backend.
We don’t expect frontend developers to use a different type of HTML because the backend is written in a different language. Surely it’s a bit weird to expect them to use a different templating language.
Oh, I realise there would be a lot of work to do. Working out a “best of breed” syntax across all the existing templating systems would be difficult. And then you need to work out how each individual programming language would interface with the templates. But isn’t it something at least worth investigating?
Back when I was doing work in Zope, we were using Tal, which was an XML-based display language. Although you could hardcode Python *hock* *spit* into the templates, most of the variables were generated in the calling program (the controller, although Zope doesn’t call it that) and passed in. This seems like like the best compromise to me. There are TAL implementations for Perl and standalone (i.e., non-Zope) ones for Python.
This is a great idea — we could even do it for non-templating languages too!Ah, wait – someone already has done. It’s called “Java”. Ahem ;-)
Darren,Yeah, a couple of people have mentioned TAL to me. But I think there’s probably a reason why few people are using TAL and all other templating languages are converging on something that looks like TT.I don’t know TAL well enough to know what the reason is, but it might have something to do with the fact that TAL is XML :)
Indeed. I think this is definitely worth pursuing. The specification for this template system would have to carefully spell out the behavior of the abstraction to remain independent of both the presentation media and the controller.
With my manager’s hat on, it’s a pain in the neck that there are so many programming languages out there, simply because it makes it hard to recruit staff. Hypothetically, if there was just one way to program a computer then it would be so much easier to find people with the right skills.All these niche languages and templating kits are actually self-defeating: they might make it a bit easier from a technical point of view to do the work, but they actually make it very hard to assemble a good team, just because the best programmers are split between many languages. So actually the project suffers more than it would if there was a single standard language, even if that language was technically less accomplished.I don’t know what the answer is to this problem. I used to wonder if it was Java, but that just got so complicated that I can’t be bothered with it. (Well, I couldn’t be bothered with any of it so I went and did an MBA!)Perhaps the root of the problem is just that techies can’t help themselves from fiddling about and coming up with “improvements”.One of the big annoyances I always had when I was a developer, especially as a contractor, was that the skills that employers demand are often changing, and so you have to constantly have one eye on your CV and staying up-to-date with new things. So for this reason there are very few people with deeply-specialised knowledge. Whereas if there was a single standard for something, that was so fixed in stone that it wasn’t going to change, people could actually develop those deep skills that make the best developers so much more productive than the rest.Maybe the answer is for the big boys to band together behind one technology and just give it a massive push. Of course, techies will complain that their personal favourite technology didn’t win, but anyone decent can pretty quickly pick up a new language.The impact on project management and productivity of this kind of standard would be immense.
Bravo. I am in the middle of a number of web application projects, some with PHP/DB_DataObjects/Smarty and some with Perl/Class::DBI/Template::Toolkit. My hunch is that a good first step would be to get the Smarty and TT folks talking. The differences are trivial when you get down to it.We are starting to see common conventions on the database side as well (I mean around table naming, column names, etc.). Who really cares what language the glue is written in, when you get down to it (Ruby, Perl, PHP). I have been porting a Java/Struts application to PHP which has been a pain in the rear. I see distinct benefit in web application “best practices” (or conventions at least) reaching language-agnostic consensus.