Mark writes:
I’m glad you bring some attention to application responsiveness, as I have often been on the raw end of poorly performing interfaces. Of course in client/server scenarios on the desktop this is often thread related, but I find this all to often over looked in the web application domain also, particularly where AJAX is concerned. I include two examples that involved AJAX that I have come across.
#1 – Single Page Application
A consulting firm provided a solution that used a single .net aspx page to host an entire application in a similar logic to Google’s gmail. The approach was very organised and quite useful in certain scenarios. Instead of traditional page refreshes, it used custom user controls for each piece of functionality that were loaded on demand through AJAX calls from the central page. What the developer failed to account for was that gmail has a very well defined and limited set of functiionalities that can efficiently be treated in this manner, whereas this system had a far greater scope.
For starters the data loads for some of the custom controls were in the 1000’s of records (the data handling really should have paged the data in my opinion), and secondly, as the system evolved, many custom controls were nested with a list calling a detail view which called an edit view etc., etc.
Unfortunately the AJAX implementation didn’t manage the partial page refreshes well and so multiple layers of interfaces, with all their 1000’s of records, were constantly being handled in the JavaScript updates, making each new addition to a nested interface exponentially slowing the interface’s performance on the client browser (not to mention running the local processor at 100%!). What was worse, system changes were only tested on the developers’ high spec machines before being published. Needless to say a 1 second wait on an interface on a high-spec testing rig, quickly became 10 seconds on the slower end-user machines.
To cut a long story short, we searched for a simple way for us not to have to redevelop the entire system, or perform a complex reworking of the AJAX calls. We found a good compromise by using old fashioned html iframes to host the individual custom controls. This way the application still worked from the single page, but the iframe instantly isolated page updates to only the functionality loaded within a single iframe. Inter-Iframe updates were then handled through some simple JavaScript routines.
#2 – Local Funtionality vs. Server Side Processing. Another project was for a bank’s trading floor. It was in the beginning of the AJAX phenomenon and the requirement was fairly simple…replace several cumbersome Excel sheets used to track certain operations with a more automated solution; the main focus being that the traders have time critical operations and therefore the new solution must speed the processes being automated.
Our initial approach was simple AJAX optimized interfaces. Unfortunately, as the users were already used to the speed of entering data into Excel, even small delays with server round trips due to many AJAX calls being triggered, proved too cumbersome (hundreds of entries per day required the same interface performance as Excel). We realized that most of the AJAX calls were entirely unnecessary and could be processed locally without the server, so we simply moved all of the required interface logic to local JavaScript routines where possible. Any data processing required by the server was performed in the background, so the interface became as responsive as their previous local Excel sheets.
I know my comments aren’t strictly related to multi-threaded programming on desktops, but I think AJAX is often just as poorly implemented in the web world, with just as consequential repercussions.
Asynchronous programming techniques are relevant to any implementation. Web Sockets and their adoption in modern browsers provide the same capability of a web application to take advantage of multi-threading or asynchronous capabilities. From that perspective, Mark, I believe your comments are very relevant.
From an application responsiveness perspective the key thing is to be able to fire off a task in an asynchronous call, and to be able to handle the results when they become available, while allowing your application (or process) to continue handling other processes that are just as important.
SignalR is an interesting framework for DotNet allowing the configuration of those asynchronous calls from your web site, utilizing WebSockets for the best performance, and older HTTP techniques supporting older browsers.
Cheers,
Ben