JSON stands for JavaScript Object Notation. JSON is a plain text standard for transmitting data in asynchronous calls. It uses keyboard characters such as brackets and colons to allow a developer to organize data into key value pairs and arrays. After a string of JSON encoded data is delivered to the browser, the javascript eval statement is used to turn it into a javascript object.

Many developers incorrectly equate JSON data transfer to single page web application architecture. This association has significantly delayed the progress of the single page web application paradigm because delivering all data to the browser using JSON is excessively complicated to code and therefore requires heavy client side frameworks.

The typical single page web application, using JSON architecture, is implemented by trying to simulate classic client server architecture. When the web page is first delivered to the browser, only the layout, minus the data is delivered. Then, a second trip is made to the server to retrieve the data, in JSON format, which is then unpacked from the data object and written to the DOM objects in the page. Interestingly, this is only an approximation of client server architecture because in client server the layout and the controller originated on the client to begin with.

Coding this kind of architecture is tedious and labor intensive, because the developer needs to render the GUI three times, for every page.

1. Render the HTML Layout on the server
2. Render the JSON objects on the server
3. Unpack the JSON objects into the layout on the client using javascript

There are widgets and libraries that attempt to do these things for you, but they are really just automating something that is a bad idea to start with. Secondly, like any library of tools one can use, you get locked into being able to do only what the producers of these libraries thought you might want to do. Finally, many of these libraries are RAD Web Application Development Frameworks which utilize architectures that tightly couple memory objects on the server to their associated widgets on the client, making these libraries brittle and memory resource intensive.

Rendering data into a web page using the JSON model often performs poorly on the browser for large pages. A simple example and common situation, is when a table with multiple rows needs to be rendered. Since each row of the table has to be laid out in HTML before the data is inserted, the developer has to have a hidden row template already present in the page. The template is cloned and then updated with the JSON data, from a JSON array, for each row of the table. Making the browser grind through a javascript loop of cloning and populating the rows in a large table will cause the user to sit through significant delays during the page rendering.

There are situations where the JSON paradigm is a good fit, but these situations are limited to data transfer only, where very little or almost no layout is involved. For example, using JSON to retrieve a list for an autocompleter is an almost perfect fit.

Dynamic HTML inclusion is a much better architecture for delivering new content to a single page web application than JSON is. Developers only have to render the content once instead of 3 times and browsers perform well when injecting HTML into a subsection of the page, because they use the same engine they do when rendering a full page. WebRocketX leverages this paradigm by adding structure to it.

References On The Web:

JSON Organization