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.
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.
Base Class Library
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.
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: