The last post from Rick Strahl’s blog! Its a great piece of reading. Check it out also here(at the bottom I have a link to his original post):
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.
Ajax is all about JavaScript and HTML DOM scripting and I thought 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 that the days of hand coding most of the JavaScript to deal with client side logic are over. These days the complexity of what’s happening on the client and the UI is quickly getting as complex if not more so than what’s happening on the server. And while in the past we might have written a couple of lines of JavaScript here or there to validate forms, these days the requirements are much more involved. It’s almost a foregone conclusion that the client side now also requires some sort of framework which is often completely decoupled from the server side.
JavaScript Frameworks
At the moment client side frameworks are all the rage. There are basic JavaScript libraries that help with common tasks automating the DOM. The most popular along these lines is Prototype which provides basic JavaScript language enhancements as well as basic browser independent DOM manipulation functionality. Many other libraries build ontop 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. Similar are effects libraries like Scriptalicious, Moo.fx
ASP.NET Ajax
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.
MS 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 and 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 is much more verbose than other JavaScript frameworks.
The client side framework in version 1.0 can be thought of 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 there’s also 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 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.
Pure JavaScript Frameworks
Microsoft started from scratch when they built MS 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 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 among the JavaScript frameworks is Prototype which 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 small and concise and is easy to pick up by anyone reasonably familiar with JavaScript which accounts for its popularity. It’s definitely going to be less familiar to ASP.NET developers as it’s clearly a JavaScript centric framework. Prototype has pretty much become the yardstick by which other libraries are compared. Prototype is also the basis of many other higher level frameworks and many smaller add-on libraries exist that provide specialty functionality on top of Prototype.
There are other frameworks that follow a similar base approach. A couple of others that I’ve used on several occasions are jQuery which is very light weight and provides mostly AJAX/ JSON functionality, plus basic browser abstraction. MooTools is a full featured library that focuses heavily on effects (like drag and drop, animation etc) . I’ve found MooTools to be very enjoyable to work with and it feels like the cleanest and easiest to use implementation of the JavaScript frameworks I’ve played with. It also 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 feature so you get only the features you want include in your set (or sets).
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
When I started out with Ajax about 3 years ago, roughly about the same time Microsoft announced MS Ajax (Atlas at the time), I also got excited about Ajax functionality and thought that it wouldn’t be too difficult 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 is not as trivial as it sounds at first once you go down the path of building more sophisticated functionality. My library ended up adding things like drag and drop functionality, modal dialogs, pop up windows and various basic effects. At the time my JavaScript skills were pretty creaky and it took a bit of time and refactoring of 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.
Today 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 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 efforts that have gone into libraries like Prototype or MS Ajax’s 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. 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.
Script#
So far I’ve looked at client side JavaScript coding which is often regarded as a hassle. But there are a also a few alternatives available that let you code in a different language and output JavaScript from it. One such tool is the Google Web Toolkit which lets you write Java code to generate JavaScript code. Being a .NET developer using Java doesn’t sound so enticing, but luckily there’s a .NET project available that provides similar functionality by using C#.
Nikhil Kothari is one of the Program Managers on the ASP.NET team and he keeps cranking out some highly valuable and useful tools. One of the most exciting tools he’s created some time ago and recently updated is Script#. Script# at its core 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. The thing to understand is that you don’t get access to the full CLR and .NET libraries, but rather to a specific subset that is available to Script# and capable of being mapped into JavaScript code.
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.
There are a number of ways that you can create Script# generated JavaScript – one is inline inside of pages via a Scriptlet control that can contain C# code that gets converted on the fly and a more traditional library type approach that creates a separate .js files.
One of the cool things that Nikhil has done is provided a mapping assembly that provides a good chunk of the MS Ajax client library so you can generate code for MS Ajax compatible controls and behaviors. But even without the MS Ajax support, Script#’s core JavaScript support libraries provide many of MS Ajax’s type system like namespaces and class registeration etc.
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).
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 MS Ajax way although it can work without MS Ajax. If I were to build MS 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 (MS Ajax style), class and namespace registration, handling and providing Intellisense for the core MS Ajax infrastructure which provides great discoverability and a great reduction in the amount of plumbing code you have to type to create the tedious MS Ajax client code.
There’s a lot of potential for this sort of tool as a lot of people feel a lot more comfortable in the C# vs. 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 recently announced SilverLight 1.1 and one of the features of the 1.1 version 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 this has been beaten to death recently, 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.
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.
read original
Today, Google is hosting a developer day for 5,000 developers worldwide. The bulk of developers will be gathering at the San Jose convention center for a keynote by Google’s VP of Engineering, Jeff Huber. At the conference Google will be outlinging their developer strategy. But the big announcement will be 
The first demo of Gears will be for Google Reader, but more Google apps are expected to come. Reader will add a green download button to the user interface. When you click the button, Reader will download the last 2,000 messages to your computer, preparing your computer to work offline or under a spotty internet connection. 
Google Web Toolkit (GWT) is an open source Java software development framework that makes writing AJAX applications like Google Maps and Gmail easy for developers who don’t speak browser quirks as a second language. Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatibilities between web browsers and platforms, and JavaScript’s lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.