In the last year or so the Ajax lifestyle has become common practice for Web development. While Ajax was primarily treated as bleeding edge technology just a few years ago, today Ajax has moved 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.
Ajax is all about JavaScript and HTML DOM scripting. In this column I’ll review some of the approaches that are available to satisfy the requirements to build richer client applications and offer some thoughts on issues that I am struggling with as I compare the choices available for my own development and solutions that I work on with customers.
It’s pretty clear (at least to me) that the days of hand-coding most of the JavaScript to deal with client-side logic are over. The client UI is quickly getting as complex, if not more so, than what’s on the server. While in the past developers might have written a couple of lines of JavaScript here or there to validate forms, today’s UI requirements are much more involved. It’s almost a foregone conclusion that the client-side now also requires some sort of framework that is often completely decoupled from the server side.
JavaScript Frameworks
At the moment, client-side frameworks are all the rage. You can find basic JavaScript libraries that help with common tasks automating the DOM. Prototype, the most popular along these lines, provides basic JavaScript language enhancements as well as basic browser-independent DOM manipulation functionality. Many other libraries build on top of Prototype to build additional libraries, the most common of which these days are user interface widget libraries. Dojo and Yahoo’s Widgets are examples of Widget frameworks, which extend UI functionality. You may also find effects libraries like script.aculo.us and Moo.fx useful for your applications. I’ll discuss these as well.
ASP.NET AJAX
The first stop in finding a JavaScript framework for most ASP.NET developers likely is the toolset along with its various support libraries. ASP.NET 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 ASP.NET AJAX’s server functionality and provides a core set of features that can be taken advantage of by other controls. You can use the ASP.NET AJAX Control Toolkit in combination with the ASP.NET AJAX library to provide many other controls that provide server-centric implementations for client side. The Control Toolkit uses a common pattern to create a 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 minimum or no client-side scripting.
ASP.NET AJAX also includes a large client-side JavaScript framework that provides core language features and basic HTML DOM accessibility through a common JavaScript API. The key feature of the client-side framework is that it provides a .NET-like type system and a common implementation pattern for classes and components. So you will typically use a set of guidelines based on namespace, interfaces, and classes to implement your classes. You’ll use property get/set syntax for property declaration and invocation when creating your own classes. The framework more or less forces you into a specific way of doing things which is both a good thing and a bad thing depending on whether you agree with the design decisions Microsoft made. But the rigid structure of the framework also means that using it requires a certain discipline and in some ways it is much more verbose than other JavaScript frameworks.
You should think of the client-side framework in ASP.NET AJAX version 1.0 as core framework services rather than as a complete Ajax framework. This includes the type and language facilities, extensions to some of the base JavaScript objects, and the base Html DOM element. Of course, ASP.NET AJAX includes support for remote communication via XmlHttp both on a low and high level as well as JSON serialization facilities and the ability to use ASMX and WCF Web services.
To me ASP.NET AJAX is a 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. On the other hand, the framework is bulky and it feels very rigid and formal in its implementation and usage.
There’s no doubt that there is some allure in ASP.NET 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. ASP.NET AJAX also includes many advanced features baked into the client framework like localization, testing, and instrumentation at every level and not just as an afterthought.
Pure JavaScript Frameworks
Microsoft started from scratch when they built ASP.NET AJAX but there are a number of very popular JavaScript libraries available, most of which are easier to use and more light weight to boot.
If you are a developer who’s familiar with JavaScript and you’re not afraid to code on the client side, a raw JavaScript library might offer you much more flexibility and options to create cool interfaces because there are a large number of libraries available. The most difficult portion of a JavaScript/Ajax framework is the browser interoperability and functionality extension of the base JavaScript objects and basic DOM objects and all of the libraries I mention here address this scenario. These libraries do away with the inconsistency of dealing with various browsers, which is easily the biggest time waster when dealing with client-side scripting. Take that away and you might find that JavaScript coding is not a big deal after all.
The most popular JavaScript framework, Prototype, is a highly usable and relatively small library that provides JavaScript type extensions and a large number of DOM abstraction and enhancement functions. Prototype is concise and is easy to pick up by anyone reasonably familiar with JavaScript, which accounts for its popularity. ASP.NET developers won’t be as familiar with Prototype as it’s clearly a JavaScript-centric framework. Prototype has pretty much become the yardstick by which other libraries are compared. Many other higher-level frameworks and many smaller add-on libraries that exist to provide specialty functionality are built on top of Prototype.
Other frameworks follow a similar approach. In particular I’ve used jQuery, which is very light weight and provides mostly AJAX/ JSON functionality, plus basic browser abstraction. I’ve also used MooTools, which is a full-featured library that focuses heavily on effects (like drag and drop, animation etc.). I enjoy working with MooTools and it feels like the cleanest and easiest to use implementation of the JavaScript frameworks I’ve played with. It uses a very Prototype-like base implementation although it doesn’t rely on Prototype itself so it will be immediately familiar to users of Prototype. MooTools also has a cool feature on their site that lets you customize the MooTools JavaScript library by letting you select the functionality you actually want to use and then combine the subsets into a single JavaScript file for you along with various options for compression.
Other libraries 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 libraries I’ve described so far (including the ASP.NET 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. Widget frameworks are libraries that address this space. 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. Widget 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 JavaScript libraries and off you go.
Unlike ASP.NET 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 and deserialization, so if you plan on using these libraries in combination with ASP.NET you’ll likely have to 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, on The CoDe Project, and also my own wwHoverPanel) that make short work of this task. My wwHoverPanel, for example, implements a self-contained HttpHandler implementation that lets you call JSON methods and return results from them. JSON is not required, however-you can pass any data over the wire, of course, and other popular options include generating HTML on the server or sending back XML.
Other ASP.NET-based libraries like Anthem.NET, Ajax.NET, Gaia ASP.NET Widgets and several others also provide server-side JSON functionality. While these libraries are also options for ASP.NET developers, they tend to be server centric, and since my focus here is on client-side scripting, I won’t go into more detail.
Build Your Own
When I started out with Ajax about three years ago, roughly about the same time Microsoft announced ASP.NET AJAX (Atlas at the time), I also got excited about Ajax functionality and thought that it wouldn’t be too difficult to create my own library with some basic functionality. Before long the library grew into a small client framework with a very focused feature set that did exactly what I needed in my applications and life was good. However, I also quickly found out that building your own Ajax library is not as trivial as it sounds once you go down the path of building more sophisticated functionality. In my library I added things like drag and drop, modal dialogs, pop-up windows, and various basic effects. When I started the library my JavaScript skills were pretty creaky and it took a bit of time and effort to refactor the JavaScript code to get up to speed and actually understand more about JavaScript’s language peculiarities and browser DOM quirks. This is an ongoing effort that continues to this day.
As I’m looking back I’m really glad I went through this experience as it taught me tons about JavaScript that I probably would have never figured out otherwise and now I feel at least reasonably proficient with JavaScript not to cringe at the thought of having to write client script. But I also realized that writing sophisticated client-side JavaScript DOM code is damn hard, especially if it has to work across many browsers, and I really started to appreciate the effort that has gone into libraries like Prototype or the Microsoft ASP.NET AJAX client library.
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. If I use Prototype or MooTools I can cut my framework code in half and just 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 Ajax library 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. One 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 ASP.NET AJAX you can’t easily have client-side code call back into a control without major hassles, but with a custom implementation this can be 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 with control development.
Script#
So far I’ve looked at client-side JavaScript coding, which is often regarded as a hassle. But there are also a few alternatives available that let you code in a different language and output JavaScript from it. One such tool, the Google Web Toolkit, lets you write Java code to generate JavaScript code. Being a .NET developer, using Java doesn’t sound enticing to me, but luckily there’s a .NET project available that provides similar functionality by using C#.
Nikhil Kothari, one of the Program Managers on the ASP.NET team, keeps cranking out some highly valuable and useful tools. One of the most exciting tools he created some time ago and recently updated is Script#. At its core, Script# is a C# compiler that rather than spitting out MSIL compiled assembly spits out JavaScript source files. There are two pieces to this magic-the actual compiler/parser that does the translation and a set of libraries that provide the supported set of features that you can use with the C# code you write. Script# doesn’t give you access to the full CLR and .NET libraries, but rather you can access a specific subset that is available to Script# and capable of being mapped into JavaScript code.
This approach gives you full support for a rich editing environment in Visual Studio, strong type support, and IntelliSense for the supported features.
You can create Script#-generated JavaScript in a number of ways. You can use C# code inline inside of pages via a Scriptlet control that can contain C# code that gets converted on the fly. Or you can use a more traditional library type approach that creates separate .js files by compiling a class library generating .js files (both for debug and packed for release) for each of the source files.
Nikhil also created a mapping assembly that provides a good chunk of the Microsoft Ajax client library so you can generate code for MS Ajax-compatible controls and behaviors. But even without the ASP.NET AJAX support, Script#’s core JavaScript support libraries provide many of ASP.NET AJAX’s type system like namespaces and class registration, etc.
Script# is an interesting concept and Nikhil 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, Microsoft has not given this project any official support, so currently it’s impressively maintained by Nikhil himself in his spare time. 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. Some of these integration features are a little rough around the edges, but you can expect that for an early release (0.3.0).
I’ve played around with Script# off and on and it provides some really interesting possibilities, but somehow I can’t shake the feeling that this is somehow limiting my options for coding general purpose JavaScript. Script# also subscribes to the ASP.NET AJAX way although it can work without ASP.NET AJAX. If I were to build ASP.NET AJAX controls I think I would start seriously looking into this tool to provide some of the core plumbing. Script# will manage things like automatic property creation (ASP.NET AJAX style), class and namespace registration, handling and providing IntelliSense for the core ASP.NET AJAX infrastructure (which provides great discoverability), and a great reduction in the amount of plumbing code you have to type to create the tedious ASP.NET AJAX client code.
There’s a lot of potential for this sort of tool as a lot of people feel a lot more comfortable using C# versus JavaScript. But without official support from Microsoft, it’s unlikely that this tool will gain wide acceptance although there are certainly some people who will find it useful for their work.
SilverLight 1.1 and .NET on the Client
Microsoft announced SilverLight 1.1 and one of the features of version 1.1 when it releases later this year or early next year will be the capability to run .NET code on the client. I don’t want to dwell on the rich user interface features of Silverlight here since there are many resources on this topic, but rather focus on the .NET programmability and the ability of the .NET code to reach out and manipulate the HTML DOM from within the Silverlight .NET runtime. This gives yet another option for managing client-side code using a .NET language rather than JavaScript. This means that you can use Silverlight in combination with .NET to write fully standard-compliant HTML.
How does this work? 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 on Windows or FireFox and Safari on the Mac. Silverlight provides an interface to 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 this could be done with third-party .NET code and once done, imagine the benefits that this would bring: Coding against the DOM with .NET code along with all the benefits of static compilation, discovery, and of course IntelliSense.
The possibilities of this technology has tremendous promise not just to address the flashy scenario we’ve seen so much of with Silverlight, but because Silverlight offers the first tool that makes .NET available in the browser. This means reuse of skills and using the tools we’re already familiar with.
Too Many Choices?
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 that is important.
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 ASP.NET AJAX release late last year has not found the universal adoption that’s typical for anything major coming out of Microsoft. While ASP.NET AJAX almost certainly has quickly become the most prominent ASP.NET Ajax framework by default, many early adopters of Ajax technologies are finding that ASP.NET AJAX is not a must-switch solution and continue on with their existing tools. That may change as time goes on and ASP.NET AJAX matures and adds more useful functionality that makes it more compelling as a client-side tool.
Where does that leave us? I feel that 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 five 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 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 ASP.NET 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 have, possibly refactor, and use a base library like Prototype? I’ll most likely take this path, but for now I’m sticking with the original framework I built. I have many choices to make, and benefits and tradeoffs to weigh.
Ajax and client-side development is here to stay, but developers are bound to see some consolidation and stabilization over the next few years. These are turbulent times.
Welcome to Web development in 2007.
