Client side rendering is getting popular now a days. Let me give a little bit of background and share my view that client side rendering is a good thing.
In pre historic days when MVC was not much popular, people used to write simple javascript to render a HTML page. However, managing this form of page is hard, because if you want to do a simple test like give 10%age of your users a new look and feel of the page to test whether people will like that new UI, will make all if - then - else statements inside of the javascript. As the requirements get complex, the UI get complex and javascript becomes unmanageable.
Then comes MVC world, where view layer is clearly a seperate layer managed in the server. Like some uses JSP as the view layer or template engines like Velocity as the view layer. For a velocity type of engine, UI developer writes the skeleton of the HTML page, server sends the model (data) and the template to the template engine and template engine renders the final HTML by merging the template with the data. Spring provides integrations with such template engines to resolve the views. This was a good strategy untill Ajax came into picture. In case of Ajax, the basic webpage loads fast and then lots of small fragmented request goes to the server and server sends back smaller data set back to the client. Now usually serer sends back small JSON objects and there needs to be some unit at the client side which will read this JSON and render the HTML. This pushed the concept of template engines to the client side.
Client side template engine like dust.js or mustach has similar concept like velocity template, they take the template and the data as the input and renders the HTML. Only difference is that it happens at the front end and not at the back end. One can push this concept little further and instead of the using Ajax, from the first request itself, they can use client side rendering. The flow goes something like this -
In pre historic days when MVC was not much popular, people used to write simple javascript to render a HTML page. However, managing this form of page is hard, because if you want to do a simple test like give 10%age of your users a new look and feel of the page to test whether people will like that new UI, will make all if - then - else statements inside of the javascript. As the requirements get complex, the UI get complex and javascript becomes unmanageable.
Then comes MVC world, where view layer is clearly a seperate layer managed in the server. Like some uses JSP as the view layer or template engines like Velocity as the view layer. For a velocity type of engine, UI developer writes the skeleton of the HTML page, server sends the model (data) and the template to the template engine and template engine renders the final HTML by merging the template with the data. Spring provides integrations with such template engines to resolve the views. This was a good strategy untill Ajax came into picture. In case of Ajax, the basic webpage loads fast and then lots of small fragmented request goes to the server and server sends back smaller data set back to the client. Now usually serer sends back small JSON objects and there needs to be some unit at the client side which will read this JSON and render the HTML. This pushed the concept of template engines to the client side.
Client side template engine like dust.js or mustach has similar concept like velocity template, they take the template and the data as the input and renders the HTML. Only difference is that it happens at the front end and not at the back end. One can push this concept little further and instead of the using Ajax, from the first request itself, they can use client side rendering. The flow goes something like this -
- User request the webpage on the browser
- webpage sends the request to the server
- server send back a basic html which has reference to the client side template js and the precompiled js files
- Server does not close the connection, but keep flushing JSON data as and when ready to the same client connection
- On the client side, template engines take the template name and the JSON data and renders them
- Load on the server reduces as the server is not merging the template with the data, its the client side browsers that are doing it. So this solution is scalable as the server load goes down
- Since javascripts can be cached by the browsers, so once the page is loaded, sub sequent operations on the page becomes faster as the template engine and the pre compiled javascript templates are already loaded in the browser memory.
No comments:
Post a Comment