微软致力于简化Ajax风格Web应用的开发，并提供丰富的、可交互的和个性化的用户体验。开发者可以对客户端脚本不甚了解;但他们可以很容易地开发和调试这种应用程序。
出于这一目的，微软启动了一个新的项目，研发代号“Atlas”。Atlas为开发这带来了如下特性：1.Atlas客户端脚本框架 2.Atlas的ASP.NET服务器控件 3.ASP.NET Web Services集成 4.Atlas的ASP.NET构建块 5.客户端构建块服务
Atlas是编写丰富的、可交互的和个性化的Web浏览器应用程序的最好方式。而Avalon是微软的下一代表现层模型，可以在Windows平台上提供最丰富的用户体验。Avalon将使用最新的媒体集成功能和硬件加速设备，提供卓越的视觉体验。Avalon将带来超越浏览器的体验。
当然，当你构建Avalon应用程序的时候，你依然可以重用ASP.NET和Atlas中的编程模型。例如，Avalon客户端上依然可以使用ASP.NET构建块服务和客户端构建块服务。这种模型可以使你平滑地过渡到下一代应用程序上。
Atlas 优点:
仁者见仁，智者见智。在这种问题上每个优秀的技术人员应该总是有自己独特的见解。能得到一个能“服众”的结论固然好，但是支持百家争鸣更为重要。我始终认为Atlas的最大长处不在于其Ajax特性，不在于其提供了复杂JS才能实现的多样化功能。在我看来，Atlas是很了不起的，而它的了不起体现在三个地方：
1. Declarative Syntax: 应该有不少人有过在HTML Element中嵌入浏览器无法识别的属性，而在某个地方通过自己编写的Javascript方法读出并加以一些功能。其实我在数年前总觉得这样的方法是tricky solution。我不喜欢tricky的方法，特别是无条理性的tricky solution。这样的方法的确可以work，但是可读性一般比较差。在大多数时刻，我始终把代码的可维护性放在第一位。后来由于在项目中需要开发一个Rich Client，给用户以大量的操作自由度（描述不当，不过估计无法用三句两句话说清了），于是不得不使用了这个方法。在进行了大量尝试后，发现如果合理使用，这的确是一个非常灵活有效，并且易于维护的方法。ASP.NET强大的客户端Element模型又可以说对这种方法合作的几乎天衣无缝。 Atlas的Declarative Scripts可以说将上面提到的这个方法进行了极大的升华。将一个从一开始似乎十分Tricky的方法变成了另一种开发方式，将程序设计和XML结合在了一起。事实上，这给了许多项目设计一个参考。将客户端代码的结构化也大大地提高了可维护性。 原来，代码还可以这么写。 2. Extendable Behavior, Extender, etc. 它们所作的贡献是提供了良好的设计。能让程序员轻松地写出符合良好设计的代码。 一个良好设计的代码，其中一个非常基础的特点就是“high cohesion”，也就是“高内聚”。高内聚的组件与外界的依赖很少，这样大大方便了开发，调试，测试，发布和部署。 就拿开发一个Extender来说，需要的就是写一个Class Library，并编译成一个程序集。使用时只需简单的引入，并像使用普通控件一般即可。在开发时需要的也仅仅是Atlas的基础结构，少得不能再少的一个程序集。 还是一个典范，还是一个示例。 3. Powerful Foundational Framework 这里不提Atlas提供了一个完全面向对象的编成框架，提供了一个Compat层来兼容多个浏览器等。现在来思考一个问题：如何写出高性能的Web应用程序？ 或者换个角度想一下，一个网站的性能是从什么方面体现出来的？这不光是要服务器端的努力，特别是现在客户端越来越Rich，客户端的Load也越来越多。优化PLT（Page Load Time）也是一个越来越重要的议题。这需要对于浏览器，HTML以及HTTP标准有相当完整的认识。通过分析Page Load来优化一个页面能够达到非常了得的效果，经过PLT优化的网页往往能将一张页面的打开时间缩短3-5秒甚至更多，并且往往也能减少服务器端的运算以及流量。 Atlas的基础代码框架的每一步都是尽量地符合优化PLT的Best Practice。所以使用Declarative Script和Atlas框架所提供的JS类往往效率会比较高。打个比方，浏览器对于相同域名只会并行地使用两个端口进行加载，因此将不同资源从不同域名加载是优化PLT的一个常用方式。但是由于可能JS中任何部分的代码都可能会改变的页面的DOM或者Render出不同的内容（例如使用document.write），因此浏览器在下载JS文件时是会Block住其他任何的资源加载，无论其是否在同一个域名中。加上现在JS文件越写越大，数量越来越多，因此浏览器的加载能力就被削弱了。在Atlas中，Binding机制能比较好地处理JS加载问题，以优化页面的PLT以及Perceived Performance。 Atlas的缺点？ 其实我有时候总是会想，Atlas代码是不是写的太庞大了，使用起来方便吗？比如其OO特性，使用起来似乎不是很方便，代码量和代码体积颇高，而且对于没有接触过Atlas的人不是很容易看懂。外界不少提供面向对象机制的JS框架似乎就精炼许多。我也因为某些需要为JS写了一套面向对象机制的扩展，很简单，使用方便，OO机制使用方式也是尽可能地向Java代码靠拢。继承，虚函数等必须的功能也一个不缺。 不得不说，这个似乎是Atlas的一个瑕疵。但是瑕不掩瑜，Atlas依旧是一套优秀的JS框架。它实现的Ajax，却又远远超越了Ajax本身。冲着Ajax or .NET来接触Atlas的程序员往往总是能从它身上得到惊喜。