What is the benefit of rendering JSON in string format in page response itself. One can render the page and can load data via ajax too when the page has rendered.
What should be the best approach based on usability issue. I know Angular is great, but what is the best approach here to make a SPA.
You need to balance two opposite requirements:
- the more data you send (either as formatted view or as information to enrich the view), the faster the application will be ready and the less you will have to rely on further AJAX calls.
- the more data you send, the longer it will take to load the application.
So there is not one rule that fits all. As a rule of thumb, data that you're going to need anyway can just as well be loaded from the start. Where you load it and how you do so depends on its nature.
Data that might be needed - but then again, not - is better left not loaded, and deferred to further AJAX calls should they prove necessary.
Another important factor is how you're serving your data and to whom. Browsers supporting request pipelining, for example, can make multiple AJAX calls scalable enough for your purposes. If you don't have this advantage, you might find it useful to do the pipelining yourself, multiplexing several AJAX calls into one to reduce latency and often improving compression performances. This, on the other hand, impacts on application flexibility because it increases de facto coupling between functions.
With this in mind let us see your options:
- Load the page (kind of blank) and then do a hit via ajax calls via Angular and fill the data into the page. This could have loading effect initially.
- Load everything in html form page initially via server side code. No ajax request on load of the page this time. If a user wants some more data I can do an ajax request via Angular further.
- Load JSON, the data for the page (in stringify format in script tags) + some html. The JSON data will be used to by Angular for templating and render the html there only. No ajax request is made this time too on page load since I rendered the data in json format along with page source.
We need to distribute the content between these three strategies.
- HTML that's not very repetitive, and is going to be immediately needed anyway -- why load it via AJAX? Better to include it from the start. What is to be gained loading it later, except latency?
- HTML which is not very repetitive, but is not immediately needed, can be loaded in the background as HTML. This speeds up initial page load, improving the application responsivity.
- HTML which is very repetitive (lists, etc.) might be more efficiently divided into an HTML template (one list entry) and the data needed for its rendering, to be sent as JSON. The difference in weight between the fully developed single HTML list entry, and the JSON data it distills into, indicates the desirability of this option. Clearly if the size of the JSON is the same (or maybe even more) than the HTML, there's no point in sending it as JSON. Except if this could help lessen the load on the web server; for busy servers this can be a factor. Also, if you need to update the list afterwards, you're already going to have to template the data. Sending it in both HTML and JSON forms is prone to errors. Better have only one rendering mechanism.
Also, consider the lifetime of the information. Different pieces of your application might have different shelf lives: the template for a list entry is not likely to change too often, while the list values might. By bundling all long-lived resources together, you maximise the bang for the buck from the various caching mechanisms (browser, proxies, etc.) involved.
This has to be kept in mind if you for example decide to bundle some resources (such as icons, etc.) as inlined base64 values. While you do reduce the number of HTTP calls required, you might increase disproportionately the traffic needed by those same calls.
Say you have one page with ten icons and a CSS:
unprimed web page, unbundled 12 HTTP calls for 80 Kb
primed web page, unbundled 1 HTTP call for 4 Kb
unprimed web page, bundled 3 HTTP calls for 108 Kb
primed web page, bundled 2 HTTP calls for 75 Kb
Bundling the resources together improves responsivity for the unprimed user, the first time he fires up the application. Then caching steps in, but the data package that needs to be sent every time is still quite large.
The unbundled version is worse for the first-time user, but on subsequent reloads most information is already stored client-side and generates cache hits and no traffic, yielding much better results than the bundled version.
The point here is that organizing data differently, or having a differently architectured application, could just as well give exactly the opposite result, with a strong indication for bundling everything (or almost everything).
TL;DR
I guess what this all boils down to is, You need to have a clear model of what the application is going to do first. Dividing the data cake between the different strategies needs must come later.
