Build Your AJAX Applications The Smart Client Way

I've been thinking about AJAX a lot lately.  Those of you who have read my past blogs (and thanks to both of you) know that I'm a fan of Smart Client applications and have been fairly critical of the mass enthusiasm for all things AJAX.  But like any good architect I have to keep my options open and so I've been thinking about AJAX a lot lately.  And what I've noticed is that AJAX in fact has remarkable similarities to Smart Client development. 

Before I start explaining the architectural reasons why I think AJAX and Smart Client development is so similar let me explain why I consider this to be a "good thing".  The primary tenets of a Smart Client application are:

1. It uses local resources and provides a rich user experience
2. It exchanges data across a network, Intranet or Internet
3. It can function without a connection
4. It is easy to deploy

Obviously, number 3 is out for AJAX applications but the rest can be accomplished via AJAX if the application is architected correctly.  They key advantage to smart client applications, in my opinion, is the use of local resources.  One of the most underutilized local resources in a browser world is the CPU on the client machine.  While browsing even complex sites like MSDN my CPU rarely goes beyond 15% capacity.  Making that resource available to your applications for performing repetitive GUI tasks while lowering the need for more and bigger server hardware is where I think AJAX has the ability to make the most impact on application development. 

Another key feature of Smart Clients not addressed in the tenets listed above is that the data sent between disparate servers and clients doesn't include UI markup which can significantly improve an applications performance.  What's more AJAX can broaden the reach of your application beyond that of a Smart Client application to non-Windows environments.  This is all serious goodness, if not quite the greatness of a completely disconnected application.

Consider web development with AJAX from a 10,000 foot view.  You have the standard server scenario, one or more application servers reading data from a SQL database somewhere.  In the old Web 1.0 world, a browser would request a page and the application server would combine the data with the UI and spit out a representation of the UI via HTML to the browser which would then render the results; a typical client/server relationship.  However AJAX allows for a more distributed model where the application server can focus on performing business logic and handling requests while the JavaScript running on the client renders data to the user by manipulating the browser DOM.  This in effect moves the UI processing to the client where, in my opinion, such processing belongs.  Note that I'm not saying that this is how many AJAX enabled browser applications are being built, but the capability is there.

In this diagram I show just how similar the architectural model for an AJAX enabled browser application is to that of a standard Smart Client application.  Notice only the labels on the boxes change.

Figure 1.

If you consider each portion of the application not by technology but by its responsibilities the similarity becomes clear. 

Application Server
AJAX:  In an AJAX enabled application much of the actual business functionality is accessed via web service calls (or static method calls which I consider a step in the wrong direction architecturally).  Data is sent and received in XML or JSON format over HTTP.  The HTML, CSS, images, etc. are all downloaded on demand by the browser and then stored on the client machine in the temporary internet files folder.  Little of the UI processing is done at this point beyond the combination of ASPX with ASCX controls.  This frees the server up to handle the more "chatty" but also more flexible interface with the client.
Smart Client:  In a smart client application, the application server provides the same access to business functionality via services (ASMX or WCF).  Data is sent and received as XML via SOAP.  EXEs, DLLs, and other content are downloaded as needed and stored in the user's profile directories.  All of the UI processing is performed on the client, once again freeing up the application server to handle service requests.

Execution Environment
AJAX:  In an AJAX enabled browser application the browser itself is the execution environment.  It has the responsibility to manage security and protect the client machine from malicious code.  (Stop laughing, I'm serious! J)  It provides a programming model to allow the logic of application written in JavaScript to execute as well as a UI object model (HTML DOM) to allow code to render data to the user.  It also provides the mechanisms for sending and receiving data to and from the application server via XmlHttp.
Smart Client:  In a typical smart client application the execution environment is the .NET CLR with significant security sandboxing.  The CLR provides the security infrastructure to protect the client machine from malicious code as well as providing the framework for logic written in .NET code to run.  It also provides UI features via the System.Windows.Forms namespace to allow the logic to interact with the user.  And lastly, it provides the mechanisms to communicate with the application server via XML and SOAP. 

Data
AJAX:  In an AJAX application the data being sent across the wire is always XML.  It may have various protocols applied and the raw data may be XML or JSON objects.  HTTP is also the only protocol used.  Because the data is no longer embedded in repetitive UI markup it is much smaller and so there is a serious opportunity for increased performance of the application as a whole.  Data can be cached locally through the use of application server generated JavaScript files.
Smart Client:  A smart client application has a bit more freedom about how to get objects across the wire.  It can use HTTP or several other protocols, it can send and receive data in a number of formats including binary.  But in most cases, for the sake of interoperability and accessibility through firewalls, it's a good idea to stick to web standard protocols of XML and HTTP just like AJAX.  And also like AJAX, only the data and protocol plumbing need be sent back and forth increasing performance of the application overall.  Data can be cached locally in an isolated area.

UI Logic
AJAX:  The UI logic of an AJAX application is programmed via JavaScript.  The logic can render data from the application server to the browser via the HTML DOM and validate input from the user.  It can handle events on the UI and make subsequent requests for more functionality/data from the application server.  It is fundamentally responsible for the user experience of the application.
Smart Client:  In a smart client application, the UI logic is programmed with any .NET language.  The UI logic can render data to the client via calls into the WinForms namespaces.  It can validate input from the user before making subsequent calls to the application server.  It also is fundamentally responsible for the user experience of the application.

GUI
AJAX:  The user interface for an AJAX application is rendered as a combination of HTML DOM objects and CSS styles.  The individual browser specifies the limits of what can be accomplished graphically in the user interface but a common standard set of features has been hammered out amongst vendors. 
Smart Client:  The user interface for a smart client application is rendered via Win32 calls on the Windows operating system.  It is limited by the features and functionality supported by the WinForms namespaces as well as those features allowed by the security context. 

Up to this point I've been speaking of the capabilities of AJAX but not necessarily the implementation, or at least not what I believe is the common implementation provided by AJAX.NET.  In most applications that tout themselves as being "AJAX Enabled", a significant portion of the UI logic is still taking place on the server.  So why, you ask is that bad?  Of course it's not "bad", it's just not the best use of a centralized (aka limited) resource that is your application server and is old fashioned Web 1.0 thinking.  No server, regardless of how powerful, can come close to the rendering power of 100 client CPUs much less the thousands deployed throughout organizations all over the world.  Since the CPUs are there and the capability to use them exists, doesn't it make sense to push the UI logic to those devices?

So how then do we architect an AJAX application that keeps the UI logic on the client machine?  Here are a few simple rules that should help.

1. HTML pages contain only static layout and file references. The caching features available for HTML pages make static pages very fast to access. Since all UI logic is being done on the client these pages could even be .HTML files instead of parsed .ASPX pages.
2. Use CSS for all UI specific features. The advantages to using CSS for layout and UI features is nothing new, websites are being built every day using CSS styles instead of the more traditional tag properties.
3. Build your UI logic from a "client-only" point of view. This means that the client JavaScript makes the calls to the server for business functionality and then builds the UI using new and existing DOM objects. It then handles events from the user and sends more requests. Lather, Rinse, Repeat.
   What is needed to enable this type of development is a combination of tooling and client side frameworks.  While the Microsoft AJAX library has a lot of the basic features for calling web services already built in, I think there is more work to do there as well as in Visual Studio to make client side JavaScript development easier.  The good news is that improvements in Visual Studio "Orcas" as well as the new Expression Web Designer are going to make working with client side JavaScript and CSS much easier... eventually.
4. Resist the urge to use server side controls like the UpdatePanel that while making your development more productive, continue the Web 1.0 paradigm of building web applications by combining the UI markup with the data on the application server machines and rendering the client PCs as little more than dumb terminals.