Thursday, November 29, 2012

How much 'multi-page' a 'single-page' application can be?

Title seems confusing??? mmm, yes.. it reflects the state of my mind on this subject! 
With HTML5/JavaScript hype, the trend today is to create the every web application a single paged. Look around to see the most famous web applications.. most of them are single page applications with heavy use of JavaScripting.
Question: First of all, why do we need to create our web applications single paged? 
Answer: It sounds cool and techie !!!
A funny answer.. but unfortunately the common approach too (smile)... May be a better answer is that.. 'We go single page to improve our user experience'

Now, how can a single page application improve usability?  
  • Multipage applications download entire application layout content with almost every user action, slowing down the response time 
  • Browser spend significant time in re-rendering the entire application for each server round trip (DOM is slow), slowing down the response time 
  • Rendering on server may have high demands on server side ultimately impacting user response time with higher loads 
  • Roundtrip makes the browser to blink at reload distracting the user engagement with the application 
  • Single page code bases are cleaner due to clear separation of concerns (API and UI).. resulting faster time to market 
  • Single page approach empower us to create a non-linear user experience that is completely different from form/page driven experience of multipaged web

Sounds great.. But can they be held true all the time? May not be.. there are some pitfalls of 'single-page' approach too:
  • Browsers are not the best species in memory handling and garbage collection. Specially when it comes to DOM handling. For example, elements removed from DOM are stil held in memory. If we let users to work on DOM for a long time without a refresh, Browser might struggle to cop up with memory issues 
  • We should ideally reuse as much as DOM elements without disposing. But even with that approach, if the user creates thousands of reusable DOM elements as she uses the application, browser may suffer in coping up. On the other hand, the memory leaks created by bad coding practices will too pile up in a long lived DOM. 
  • If we need the complete product suite functionality to be available as a single page application, it can be too much of JS/CSS code to be loaded at once impacting the initial load time.

Probably we will need to look for a solution that let us enjoy the best of both worlds..
  • If we study how Facebook operates, we notice it works as a single page application (long lived DOM) in general. But time to time, with a user action, it reload the page entirely causing a new DOM to be formed. With this approach Facebook ensures users do not continue working on the same DOM for a long stretch. 
  • If we look at how JIRA works, we can see a different approach to it. JIRA is a collection of single page applications. Each of the sub application works as a single page application but when traversing between sub applications, it refreshes the DOM (behave as a multi page application).

What flexibility is there in implementing this with boilerplatejs?
It is not difficult to implement the approach taken by JIRA with already existing boilerplatejs architecture. Each of the sub application can be of completely different entry points (meaning we will have different main.html files for different sub applications). This ensures page refresh when users move between sub applications, causing the DOM to refresh.
Each entry point will only include the scripts that are necessary for that sub application to operate. These scripts can be of:
  • Third party scripts such as jQuery. These will be served from a central CDN allowing caching 
  • Common Scripts such as boilerplate 'core/context.js' 
  • Specific custom scripts of the particular sub application such as viewmodel, component, etc.
The latter 2 will be compiled in to a single script per application by BoilerplateJS optimizer. Meaning even the core classes will be in sub application script for each and every entry point. In contrast, it is possible to separately compile the core framework classes allowing separate caching of the same. But the benefits are not worth the trouble in my opinion, because doing so restricts the developers selectively using 'core' scripts in their applications.