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.

9 comments:

creed - Uchitha said...

Hasith,

A very useful post again.

Single Page Applications (SPA) are certainly cool, however I still struggle to understand how relevant they are for most applications/scenarios. You have mentioned limitations of the DOM to act as a platform, but I see a few more fundemental issues. May be you can clarrify few things thats stopping me from taking the pill.

1. Lack of support
The tools, frameworks, patterns and best practices for SPA is still not widely known in the community. This could be the reason why I feel that the benfit(s) of moving to SPA still outweights the cost(s) for most solutions and workplaces.

2. Does it really improve 'usability'
Although performance is one compelling reason to consider SPAs, relevance of the 'modified' user flow (Or non-linear user experience as you mention) to your solution is far more important. In some applications it's difficult (or not economical) to design the application as SPA while keeping the design simple and user experience coherent.
e.g. In gmail it's all about sending email which is a fairly restricted use case and is reasonable enough to be treated as a SPA. But in a typical Enterprise Application having several differnt users and use cases this becomes tricky.

While having my doubts, I really like the approach JIRA has taken. Probably this could be a fundemental approach to be taken when designing/migrating Enterprise Applications to the 'Windows Store' (Or 'App Store'/'Google Play' although I don't think it'll happen). Each part (usecase/business case) of the application could be different 'Apps' (SPAs) that are being tied together by a backend state server.

Interesting points to discuss.

Thank you so much.

Hasith Yaggahavita said...

I agree to what you say... in reality almost all web applications today are SPA to some extent.. who doesn't do async JS call to server and update the DOM? it is more a question of how much SPA really.

There is a fundamental problem I see in approaching SPA applications. For any other language like Java, C#, Ruby we expect people to learn before code... but the only unfortunate language is where everyone expect you to code without learning is JS.. with first order functional and prototypical inheritance it is massively different to other languages, and we today dive to SPA deepend and complain on lack of tool support... Just my experience... if you learn it well development time is factors faster... and tool support is immense...

Hasith Yaggahavita said...

Also see my recent post Simplicity Misunderstood... SPA approach helps to reduce 'perceived complexity' of the applications interfaces..

Nicholas said...

I just discovered BoilerplateJS today, so bare with me, please.
If you use an approach like JIRA, can your modules still communicate with one another using the Boiler.Context event messaging system?

I need to create an application that navigates like the JIRA app you're describing and I need to do it very soon. I would like to look into using BoilerplateJS for this, but I'm not familiar enough to know how to set up an app to let subapps have completely different entry points. Do you have an example?

Thank you for your time!

Hasith Yaggahavita said...

Even though the Boiler.Context events are included in the reference architecture for the sake of completeness, I really do not recommend someone to use it unless you are really sure about what you do.

The problem of using events is that you are not able to bookmark/history track when you navigate using that. Always try to use the URLController and every navigation to have it's own URL hash. This allows users to use the back button and also to bookmark a particular panel for later access.

Anyway if you use separate entry points, events will not propagate across. Because events are only routed within the same DOM. Separate entry points will have separate DOMs as page refreshes will take place when moving between.



SAURAV PAUL said...

Hasith, Nice explanation. I am confused with point "Multipage applications download entire application layout content with almost every user action, slowing down the response time" In typical Enterprise Application using JSF/ Struts it doesn't load entire layout? And how normally people achieves role-based authorization in JavaScript Application?

chathu said...

Hi,

Great post. I've recently jumped into SPA and I'm wondering how you take the decision to go for SPA against traditional multi-page application. What you should consider before taking that decision?

Mohamed Jubair said...

very good post. Easy to understand.

Single Page Applications

Mohamed Jubair said...

Very Good Post.Easy to understand.


Single Page Applications