仁者见仁，智者见智。在这种问题上每个优秀的技术人员应该总是有自己独特的见解。能得到一个能“服众”的结论固然好，但是支持百家争鸣更为重要。我始终认为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的程序员往往总是能从它身上得到惊喜。
学习Atlas……
我经常在我身边的开发人员中推荐.NET，虽然无偿，但是冲得就是对这一技术的喜爱。我是技术人员。当然对于Atlas也向别人进行过介绍，也看到不少人学习Atlas的情况。
似乎Atlas进入了.NET相同的情况，大家纷纷在使用，感觉很爽，而去了解它是如何做的人却很少。知道在什么情况下如何使用的人也很少。而且能够灵活使用的人，往往也对其机理有了相当认识。可能的确只有从一个特定的层次以及角度去看它，才能对它有更好的掌握能力。“使用论”和“深入论”的争锋似乎依旧存在。忽然想起Jeffrey Richter说过他的CLR via C#市场反响不好，现在越来越少的人希望从CLR层面去了解.NET Framework……
其实我也是“使用论”的支持者，但是我仅仅支持良好的使用方式。这都不是一朝一夕能够炼成，也不是仅仅靠了解一门技术就能做到的。要成为一个优秀的技术人员，所需的技术覆盖之广，其实远超过普通技术人员的想象。
经典评论：
1.
Atlas先天不足，在我的文章：http://dflying.cnblogs.com/archive/2006/05/01/390401.HTML 中headchen朋友有这样一条评论，绝对入木三分，这才是真正高手的看法：
（以下引用headchen朋友的评论）
1. JavaScript试基于原型prototype的继承机制，通过构造函数和原型对象来模拟类。这一点在Atlas中当然不会发生改变。只不过他在暗地里全都处理了，处理得方法是：派生类拷贝了基类原型对象得所有方法到自己得原型对象中。这样当一个派生类继承于一个基类时，自动继承类通过原型对象实现得实例方法（当然派生类的原型对象中若存在同名方法，则不拷贝）。
2. Atlas通过registerBaseMethod来声明得虚方法仅仅时构造函数得内部方法（有一些文档中称为privilege方法，意思时能够访问构造函数得局部变量，Atlas正是通过这个来模拟私有变量的）。而Atlas中大量的get_ set_正是此类方法。
3.在JavaScript中实现一个类的实例方法有两种途径：1 把方法定义在原型对象中，这个在使用时自动通过访问原型链来访问实例的方法。这种方式的好处是节省内存，效率比较高（这里说的效率是实例化对象时的效率），因为多个实例的方法都存在一个原型对象中。2 定义为原型对象的内部方法（上面已经说过来），这种方式，在初试化实例对象时，实际上是给每个对象实例都定义了一个相应的方法。所以初试化实例对象时需要更多的内存和时间。但这种实现方式有他存在的必要性，那就是利用函数的closure特性来实现特有的需求，比如：生成事件委托，回调函数，实现局部变量等等。但如果对象实例很多时，存在很大的效率问题，所以把他称为privilege方法也时有道理的，那就是他的存在的理由就是为来利用closure。
微软在Atlas种大量使用privilege方式来实现实例方法，而有意无意的淡化来JavaScript固有的prototype的实现方法，从语法上来看更接近C#的语法，另外Atlas种存在大量的get_ set_ 类方法也只能通过这种方式来实现，我们也看到绝大多数类实例的方法，即使不是必须，也大多采用类这种实现方式，而不是prototype的方式。对于这种动向，本人时持有反对意见的。很明显的看出：Atlas有.net情结。想在JavaScript环境实现一个稳固严密的架构，但确牺牲了 JavaScript原有的灵活性，并且牺牲了大量的内存和效率。
所以我们可以利用Atlas提供的一些扩展，比如对于String Array Function等的扩展，特别时命名控件，事件委托等等。但不必完全拘役于它或者完全模仿他。
Atlas对Function,Array,String的扩展是通过prototype来扩展的，这也是JavaScript中的唯一的选择，也是 Atlas的基础性的建设。我说的Atlas内部函数的倾向是指架构中类(class)以及继承等的实现。可以看出，在Atlas中除了对 Function，Array，String，Date的扩展和对Event的实现外，其他类的实现均是通过内部函数的方式，而不是prototype的方式，前面我说过，内部函数的方式有存在的必要性，但除非必要（比如你要实现一个供setTimeout使用的回调函数等），在JavaScript中对类实例的方法的标准实现是通过prototype的，这是ECMAScript的规范。当然不是说通过内部函数的方式实现不可以，就是存在内存和效率问题，如果一个类的实例可以预见到不是很多，则无所谓了。如果比较多的话，问题就来了。
我认为，在Atlas的客户端脚本中存在的某些倾向有一定的问题：
1. 为了语法的完整大量采用内部函数来实现类方法，前面已经说的够多的了。
2. 过份强调了严密性而放弃了灵活性和效率。典型的就是对对象属性的实现方式。大量采用了get_ set_ 这样的内部函数。就其好处，当然首先保证了私有变量安全，另外可以对属性的值进行校验，便于扩展，还有就是可以触发事件或者其他的联动计算来保证数据的完整性。另外在解析XML脚本时保证来对属性访问的合法性。PME的概念在.net中可以说时很普遍，也是C#,VB.net等语言固有的特性，但这些并不是JavaScript固有的特性，可以说JavaScript语言从设计到发展到标准化(ECMAScript)都不是这个方向，从将来的趋势来看也没有这种趋势。因为客户端脚本的目标和一个编译性语言时不同的，他的特点时简洁、灵活、强大，他存在于宿主环境中，他最主要的目标是操作宿主对象，所以对自身的面向对象的特性方面要弱一些，而且并不严密，存在很多不足。若非要那他来建立一个“坚固”的客户端脚本环境，我不会看好这个方向，或许微软把 Jscript.net强制放在IE环境下会比在jscript中磕磕绊绊地模拟好一些，但这是不可能的。要我来说的话，那些大量的set_ get_ 还是扔了吧，尽管他有不少好处，但和付出的代价来说，太不划算了。
Atlas的抱负可能太大了一些，依我看，照此路发展下去（不仅仅是客户端脚本）,很难成功。当然对于微软来说，没有什么是不可能的，我们还是拭目以待吧。
2.
其实这些是选择实现JS类的比较关键的地方。Atlas的目的是完整的在客户端实现一个尽量严谨的OO机制，但是有些地方受限于JS本身导致的不足，而又异常复杂，实现得也不很直观，有种高不成低不就的感觉。因此我把它视为值得一提的缺点。
在Atlas的“硬伤”之下，还是可以有针对性地进行优化，这个需要大量的琢磨、归纳和努力啊，路漫漫其修远兮……
做人要厚道，请注明转自酷网动力(www.ASPCOOL.COM)。