A few weeks back now, we started the development of our new web application BeeBole.
Of course we had to make several important choices for our IT architecture.
We started by choosing a light, flexible and really fast back-end as mentioned in our post: Why Erlang ?
For the front-end, we wanted the browser to be the center for rendering and aggregating services. (Read our post about True Aggregation, the Browser as a Platform).
To achieve this goal, we had to decide for:
- a communication language between the browser and the back-end: JSON ? XML ?
- a template engine to render the back-end services in HTML
We chose jQuery as our JS library (the reasons of this choice will be detailed in a future post).
We decided to go for JSON as the preferred communication language between the browser and Erlang.
The main reason being:
Don’t get me wrong. It doesn’t mean that we are closing the door on XML and that we won’t aggregate XML services from other API’s in our solutions. It took almost 10 years for the IT Industry to replace ASCII files with XML. And nowadays, you can find plenty of API’s working with XML. So XML is here to stay.
But receiving JSON data in a browser simplifies the developer’s life dramatically.
For years, although very unpopular amongst developers, we really enjoyed XSLT to render XML.
Granted, it’s exponentially verbose and it takes a while to be comfortable with both the clunky syntax and the pattern programming.
However it’s amazingly powerful and its rendering speed is impressive, especially in IE.
We started venturing around the web hoping to find the template engine we needed.
We liked the “JS/HTML only” approach but not the use of the imperative kind of <%..%> tags and programming.
At the same time, we started to build a template engine. We first tried a version that was DOM based and which was so heavily inspired by XSLT that we called it JSL
But in the end, it was a disaster in terms of performance. Only Safari 3 on Mac had a decent rendering speed, but still too slow for our planned usage. IE was by far the slowest.
What we didn’t like, was having to install Perl to build templates, and the [%..%] tags either.
We wiped out JSL from our git repository and decided to go for Jemplate.
But the same week I saw a post about templating on Mootools by Zoltan Vrana. Then a comment drove me to Mario Valente’s blog. He was detailing other existing approaches and was sending this message in a bottle:
It blew my mind!
Our wish list for a template engine was as follows:
- it should provide the 4 key templating functionalities: assign values, include templates within templates, iterative and conditional statements
- it should be totally unobtrusive (no % tags of any kind)
- it should compile the templates in JS for fast rendering and bandwidth savings
After some more research, we didn’t find anything like that. So we turned our wish list into a reality by building PURE, standing for PURE Unobtrusive Rendering Engine.
Past the excitement of finding such a nice acronym, we discovered that it was a totally new way of building web pages.
The main surprise is that there are no real templates anymore. And no template language either.
But then, any HTML portion of this modified page can be reused as a source for a new rendering, and so on.
This ability to dynamically generate new templates on the fly, radically changes our way of building web interfaces and the HTML rendering in general.
As we thought it might help and inspire others, we decided to document it and make it Open Source.
And here are various links of the PURE project:
- The Google Group to get support and share tips/ideas
- The PURE on Github for technical documentation
And if you end up liking PURE, the best you can do for the project is to promote this post by clicking on the Share button hereunder and promoting it on your favorite social bookmarking.