Generate HTML from a JSON Without any Template but HTML and Javascript
A few weeks back now, we started the development of our new web application BeeLit.
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 JavaScript library to ease the cross-browser issues and advanced DOM functionality
- 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:
JSON is JavaScript, and JavaScript is THE language of the browser that runs the client logic.
When an AJAX kind of call returns a JSON, your JavaScript code understands it natively.
When an XML is returned, in some ways, you have to convert it fully or partially to JavaScript variables. Then the data becomes useful in your browser. This remains true even if you use XSLT for the rendering.
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.
Now, with JSON as communication language, we had to find a JavaScript equivalent to XSLT.
We started venturing around the web hoping to find the template engine we needed.
We first came across the <%..%> family of templating tools: ajax-pages, EJS, trimpath, Tenjin, …
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.
Then we discovered Jemplate. We liked the functional richness (inherited from TT2), the blazing speed and the idea of a compilation of the template to a JS function.
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:
To sum it up, what I would really like is a JavaScript implementation of Meld.
It blew my mind!
I read about Meld and pyMeld. Not being a Python expert, I stopped quickly but it was too late… I was convinced that building an unobtrusive rendering tool was possible. And why not… in JavaScript!
Our wish list for a template engine was as follows:
- it should only be based on JavaScript and HTML/CSS. Nothing else!
- 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.
With PURE, we can start from any HTML page and transform or make dynamic some parts of it just with some JavaScript directives.
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 dedicated website for full feature explanations, downloads and getting started
- The Google Group to get support and share tips/ideas
- The Google Code project 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.
Stay tuned
Very nice! It wins over PyMeld in two ways: it has a much neater, more declarative, way to do iteration, and you can use various selection methods, not just the ID attribute.
If I’m ever pining for PyMeld in a browser environment, I’ll come knocking at your door.
Hi Richie,
Thanks a lot for your very positive comment.
From you it counts double !
For me the big differences are related to PURE running on the browser instead of the server.
As the browser renders the HTML in the end, being on the browser gives much more control on the rendering than having to ask something back to the server.
Then comes the unobtrusivity of the directives. The HTML remains untouched.
You mix these two properties and you get that any portion of the loaded document can become a template again.
This is huge! Ok, just in our garage for now
See http://marijn.haverbeke.nl/mold for another recent and minimalist endeavour in this direction. It does use XML processing instructions () though, which you seem to dislike, but makes event handlers a breeze.
Hi Reggie,
Although the tags are nice, they still sit in your HTML.
In general, the designer provide their HTML. Then developer cuts them in pieces and fills them with obtrusive tags or codes.
With PURE we wanted to make a total separation between the view and the logic, and think we solved this issue.
Designers can continue to work on the HTML, while developers are building the logic during the full project cycle.
And as mentioned in a post above, PURE use not tags of any kind, as a result you can re-use any portion of the loaded document.
Apply new data to it and render it again and again.
When the development of our web app BeeLit will be more advanced.
We’ll post what we’ve learned so far about this totally new way of building HTML screens.
Apache Wicket has a fairly mature and complete implementation of this sort of template system. It takes a serious mind-shift to work with though.
A lot of good comments have been shared on this post directly into Reddit. Here is the link : http://www.reddit.com/r/programming/comments/6uxcl/we_have_created_a_completely_new_way_of_using/
We will later make a summary of the good ideas and share those on the Google Group : http://groups.google.com/group/Pure-Unobtrusive-Rendering-Engine
Generate HTML from a JSON Without any Template but HTML and JavaScript | BeeBuzz…
Learn how we built a truly unobtrusive JavaScript Template Engine that leaves your HTML untouched…
Template code has always been ugly, even in rails. And designers want to be able to use dreamweaver or other visual tools to make templates. Whoever had the brainwave for this idea is a genius. You win the internets. Now the mockup IS the template. You just deleted me a very tedious and error prone job. I might make a rails plugin for this because it is so great.
I’ve worked with this type of template system before (it’s not new). It seems perfect at first, but it proves to have some issues. For starters, while the logic/template separation is very clean, that isn’t always so convenient. It tends to be a little more involved should something need to be changed. It may seem like that the separation will lend itself to division of labor between designers and programmers, but that turns out to be limited. Also, doing this on the client-side isn’t so helpful for search engines, if that is important to your page.
Having said that however, this type of system still has it’s merits. It’s clean, has good SOC, and can off-load some template processing to the client.
@ Darrell: Thanks a lot for your comment! Mic has been the main thinker and contributor to this project (largely).
If you create a rails plug-in, just drop us a message on our discussion group: http://groups.google.com/group/Pure-Unobtrusive-Rendering-Engine. We will always be interested in all kind of evolutions (even if it is just the logic).
@ Trans: Thank you for your comment.
It is true that PURE is still very young and we will learn more from various experiences and contexts, as people will start using it.
PURE came from an internal need as explained in the post and has been built in that sense first.
The main reason of releasing it as Open Source is to benefit from all those external experiences and to share with others having the same needs.
On SEO, again, we created PURE in the development phase of our web app BeeLit for which search engine indexation is not relevant.
We still think the logic behind PURE is good and we will translate it to our Erlang back-end. It could be done on other languages as well.
A comment on Reddit mentioned the use of Rhino and Spidermonkey to have it on the server side.
@ Mirza
Thank you for the link.
If you have experienced Apache Wicket, what was the main difficulties for you in the mind-shift you described ?
I am always happy to know that kind of info to make our documentation and examples better.
Looks very good. One issue I see is reuse of components. For example you might want a login box on every page, which changes state when being logged in.
Can solve Pure this requirement withouth cut&paste the box into every page?
Peace
-stephan
@Stephan, #12
As a login screen is a fairly static HTML you can apply the following procedure:
* Place the HTML for the login screen in a page while you develop
* Set the directives to make it live
* Then compile it to a JS function (with $p.compile)
* collect this JS function, (with $p.getRuntime; See a “how to” at the bottom of the page: http://www.beebole.com/pure/examples/docs/allExamples.html)
* copy&paste the JS functions into a file(.js) that is common to all your pages (probably with your login logic too)
* Then call this JS function when needed. Note the browser will cache this JS file
Thanks for the reply.
Doesn’t sound very usable from a designer view point. And as far as I see doesn’t allow for “push-button” release management, when a developer has to modify all pages by hand for release. Or I don’t get it yet
Peace
-stephan
@Stephan, #14,
I moved this to the discussion group: http://groups.google.com/group/Pure-Unobtrusive-Rendering-Engine/browse_thread/thread/ddfc6b59d286b031?hl=en
And will answer there.
feedback doesn’t have a plural. [you wanted feedback, that's why I'm saying it]