Friday, May 14, 2010

You are using the wrong #templating system for #html.

Use javascript + json + DOM for html templating.

Front end developers know how to use this technology. They know this technology very well, so will be way productive.

No weird new template language to learn and install on every single project.

No dependency on a rapidly changing server side backend... or database, or 3rd party API required.

No taking the html, and turning it into [$%%WEIRD TEMPLATE LANG%%$$] step. Instead you can use javascript, json and the DOM.

Being able to use the templating system either via the browser, or via the server side means there is no dependency between the front end and the back end. Front end developers just need an example json file to work from. Then the back end developer just needs to create the json file.

It does mean you are dependent on a DOM+javascript implementation on the server side if you want to do things like server side caching, and supporting Agents(browsers, bots etc) that do not use javascript on the client side.

Just json files. Just javascript. Just the DOM.

You are (currently) using the wrong templating system.

19 comments:

icebrain said...

Javascript dependency for static content is bad. What happened to graceful degradation?

Besides, that would require yet another HTTP request to the server. More latency, more user CPU usage.

Thirdly, server-side processing templates can be cached. Client-side templates can't.

Jabapyth said...

hmmm caching hmmm performance hmmmm

Lennart Regebro said...

I'm sorry, this blogpost makes no sense. Are you saying that instead of a templating system , you should write a Javascript that constructs the page from scratch?

Pekka Kujansuu said...

Care to show us how to actually do this in practice?

Matt Hamilton said...

I really don't get this.

If you are wanting to use a templating system that doesn't introduce extra tags just use ZPT e.g.:

http://www.slideshare.net/hammertoe/an-introduction-to-zope-page-templates-and-their-use-outside-of-zope

http://www.netsight.co.uk/blog/2010/2/4/zope-page-templates-in-google-app-engine

-Matt

Tim Parkin said...

You'd best come up with some examples in order to demonstrate that you aren't being so stupid as to suggest building a website that only works with javascript enabled.

I'm presuming you have some cunning plan to run javascript on the server to generate html resources - please share!

bkc said...

Wohoo,

I like ZPT so much that I use an XSLT version of it (lxml converts ZPT to XSLT that can be used server-side or client-side).

I also wrote a javascript version of ZPT as well. Both are great.

Not sure what this post is about though without some examples..

Cheers,

Laurence Rowe said...

Quite apart from losing non-javascript users (a small percentage) and being rather slow to render, your site becomes impossible for search engines to index.

Templating systems do suck though, thats why I've been working on XDV which lets you define a simple rules file for merging your content into a plain html theme.

@bkc,
Can you point me at the ZPT -> XSLT conversion, sounds really interesting.

elarson said...

Well it looks like I might be alone here among the commentators, but I think this is kind of an interesting idea. Just to clarify, it sounds like you are suggesting doing templating on the server side by implementing a callback to fill in values or create HTML via Javascript and JSON. Essentially your template system would look like basic ajax calls expecting JSON that you then insert into the DOM.

I could see this working and there is obviously some value in it. The disconnect between templates, snippets and ajax handlers disappears into a unified interface, which is a pretty powerful idea. No longer would you have to consider hints in the request as to what to process and return (html, json, html snippet).

The downside in my mind is that at some point you would have to come up with some tools to make the whole process simpler. jQuery would be a nice start but that would require the Javascript processor on your server have the necessary DOM aspects.

I'd be curious as well what sorts of additions or framework would be needed. For example, most template systems have a means of including or inheriting other templates. This makes it much easier to make your templates modular. It seems like there would be instances where you'd want similar syntax. Of course, that might simply be an anchor tag with a specific "includes" class.

In any case, it is an interesting idea. I'd like to see if anyone has tried it outside of the server side javascript realm.

Steve Lacy said...

Why not just use GWT or SproutCore for your frontend? Why have a "template" at all?

I too would like to see some examples (even if they're non-working pseudocode) of what your idea is.

I also would think that caching and searchability are key issues, but people developing GWT applications don't seem to worry much about this, so maybe it's a non-issue?

Mcweekly said...

Interesting idea. I'm assuming the templating would be done on the server side.

Although I love ZPT (especially because of James Clark's nxml-mode for emacs), traditional templating does create a middle-man between the html coders and the backend. Personally I know zero-design, a bit of html/css/js and alot about templating and backend. Most of my time is spent templating but really I'd rather spend most of the time on the backend :)

The problem I see with the json/dom approach though is similar to issues I've come across with push templating libraries in general. It tends to separate the data from the templating structure so much it feels very disconnected and fragile.

I'm with elarson, seems like some kind of framework would need to be built to eliminate the tediousness of raw dom manipulation. Would that eliminate the middle-man template master or just create a new breed?

David Keeney said...

icebrain: client-side templates are pages and scripts; they are cached, and cached offsite by the client and various intermediate network nodes. So a typical page might be just one request, since the embedding page and scripts are cached offsite, and that one request is bandwidth-frugal JSON.

lawrence: the criticism about AJAX pages being invisible to search engines is valid, but it may not be true forever. Google has its own javascript engine; what is keeping them from having their spiders do jscript rendering?

illume said...

hi,

Sorry for the poor confusing writing in the blog post.

One way of implementing this would be to import 'server side' js first before client side js.

Then it's just a normal dynamic HTML page. Get your json object/s from a URL, or just included in the page as javascript, and modify the page.

At this point, you can save the html and send it out to the client. Or you can start running the other client side JS.

It can act either as completely client side templating, or completely server side templating.

You could do includes by reading other html, and then finding the parts you want in there, and inserting it. Using an include class of some sort would work well I think as you suggest.

However, different front end developers would use different tool kits. eg, one may use jquery, another GWT, another YUI.

I haven't used this technique for a whole project, but it has worked well for parts of it. The server side programmers just produce the json, and the front end ones just produce the html+js. Neither of them have to even see the other persons work - except for the sample json.

No need to translate the html into a template, and no need to have the server side code even finished! Just save a .json file, and the front end programmer can work. They don't need to set up apache, download 32 libraries, run a server on a different OS, get a database set up... and file bugs with the server people, and the admin people. All those problems are removed.

No need to train up the front end programmer in the platform, or the templating language of choice either. Also the back end coders do not have to edit something they don't know that much about (html/css/js), so the quality remains higher.

cu.

icebrain said...

@David Keeney: You can cache the template and the data, but with a server-side solution you can cache a "baked" page with the data in the HTML page already.
Example can be a Slashdot page. If the client has to pick up a template HTML and then fill in the hundreds of comments from JSON files that will take a non-trivial amount of time. Slashdot bakes a static page once and then serves it to multiple clients.

Besides, if you keep the same HTML file and have AJAX requests to update the data when the user clicks something, you'll have to do all those "URL tricks" to ensure the user gets to the right page if he e.g. bookmarks it or send the URL to a friend.

Client-side templating is OK for RIAs, where it's already used. But not for most web sites.

Now, server-side is a different matter. Yes, it's interesting, and you'd end up with a machine-parsable view for free.

Pete Hunt said...

I blogged about this a month or so ago; instead, I decided to use PyQuery on the server side and it achieves roughly the same results.

Lennart Regebro said...

Deliverence or XDV is definitely the future. I've said it before, and I'm saying it again: It's a game changer.

But you still need to generate the HTML that XDV eats, and that is still best done with a templating system of some sort. Personally, I like "templess", but never have a chance to use it, so I'm stuck with ZPT.

Pete said...

Oooh, I thought about this at Pycon in Chicago last year...

I was thinking that you could run a headless webkit on the server to static-ify AJAX applications for non-JS clients (spiders in particular).

Bruce said...
This comment has been removed by the author.
Bruce said...

Doesn't pure do this already?