So I sat down to write a blog entry about the “Atlas” Client Script Library and the client-centric programming approach it enables as a lead in to a bunch of screencasts I am recording. I, of course, spent some time reviewing all the blog posts, documentation, etc. I read to get familiar with the “Atlas” client-centric approach. I quickly realized that between what’s said in Nikhil Kothari’s explanation his “Atlas” architecture post here, the “Atlas Client Script Framework” section of Scott Guthrie’s “Atlas Project” post here, and the “Atlas” documentation here, that I couldn’t just regurgitate what they said. So I highly recommend you take a look at what they have to say. As an alternative, I’ll just give you my thoughts on the pieces of the Client Script Library after having used it for a bit.

Once you look at the Client Script Library, you’ll quickly see that it was influenced by the .NET Framework. In essence, it’s an attempt to make up for what JavaScript is lacking and make JavaScript programming feel much more like .NET programming. The library is broken up into the following layers:

Browser Compatibility Layer

First and foremost, I think this is the most crucial piece of the stack. Why? Because it’s being written to work against IE, Mozilla/Firefox, and Safari. All other parts of the library ultimately talk to this layer. That means that if you program using “Atlas,” it just works regardless of which of the above browsers you use. This also insulates you from changes to browsers. If bugs are found, browsers change, or new browsers become mainstream, then there is one layer to fix.

Script Core

There’s all sorts of geeky stuff in here. The bottom line is the Script Core lays the foundation for having parity between your client side and server side programming model. This layer introduces concepts like namespaces, inheritance, and delegates (to name a few) to JavaScript. This is the beginnings of the “Feels like .NET” theme.

Base Class Library

As Nikhil says, “This was inspired by the .NET Framework.” Just like the .NET Framework, there are a bunch of classes here that make performing common tasks simple (building strings, debugging, etc). There are quite a few namespaces. There’s a really nice “Atlas” Client Library Browser that allows you to navigate all the namespaces and types here. Since the Visual Studio doesn’t yet provide Intellisense for JavaScript, this will come in handy to discover what properties, events, and methods are available for a given control. An example namespace is Sys.Net. It eliminates the need for awkward XMLHTTP programming. The JavaScript web service proxies “Atlas” creates for you use this namespace to make remote calls clean and elegant.

I think the key here is the enablement of a client side JavaScript programming model that is much more consistent with .NET programming. The experience is akin to going from Windows Forms programming using C# to Compact Framework Windows Forms programming using VB.NET. The capabilities are reduced and the language syntax is a bit different, but you’ll see that it feels pretty darn close.

Component Model and UI Framework

This is another layer with all sorts of geeky stuff in it. This where the foundation for concepts like controls, behaviors, validators, and databinding is laid. What’s important to understand about the UI Framework is that it enables you to completely (if you choose) perform all of your UI logic inside the browser. The communication between the client and the server is pure data baby. Unlike the traditional postback, process logic on the server, generate UI and send it back to the browser approach, you just send and receive data to and from the server. All the processing of your UI logic, UI generation, datadinding, etc. happens on your desktop.

When I first started exploring programming against the Client Script Library I thought to myself “This feels like Windows Forms/WPF/VB6 programming.” I think VB6/Windows Forms/WPF programmers will be more comfortable with this programming model than Web Forms because you don’t have to worry about things like server page lifecycle, state management, etc. nearly as much.

My favorite feature this layer enables is XML-script. This is a declarative way of defining JavaScript objects very similar to how XAML is used for the Windows Presentation Foundation. Markup has proven to be a great way to define UI and UI behaviors. One benefit of markup is that it is much easier for tooling to generate than traditional code. Right now, the tooling support for the Client Script Library is limited, but I am excited to see what kind of features are in store for Visual Studio Orcas to make using the Client Script Library even easier.

Controls and Components

In ASP.NET Web Forms, Server Controls abstract HTML into a nice object oriented UI programming model where controls are objects with properties, events, and methods on the server. The Client Script Library does the same thing within the browser. You no longer have to program the HTML DOM. For example, you now have a nice clean TextBox control you can define/access both programmatically or declaratively. Furthermore, this makes the programming experience much more similar server side and client side. There is a significant increase in parity between the controls you interact with on the server and on the client. In this case, whether you are server side or client side, you just access the Text property of the TextBox.

Here’s a slide that summarizes the Client Script Library:

So that’s my take on the Client Script Library. As I suggested earlier, I think the biggest barrier to traditional ASP.NET server centric programmers (folks not doing much JavaScript now) writing client centric apps is the tooling. It’s not quite there yet. Stay tuned! Having said that, just using the Client Script Library makes JavaScript web UI programming orders of magnitude easier. Whether one stars now or waits for a better tooling experience, I think the Client Script Library will make many developers who won’t touch JavaScript with a ten foot pole say “This JavaScript programming thing ain’t so bad!”


Technorati Tags: Microsoft, .NET, ASP.NET, Atlas, AJAX, Web 2.0