My take on the “Atlas” Client Script Library

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

Comments (8)

  1. Steve says:

    "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."

    Exactly, I hope to see the next CTP enhance this area – this (Atlas) is the most exciting thing to me since .NET came out

  2. Mike says:

    Why does "Atlas" remind me so much of "Remote Scripting" circa ASP 2.0 (mid 1990’s)?

    So far it looks the same – just a better implementation.

  3. Steve says:

    What does "tooling" mean?

  4. Exactimo says:

    hello mr jollyman, show me the tomato

  5. FederalDev says:


    You are not alone!  In fact, when I talk to customers about AJAX programming in general I always explain to them that this style of web programmng is nothing new.  I usually go through a history of browser based technologies that have enable this style of progamming in the past.  Remote Scripting is one of them.


  6. FederalDev says:


    When I say "tooling" I mean the IDE capabilities of Visual Studio, the “tool”, to make using the “Atlas” framework easier client side much like it does now for ASP.NET server controls.  For example, when you drag a GridView control from the “toolbox” of Visual Studio 2005 onto an ASP.NET page, Visual Studio  generates a  bunch of markup for you which you would otherwise have to write by yourself.  It does this through control defaults, wizards, smart tags, configuration dialogs, etc.  Think of it as the difference between writing it ASP.NET server side code/markup in notepad and writing it in Visual Studio.  Right now, when you use the “Atlas” client centric approach it is more like coding in notepad.  VS gives you a few things like syntax highlighting and debugging, but some of the things we take for granted like Intellisense for both code and markup, drag and drop of controls from the toolbox, etc. aren’t there yet.


Skip to main content