JavaScript

Client-Side Rendering Approach – Good & Bad

Traditional web applications send all the work to server which processes the requests and returns generated HTML pages back to browser to just render them at client side. Server performs all or majority of the tasks hence heavy traffic to server is an overhead. Modern web applications process and render entirely on the browser and requests server only to handle data. While there are several compelling reasons for choosing client-side rendering model, it is also important to aware of the trade-offs with it. Note the article covers benefits and trade-offs with client-side rendering, little more other than runtime aspect.

Benefits:

Rich interactive user experience. Since UI content and modules are loaded upfront and the need for reaching out to server is only for data, sub-sequent user interactions will be super-fast and gives the close to native app experience. The JavaScript MV* frameworks make it easier to create building blocks of Single Page Applications – routes, controllers, views, services, etc. Other UI frameworks like Material Design and Ionic make the visual appearance and animations rich and native app-like experience. As an end user everyone likes if the app looks prettier and highly responsive.

Overall system performance. In the traditional server-side processing approach, the design lets server to perform almost every tasks during user interactions with the system barring handling very minimal tasks in browser that normally increases number of hits to server hence the workload. The client-side approach lets Server to handle only data related requests that reduces the traffic to server and overhead significantly, results in higher efficiency and reduced response time for the overall system.

Separation of UI concerns. When the web was immature, server performing UI logic was unavoidable though some were managed to handle it in different ways. With the birth of new JavaScript frameworks, it makes lot more sense to define the UI specific responsibilities clearly at client side. The UI and server side components can be designed, developed, tested and deployed independently with specialized tools, frameworks, skills and practices for them.

Taking advantage of powerful modern Browser capabilities and Web Technologies. Modern web browsers are capable of performing more intensive tasks than ever before as smart phones, tablets and computers have loaded with powerful hardware and operating systems. While web is improving everyday with HTML5, CSS3 and ECMAScript 6 (ES 6 or ES 2015), the other frameworks like Angular, Ember, Backbone, TypeScript, React, Ionic, Material design, etc. (yeah its a long list) are taking web to next level to build some amazing web apps focusing on responsiveness, quality, performance, efficiency, productivity and scalability. Every day we hear about a new framework or library coming out and existing ones introducing new generation of features. The entire community is working hard continuously to make the web better at rapid phase.

Unified language and skills. The primary programming language in the context is JavaScript. While Node.js is becoming increasingly popular to write server-side code, using JavaScript for UI goes without saying. They can leverage the same resource skills and possibly reuse common components/ logic at both server and client sides.

Industry movement. There is clearly a moment driven by the vibrant open source community, their culture and commitment to make the web better and better every day, more enterprises are opening door to share their solutions that worked for them (popular few are Angular from Google, React/flux from Facebook, interesting to note Walmart Lab’s Electrode bolt), witness extensive collaboration between developers. On a side note, in general this factor has forced Microsoft also to be more open than ever before, to remain in the picture and be more attractive to developers.

Trade-offs:

Critical initial page load performance. Although bringing required files to client side upfront helps subsequent performance, certainly affects performance of initial page load, results in blank screen for few milliseconds. There are techniques to improve this experience using template caching, minification, bundling, sprite, etc. Still, it could be a deal breaker for some business like Twitter had recognized the impact earlier and went back to server-side rending as their user base is across the globe and internet speed is far slower in many countries. It might not be an issue for most LOB applications, however you must consider this if it is critical for your business.

Web crawlers support. Web Crawlers are headless search engine programs which crawl website regularly to index them and make them appear on web search results (SEO). Unlike server side rendered applications, client-side rendering apps don’t produce final HTML directly from server hence Web Crawlers cannot have the expected content and index them which affects the SEO benefits for internet facing web applications. Googlebot and Bingbot (crawling robots) are here to rescue, which are capable to execute JavaScript during crawl and improve the SEO. For those it is critical have come up with alternate solutions to generate initial page at server and the rest at client to take advantages of both worlds.

Inconsistent performance. Performance of server-side rendering is consistent for the fact that browser has less to do with processing and almost none in producing HTML. Other hand, client-side model runs the entire app on the browser, performance and behavior vary largely based on capabilities of user’s devices. This might not be a problem for most enterprise applications if their users are internal associates and they use managed devices.

Duplication. Unless you are going with Node.js at server, you would repeat building another set of cross cutting concerns and services for UI such as routing, logging, caching, etc. Also, you would have duplicate set of build systems, testing frameworks and tools.