In the last year or so the Ajax lifestyle has become common practice for Web development even in the developer mainstream after a few years where the technology was primarily treated as bleeding edge technology. Today however, Ajax is drifting more and more into the mainstream of Web development and you’d be hard-pressed to find a Web development tool that doesn’t support it in some highly abstracted way.
The first stop for most ASP.NET developers likely is the MS Ajax toolset along with its various support libraries. MS Ajax provides both a server centric and client centric toolset. The server side functionality is primarily driven through the UpdatePanel control that allows wrapping server side controls and containers into an updateable panel container that allows for partial page updates. This component is the basis of MS Ajax’s server functionality and provides a core set of features that can be taken advantage of by other controls. The MS Ajax Control Toolkit can also be used in combination with the MS Ajax library to provide many other controls that provide server centric implementations with client side. The Control Toolkit takes uses a common pattern to create client side control implementation and also expose the control or behavior via a server side control which allows getting the base behavior exposed in a way familiar to ASP.NET developers with a minimum or no client side scripting.
To me MS Ajax is completely mixed bag. On the one hand I think Microsoft did a great job of providing a deep framework that is modeled closely to the .NET framework’s design which makes it somewhat familiar to .NET developers. But on the other hand the framework is bulky and it feels very rigid and formal in its implementation and usage.
But there’s no doubt that there is some allure in MS Ajax because it provides a single framework for client and server. The above mentioned rigidity of the framework can also be advantageous to control developers as it clearly forces common patterns for implementing components that work and expose functionality consistently. There are also many advanced features baked into the client framework like localization, testing and instrumentation at every level and not just at an afterthought.
Other libraries yet aim to extend the popular Prototype library. script.aculo.us for example, provides an effects library that runs on top of Prototype as does Moo.Fx, which is a tiny effects library that can work with Prototype or as part of MooTools.
All of the the libraries I’ve described so far (including the MS Ajax client library) are really core framework libraries. They provide language, object and DOM extensions, but they don’t provide much in the way of new user interface functionality. There are a number of libraries available that address this space with Widget frameworks. A couple of prominent entries in this space are Dojo, the Yahoo UI Library and even OpenLazlo (works either with Flash or DHTML) which provide a host of client controls. These frameworks are big and are often complex to use, but they provide really rich client side functionality that allows building interfaces that mimic desktop applications to some degree.
The good news with any of these tools is that they will work without any sort of server implementation so they’re easy to drop into any application – simply reference the JS libraries and off you go.
Unlike MS Ajax these libraries are purely client side – they know nothing about ASP.NET and the server side. But that’s part of the benefit of these frameworks as they are completely server agnostic. Communication between client and server is provided using XmlHttp and JSON serialization, deserialization, but if you plan on using it in combination with ASP.NET you probably will want to at least implement a custom JSON service interface that you can use to pass typed data between client and server. There are several open source .NET JSON libraries available (JSON.net, here and also my own wwHoverPanel) that make short work of this task. wwHoverPanel for example implements a self-contained HttpHandler implementation that lets you call JSON methods and return results from them.
Other ASP.NET based libraries like Anthem.NET, Ajax.NET and several others also provide server side JSON functionality. These libraries are also options for ASP.NET developers, but they tend to be server centric, and my focus here is on client side scripting so I won’t go into more detail here.
Build your Own
I still see a lot of value in building a custom library, however. If I had to do it over (and I may) I would almost certainly use one of the more prominent base frameworks as my base library and build on top of it. Using Prototype or MooTools would cut my framework code in half and let me focus on the specialty features I want in my framework.
The design I chose ended up creating matching client and server controls for most components built in such a way that the client control interfaces largely matched the server controls. The key features were to provide easy and flexible remote callback functionality to the server, a small windowing library that makes it easy to present pop up window content, along with a host of basic client side behaviors all in a small package. And finally combining all of this into an easy to use ASP.NET based interface.
Building your own is probably an edge case, but I’m often surprised how many people like me have gone down this path mostly because in the early days there weren’t as many choices available as there are today. The advantage with this approach is that you can build a truly customized framework that matches your toolset. It can also be beneficial to do this as a tool developer so you can provide additional functionality that is self contained. For example, even today with MS Ajax you can’t easily have client side code call back into a control without major hassles but with a custom interface it’s as easy as adding a method to a control and calling it from the client side. These are the kind of things you may never see in an official framework but are indispensible when you’re dealing control development for example.
The benefits of this approach are that you get full support for a rich editing environment in Visual Studio, strong type support and Intellisense for the supported features.
Script# is an interesting concept and Nikhil himself has used it for building a number of controls and helpers he’s published recently which is a validation of this concept for real work in a lot of ways.
Unfortunately this project currently has not been given any official support from Microsoft, so currently it’s impressively maintained by Nikhil himself. The toolset includes pretty good integration into Visual Studio .NET with project and item templates and integrated editor support for most things in the way you’d expect from C# source editing. But some of these integration features are a little rough around the edges which is to be expected for an early release (0.3.0).
SilverLight 1.1 and .NET on the Client
The way this works is that the .NET runtime hosted in Silverlight provides a programmable reference to the HTML DOM that Silverlight is hosted in. This may be IE or FireFox or Safari on the Mac or Windows. Silverlight provides interface to the the browser’s DOM and allows automation of it.
In concept this is a great idea, but before you get too excited remember that the current DOM support is very limited and deals primarily with accessing HtmlElement at the raw DOM level. There’s no browser abstraction or any support for specific HTML constructs. However, it’s quite possible to extend this basic functionality using .NET code to provide a much richer abstraction and browser independent access to the DOM. This would require somebody to build a browser abstraction layer first, but once done imagine the benefits that this would bring: You could build a browser abstraction layer that’s driven through the .NET coding model providing all the benefits of compilation and discovery and of course Intellisense.
We’re not there yet, but the possibilities of this technology have tremendous promise not just to address the flashy scenario we’ve seen so much of with Silverlight but also using Silverlight as a behind-the-scenes scripting engine for the HTML document.
Too many Choices?
As you’ve seen there are quite a few options available these days to build client side code. It’s no longer just about the remote AJAX functionality but also about building rich and snazzy client side interfaces.
There are many ways to skin this cat. The Ajax framework market is hugely fragmented and this is a problem especially since many of the Ajax frameworks and tools are so drastically different that moving between them is nearly impossible.
Even if you look only at the ASP.NET space, you’ll find that the MS Ajax release late last year has not found the universal adoption that’s typical for anything major coming out of Microsoft. While MS Ajax almost certainly has quickly become the most prominent ASP.NET Ajax framework by default, many early adopters of Ajax technologies are finding that MS Ajax is not a must-switch solution and continue on with their existing tools. That may change as time goes on and MS Ajax matures and adds more useful functionality that makes it more compelling as a client side tool.
Where does that leave us? I feel right now just about all of the Ajax tools out there are immature and often buggy. That doesn’t mean they don’t work, but they are not necessarily easy to use or maintain. The best that we can do as developers is to try and pick a toolset and stick to it if possible. But even that is often difficult if you work with multiple clients that have different preferences for the toolset used. Over the last year I’ve worked with at least 5 different Ajax frameworks on various projects and switching between these frameworks and building interfaces that run on top of them is not optimal to say the least. But it’s become a fact of life.
For my own internal work I’ve also landed myself in a dilemma. Do I stick with my custom built solution, or do I bite the bullet and make the switch to MS Ajax just because in the ASP.NET space at least it’s as close as it gets to a standard implementation? Even though I’m less than thrilled with that toolset? Or do I stick with what I got, possibly refactor and use a base library like Prototype? That’ll be most likely the path I take, but for now I’m sticking with the original framework I built. There are a lot of choices to make, benefits and tradeoffs to weigh.
Ajax and client side development is here to stay, but we are bound to see some consolidation and stabilization over the next few years. These are turbulent times.
Welcome to Web Development in 2007.