Atlas has been out for just about a month now and folks have been sharing thoughts. Various comments on my blog made me realize that we’ve been primarily talking about the "what" when discussing architecture, and features of the script framework, but haven’t addressed the "why". A programming model discussion might help address that. So, I chose to do that for a recent ASP.NET Insiders event. We had some good discussion that helped refine some of our thoughts. I’ll use this post to write on this topic. Hopefully this continues the comment discussion.
One key aspect of AJAX applications is their out-of-band communication with the server to eliminate or reduce post-backs. The interesting question, is what is transferred back and forth? Another interesting question is what logic runs where? These distinguish client-centric and server-centric development models.
The diagram depicts a client-centric development model from my slide deck. The server sends down the presentation, as well as UI logic during the initial request. This script-based UI logic runs on the client to handle user interaction, sends data to the server, and retrieves data (not HTML) in response, which it uses to further drive the presentation and content. The server exposes functionality, and other resources to the UI via services.
In a server-centric development model, the server often sends down HTML to the client instead of pure data in these out-of-band requests, and the client-side logic is considerably simpler. It is primarily responsible for making requests, and squirting in the response HTML into the right spot in the page. Most of the UI and interaction logic remains on the server.
The client-centric model allows implementing some compelling application scenarios, ranging from client-side computation to live data on the client. Imagine a master/details setup where editing a row of data in a list, causes the changes to show up in the details immediately without a network lag, because data is retained in-memory on the client and can be visualized in multiple forms simultaneously, and can be tracked for changes. This model also allows for more immediate handling of user actions and gestures, and the ability to perform snazzy visual effects (which can truly differentiate an app when used judiciously). The costs of this approach include writing significant client script, as well moving UI logic from server to the client, which entails learning, using, and building new tools, new patterns etc.
While some do love the new direction and its potential, some (very justifiably) respond with concern over the focus on scripting, and would prefer to stay in the realm of server-centric development where the guts of the application, including UI logic is implemented in something more familiar such as C# and with better tools. Incremental improvements in the application such as auto-completion, smarter grids etc. do not necessarily require a whole new model. While the UI is not as interactive as a true client application, it suffices for a class of applications. These scenarios are interesting to the overall Atlas vision, and a lot of feedback has been reinforcing that. You’ll see more and more of this part of the overall vision being fulfilled as the Atlas framework matures and allows developers to "Atlas-ize" and incrementally enrich their applications via server controls that balance client-richness with existing server-side paradigms.
So to try and address the "why" question around the script framework:
- It enables a more disciplined and manageable approach to scripting via OOP patterns, and component patterns. Atlas also provides abstractions over raw JavaScript and DHTML to create an application framework that has largely been missing from the browser platform. Essentially a goal of Atlas is to enable tapping into the capabilities of the platform for use in "real" apps, so the client-centric model can in fact start to become real.
- In another sense, Atlas is an enabling technology that simplifies the development of richer component development. Server controls already use script to varying degrees. Atlas provides a better substrate or runtime for control developers to target than just raw JavaScript and DHTML.
A lot of what you see today is a focus on client-centric development, as the groundwork is laid out. However, Atlas is about addressing both rich Web application development models: directly with a client application framework, and indirectly, by enabling server controls to target a better runtime.
<aside>
One thing to point out about the client-side approach is its remarkable similarity to how a smart client application or a mashup-type application might interact with the server. The idea is that your ASP.NET server-side infrastructure, services, and resources could be shared and leveraged across multiple applications and/or presentation platforms.
</aside>
One other dimension to the programming model, especially for those who are indeed fluent in scripting, is the choice of abstraction level when using Atlas. In order to address the varying needs, Atlas can be used in framework mode or runtime mode. Think of these as different packagings of the script framework presented in the layered architecture diagram.
We recognize that some developers will prefer to work directly with DHTML, as they have done so in past. These developers might be interested in building on top of the script core, and using it for things such as the OOP type system, APIs added to core JavaScript objects, the WebRequest/WebResponse abstraction over XMLHTTP and script proxies in order to call into Web services. This functionality is packaged into AtlasRuntime.js which comes in at about 10K today (assuming compression via IIS). The idea is to keep it as minimal as possible.
The Atlas "framework" could be thought of as the Atlas script framework in its entirety (sans auxiliary functionality such as drag/drop, mapping etc. that are to be included on an as-needed basis). In addition to the script core, this includes the component and UI framework, and a library of components, controls, behaviors etc. that abstract DHTML and the DOM to a certain degree. For example, you can use a Timer and subscribe to its tick event instead of window.setInterval. You can use bindings to transfer data across different parts of your application, instead of manually listening for change events, and implementing script event handlers, or use behaviors to package functionality and attach them to UI elements. Finally, you can choose to declaratively specify behavior instead of doing so imperatively using XML script. These are all different flavors of abstractions. The Atlas "Framework" is packaged in Atlas.js, which is about 30K today.
You might find both modes relevant in the same application. The runtime mode might be suitable for something like a home page for a site, which contains relatively little logic, and could in fact preload the framework, thereby making it available for immediate use on subsequent pages that are more involved.