Yesterday I came across this excellent article by Pamela Fox – http://blog.pamelafox.org/2013/05/frontend-architectures-server-side-html.html. In it she goes through how her company uses all three stated architectures, discusses why, and how they are used by the end users. It struck me as fascinating because I feel like we are going through this exact same struggle in the XPages community – what is the best architecture to create applications for our users? I also feel fortunate to have experienced all three (to an extent) in the past 18 months and I can empathize/understand Pamela’s perspective.
I am writing this blog article to first highlight the original article, but to also put an XPages spin on it and discuss some of the point raised therein. I have been meaning to write on this subject for a while and Pamela’s article said it better than I could because she has real examples to discuss whereas mine was all hypothetical.
Please read the article before continuing, otherwise the context would be rather lost 🙂
Server-side HTML (“Web 1.0”)
“This architecture suffers the most in terms of usability – it’s very hard for users to do many interactions in a small amount of time – but it does have definite benefits of easy linkability, shareability, and searchability.”
XPages out of the box is a technology built on this paradigm. The tools provided make it quick and easy to create functional applications based entirely on a request-response constant back and forwards to the server. The bulk of the application logic is based on the server and that is very much akin to traditional Lotus Domino development. XPages does at least move Lotus Domino in the right direction, in that we now have partial refresh and the programmatic ability to execute Server-Side logic without having to completely reload the page.
In many senses this is more work than creating a traditional XPages/Notes Domino application because the developer has to code everything by hand – there are no (IBM XPages provided) tools to help develop this architecture.
But the payoff to the end user is significant – the data transfer is as minimal as possible and the transactions with the server are fast – ultimately leading to a faster user interface.
As the application complexity scales, so does the amount of work (and code) necessary to make this happen. This also raises a question about maintainability across an enterprise.
Single-page web apps
With the introduction of the ExtLib Dynamic Content control Single-page web applications are a real possibility within XPages. The user never has to leave the “XPage” to be able to interact with their entire application. With the controlled use of partial refresh the user can move from View Panel, to Document and back again without having to reload the entire page…ever.
This lead to a very consistent, smart, user interface.
The difference between a corporate web application and a “web-site” become more apparent though as the size and complexity of the application increases.
Twitter is a single-page application – but the overall front end user interface features are relatively limited. Maybe 5-10 different screens and most of those are data reading only – the amount of “update” is limited to posting tweets and profile update.
In a corporate application you could have a significant number of “forms” which require update and an equally heavy number of data views. The complexity for keeping this all on one page does not scale well.
Another consideration is the amount of script libraries etc you have to load when the user first accesses the application. More significant if you have to support older IE browsers or XPiNC which cannot handle dynamic script injection via AJAX. If you have 100 “pages” and only one of them uses a specific plugin (org chart for example) you have to load that script library, regardless of whether or not the user is going to access that page or not. That’s kinda nasty.
So what is best for XPages?
I believe that all development decisions should be grounded in the user experience, not on the easy of development. For too long Lotus Notes has succeeded and then failed by allowing people to build functional applications quickly (cheaply) and then having other people mock it for “working” but looking like crap and/or being too “hard” to use.
That said there is a definite bottom-line balance between the $500,000 application overhaul to code everything in the browser and make an amazing application, and the $100,000 application which works great, is maintainable by the in house development team and if 80% awesome on the end user. The builders of amazing Internet websites do not necessarily have the same restrictions and decision makers as “corporate developers“.
So I think the answer is a balance – if you have a large application broken into 5 functional areas, then why not have a widget or single page like application for each functional area?
The point is that there are many factors which go into designing the application architecture from the ground up – and we *ALL* need to understand the *ALL* options so that we can make the right decision for the customer and end users.
Please – discuss 🙂