Geek Answers Handbook

What are the benefits of serving static HTML and creating content using AJAX / JSON?

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

A hit from Urbantastic writes about his HTML generation system:

All HTML in Urbantastic is completely static. All dynamic data is sent via AJAX in JSON format, and then combined with HTML using Javascript. In other words, the server software for Urbantastic only produces and consumes JSON. HTML, CSS, Javascript and images are sent through another service (Nginx Vanilla Server).

I think this is an interesting model because it separates the representation from the data physically. I am not an expert in architecture, but it seems that there will be a leap in efficiency and stability.

However, the following concerns me:

  • [subjective] Clojure is extremely powerful; Javascript no. Writing all the content in a language created for other purposes will create some pain (imagine that the code is Javascript type in CSS). If it does not have a macro system for generating Javascript, Heath is likely to constantly switch between JavaScript and Clojure. It will also have a lot of JS code; probably a lot more than Clojure. This may not be very good in terms of strength, rapid development, conciseness and everything that we look at when switching to LISP based langauges.

  • [performance] I'm not sure about this, but everything that may be on the user's computer may lag.

  • [accessibility] If you have JS disabled, you cannot use the site at all.

  • [accessibility # 2] I suspect that a lot of dynamic data populated by JavaScript will create problems with multiple browsers.

Can anyone comment? I would be interested to know your opinion about this type of architecture.

Literature:

  • Link for discussion of HN.
  • Link for discussion / r / programming.
+4
source share
3 answers

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

I think the standard RIA model. The accent word seems to be "Everything" here. The reason on many websites, many of the dynamic content is still not received through Ajax, only key features.

I don’t think that rendering problems will become the main bottleneck if you don’t have a huge web page with a lot of elements.

JS availability is really a problem. But then users who want to experience AJAX must have JS. Have you done a survey on how many of your users do not have this?

+2
source

The advantage is that you can serve 99% (by weight) of content via a CDN (e.g. Akamai) or even host it on external storage (e.g. S3). Serving only JSON is almost impossible for the site to get slashdoted.

+1
source

When AJAX started to hit hard, at the end of 2005 I wrote a template engine on the client side and basically turned my blogger template into a full-fledged AJAX experience.

The fact is that this template material was really easy to implement, and it eliminated most of the grumbling work.

Here is how it 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 instance function makes a deep clone of the template, and then searches for a clone for identifiers to replace with the data found in the response. The end result is a populated DOM tree that was originally defined in HTML. If I had more than one result, I just got stuck in the code above.

0
source

More articles:


All Articles