The Server/Client Balance of Power Continues
I have had the unique pleasure of dealing with this conundrum countless times of the past eight years while architecting applications that operate in various web server and browser environments. The notion of a “rich client” experience has always been balanced with the capabilities of the client environment and the programming prowess of the developers. At one point it was java applets that allowed us to do client to networking calls back to the server without reloading the current webpage. Various other experimentation saw folks using hidden frames, xml data islands in IE and I’m sure a whole lot of other stuff.
Java applets have been replaced, largely, with Flash controls (and Silverlight, to a lesser but growing extent), but the real pants-kicker for the “rich client” holy grail of web apps has been the AJAX client/server frameworks which allow for a quick ramp-up for fledgling developers to use basic HTML and backend server markup languages to build an application that takes advantage of javascript for its client-server communication outside of page loads.
The Asp.Net AJAX framework, and its accompanying Toolkit of controls/extenders is a perfect example of this frameshift from a “pure” post and get ideology, to a hybrid postback-callback-async postback application. (By the way, when I talk to .Net web developers, I always try and get them to identify those three kinds of server requests – the results are often enlightening.) The difficult choice usually centres around the UpdatePanel, which, in my opinion, provides the most functionality for developers to quickly speed up the look-and-feel transformation of an application.
The problem doesn’t present itself right away. You might have an application with a GridView, maybe a dialog via a ModalPopupExtender, maybe another UpdatePanel for the DetailsView or FormView for editing the details of whatever is in the grid. Now you can use server-side code to hide the GridView and show the details panel when the user clicks on a row, and then vice versa when the save button is clicked - all without reloading the whole screen in the browser. In the past, this structure may have been on the same web form andway, in which case the ViewState overhead for loading the page and rebuilding control hierarchy on the server would seem to be the same, but beware, they are not. Not by a long shot.
The hidden field that contains your ViewState, and all (yes, ALL) the values of any other form elements on the web page, are now posted to the server with every invocation of any UpdatePanel on the page. That allows the server to behave as if a true postback had occurred. The first thing that surprises many folks here, is that the entire form contents (and not a subset of them based on the involved UpdatePanel) are posted back, and secondly, the control layer, javascript, has a massive performance dependency on the ViewState size. In other words, the more controls you add to this page, even if they are in not visible, will slow things down astronomically. Remember that javascript performance is affected not only by the network speed, but also by the complexity of the DOM that it is working with. The only thing worse that a slow web app, is a slow web app that is supposed to be using AJAX to speed things up!
How do you balance this offset as your application gets more complex? You still want the benefits of AJAX and the ability to use the UpdatePanel to quickly get moving and to take advantage of all the controls you know and love...
Come on back next week and we’ll take it to the next level.