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.
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.
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.