Thoughts on web templating, Enlive, XSLT and jQuery

Web templating is one of those perennial problems that comes up again and again in my life. By “templating”, here I mean the definition of abstract web view components that are combined with dynamic data to create web UI. I should start by saying that if you don’t see why JSP / JSTL / Velocity style templates kind of suck, this probably isn’t the blog post for you.

One of the main reasons I dislike those technologies (not to say we don’t use them – we have a load of Freemarker in our apps) is that you start with a working HTML mockup of an application (if you’re design-led, as we’ll be until we have enough users to be led by them!), and you end up with templates that no longer work as an HTML mockup. If you want to keep responsive to changes to the design, you have to keep the mockup in sync with the templates manually. Life’s too short!

So I have a very simple ideal for a templating technology: Templates should work as HTML / JS files. The impact of this on the design and development process is huge – design revisions can be worked directly into the templates. This isn’t a breathtaking or novel observation, but it’s useful to remember before building around a sucky templating technology, and it serves as a neat segue to talk about Enlive, which I’ve been using for an in-house web app development (along with Compojure and Ring).

Enlive works by defining a template as a series of mappings from a node selector to a function of the selected nodes. There’s a tutorial for Enlive that starts by showing you how to use Enlive to produce reports from scraped web pages. As far as I know, it’s more commonly used to add variable data into HTML files (the tutorial goes on to this), but it could just as easily be used to to transform XML into various different formats. Which started me thinking about XSLT, and then about jQuery.

Enlive, XSLT and jQuery are similar in a number of ways. In each you build a transformation based on a source document and a series of #{node selector, function of selected nodes} pairs. It’s not quite so obvious that you’re doing this in jQuery as it is in Enlive or XSLT. They all allow the source document to be in some way ‘valid’ on their own and unencumbered by transformation code.

There are two things that strike me as being different. Firstly, the list handling and function calling in javascript or Clojure is leagues better than XSLT. Secondly, Enlive is limited to server side processing, whilst jQuery[1] and XSLT[2] could both be made to process either client- or server- side. Although more and more of this kind of processing goes client-side, there are still situations where you need server-side templating – to producing your RESTful representations if nothing else.

1 – I haven’t tried it, but env.js looks a likely candidate.
2 – Although I’ve little experience in getting XSLT to work cross-browser. I imagine it’s unpleasant.

Be in the FROW

Receive the latest fashion trends, new collections and perks

You may also like

Metail is proud to announce the arrival of Bree - our new and improved MeModel

As of Monday the 8th of May, after a year of hard and dedicated work from our MeModel, Garments and...

Read More
“I’m the only girl in my class”:

What supervising a 14-year old’s work experience meant to me by Data Scientist, Erika Nitsch Why are young women underrepresented...

Read More
Get Colourful with Kahlo

So your summer sandals and bathing suits may be living at the back of your wardrobe already, but we feel...

Read More