A lot has been talked about client side view templates hindering the critical path, thus affecting performance. I have made an effort to summarize the need for client side rendering and measures to enhance the performance.
Before we actually jump on to measures, lets revisit how today’s web application ended up being rendered and compiled on the client (browser) using javascript based templates –
Before the advent of nodejs and javascript templates, how did one used to render json data on the browser ?
Front end developers (FED) used to write prototypes based on html, css, jquery and hand this over to the backend developers. Backend devs take this asset and integrate it with the java code, parsing the json themselves directly in the servlet or jsp. Here, it takes only one call for the page to load and FED can focus on optimizing critical path, gzip the assets, etc thus improving the performance. This really worked well when we had only one or two FEDs for the whole project and a waterfall approach was followed. Designers used to provide the comps, UI developers created pixel perfect prototypes, and no design changes were allowed once the development started.
And then, what happened ?
Coming back to where we are today, as the web evolved, more focus is put on User Experience, and with the introduction of LeanUX, design and development are being done simultaneously. Now, backend developers cannot change the html in the jsp or servlet every time the design changes and becomes frustrating for them and they don’t see the need to do that at all. Enter jQuery and ajax. FEDs can make an ajax call to the RESTful service, parse the json and render it on the presentation layer, i.e jsp. But, this resulted in a convoluted mess of spaghetti code and became hard to maintain as the application grew.
Same time, javascript became more mature and nodejs was introduced. With the help of nodejs, enter client side templating – handlebars, mustache, htmlbars, etc. These templates are logic less (no if, else, for loop statements in the html) and provided a clear, neat separation of html and data paving the way for a true MVC architecture on the client. Both front end developers and back end devevelopers are happy as FEDs can focus on neat reusable, DRY html with dynamic data while backend developers can focus on generating the RESTful API service, data binding and need not worry about design changes at all. Because, data parsing is completely done on the browser now. To help with this data parsing and templating for the FEDs, a host of task runners to improve performance, based again on nodejs got introduced – grunt, gulp, etc. So that, FEDs can focus on the html and the task runner can do all the performance optimizations for them. Wonderful, isn’t it ?
So, what is the disadvantage of this client side templating ?
With client side templating, every ajax call we make, there is an extra http call on the browser, and the template has to parse this data as well as render itself on the browser. Enter performance issues and critical path rendering.
How to remediate ?
Fallback to nodejs for solutions again. Client side templating is still fairly new and as the web progresses, definitely the focus will be on ways to render the data on the server itself. There is already htmlbars, which is out to do that as mentioned here, here and also here.
Ultimately, the advantage of separating html from the backend code and allowing front end developers to make robust design changes concurrent with the development cycle has proved more advantageous, than the performance issues with the client side templating.