What are benefits of serving static HTML and generating content with AJAX/JSON?

Question

http://blog.urbantastic.com/post/81336210/tech-tuesday-the-fiddly-bits

Heath from Urbantastic writes about his HTML generation system:

All the HTML in Urbantastic is completely static. All dynamic data is sent via AJAX in JSON format and then combined with the HTML using Javascript. Put another way, the server software for Urbantastic produces and consumes JSON exclusively. HTML, CSS, Javascript, and images are all sent via a different service (a vanilla Nginx server).

I think this is an interesting model as it separates presentation from data physically. I am not an expert in architecture but it seems like there would be a jump in efficiency and stability.

However, the following concerns me:

---

• [subjective] Clojure is extremely powerful; Javascript is not. Writing all the content generation on a language created for another goals will create some pain (imagine writing Javascript-type code in CSS). Unless he has a macro-system for generating Javascript, Heath is probably up to constant switching between JavaScript and Clojure. He'll also have a lot of JS code; probably a lot more than Clojure. That might not be good in terms of power, rapid development, succinctness and all the things we are looking at when switching to LISP-based langauges.

• [performance] I am not sure on this but rendering everything on user's machine might lag.

• [accessibility] If you have JS disabled you can't use site at all.

• [accessibility#2] i suspect that a lot of dynamic data filling with JavaScript will create cross-browser issues.

Can anyone comment? I'd be interested in reading your opinions on this type of architecture.

References:

1. Link to discussion on HN.
2. Link to discussion on /r/programming.

Answer 1

"All the HTML in Urbantastic is completely static. All dynamic data is sent via AJAX in JSON format and then combined with the HTML using Javascript."

I think that's the standard model of an RIA. The emphasis word seems to be 'All' here. Cause in many websites a lot of the dynamic content is still not obtained through Ajax, only key features are.

I don't think the rendering issues would be a major bottleneck if you don't have a huge webpage with a lot of elements.

JS accessibility is indeed a problem. But then, users who want to experience AJAX must have JS enabled. Have you done a survey on how many of YOUR users don't have it enabled?

Answer 2

When AJAX began to hit it big, late 2005 I wrote a client-side template engine and basically turned my blogger template into a fully fledged AJAX experience.

The thing is, that template stuff, it was really easy to implement and it eliminated a lot of the grunt work.

Here's how it's was done.

<div id="blogger-post-template">
<h1><span id="blogger-post-header"/></h1>
<p><span id="blogger-post-body"/><p>
<div>

And then in JavaScript:

var response = // <- AJAX response
var container = document.getElementById("blogger-post-template");
if (!template) { // template context
    template = container.cloneNode(true); // deep clone
}
// clear container
while(container.firstChild) 
    container.removeChild(template.firstChild);

container.appendChild(instantiate(template, response));

The instantiate function makes a deep clone of the template then searches the clone for identifiers to replace with data found in the response. The end result is a populated DOM tree which was originally defined in HTML. If I had more than one result I just looped through the above code.

Answer 3

The advantage is, you can serve 99% (by weight) of the content through CDN (like Akamai) or even put it on external storage (eg. S3). Serving only the JSON it's almost impossible for a site to get slashdoted.