JSON is a good architecture for transfering data to web browsers, but a poor architecture for transmitting data associated with layout.
Using JSON For Page Rendering
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
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.
- Render the HTML Layout on the server
- Render the JSON objects on the server
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.
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: