《Prototype 与 script.aculo.us终极揭秘》一书的序言
2005年对于Web开发来说是一个伟大的年份。在这一年中，有两个技术异军突起，一个是Ajax，另一个是Ruby on Rails。这两个技术的出现改变了Web开发的面貌，甚至打乱了JavaEE前进的步伐。多年以来，JavaEE设计者们为自己所设计的无所不包的复杂架构而陶醉，新的buzz word层出不穷，一出来就会得到广泛的关注，相关的图书也会热卖。辉煌的JavaEE版图中居然还有完全被忽略的死角，这是JavaEE设计者们始料不及的。事实上他们在JavaEE的架构中从来就没有考虑过浏览器端的处理能力，浏览器对于JavaEE来说是完全无智能的瘦客户端。他们这样设计情有可原，因为他们只能把设计局限在Java能够控制的区域内，在Java Applet彻底失败之后，Java能够控制的区域退守到了服务器端。毫无疑问，JavaEE取得了巨大的成功，但是这种完全基于服务器端的解决方案很难向用户提供优秀的交互体验，同时也很难实现最佳的可伸缩性（Scalability）。
Ajax是用户和市场的选择，这个由群众创造出来的buzz word时常响在JavaEE设计者的耳边，令他们非常烦躁。甚至有人发明出了“JavaEE without Ajax”的口号，和2004年Rod Johnson所提出的“J2EE without EJB”相对应。但是仔细考察这个“without Ajax”，我们却发现它和“without EJB”说的并不是一个意思。“without EJB”的意思就是不使用EJB，而“without Ajax”的意思却不是不使用Ajax，而是设法将Ajax隐藏掉，使得普通的JavaEE开发者不需要学习Ajax。在这个口号的发明者所设计的JSF框架中，内嵌了一个Ajax组件库ExtJS，看来他们还是需要Ajax的帮助的。所谓的“JavaEE without Ajax”其实是一个伪命题，只是用来吸引眼球的噱头，主要的目的是为了迎合了一些讨厌Ajax、对于浏览器端脚本编程没有兴趣的的JavaEE开发者。其实无论开发Web应用，还是开发B/S结构的企业应用，交互体验都是非常重要的。在交互体验越来越受到重视的今天，想要把Ajax排除在外，可以说是一件不可能的任务。
尽管Ajax开发确实很重要，但是无须讳言的是Ajax开发，特别是DHTML开发至今仍然是一件很复杂的工作，必须具备专业的技能。除了高超的开发技能之外，还需要开发者对于Web可用性和交互设计具有足够的理解。这超出了Web页面设计师和制作人员的能力范围；而对于服务器端开发者来说，这些显然也不是他们的特长（他们的特长是处理业务逻辑和与数据库打交道，而不是界面开发和交互设计）。在Web页面设计师和服务器端开发者之间出现了巨大的断层，这使得高水平的Ajax开发者一下子变得炙手可热。
JavaEE设计者们简化Ajax开发的努力是可以理解的。但是我们需要讨论清楚一个问题:究竟怎样做才能真正简化Ajax开发？
在我看来，JavaEE社区简化Ajax开发的努力都不是很成功。将ExtJS嵌入在JSF框架中，确实可以实现一些简单的交互需求，但是这种做法其实阉割掉了Ajax主要的能力——直接在浏览器端处理用户的事件。JSF的事件模型是完全位于服务器端的，界面的任何改变都需要发送事件到服务器端做处理。即使引入了ExtJS，也不可能改变这一点。Struts2/WebWork和jMaki中通过使用taglib集成Ajax组件库的做法也感觉笨拙而不自然。之所以集成的效果不理想，是因为传统的JavaEE框架和Ajax组件库的核心架构设计都没有考虑到对方的需求，它们在架构设计上存在着内在的冲突，拉郎配的结果是可想而知的。这些JavaEE表现层框架集成Ajax组件库，是希望将Ajax组件库改造为JavaEE世界的顺民，服从JavaEE框架的架构约束，但是这样做不可避免地会削弱Ajax组件库的能力。要简化Ajax开发并且充分用好Ajax技术，仅仅使用taglib来对Ajax组件库做封装是不够的，服务器端的架构也必须加以改造，甚至需要设计出一套全新的架构，这是传统的JavaEE表现层框架无法做到的。Google的GWT同时具有浏览器端和服务器端，似乎是一个很好的选择，但是GWT主要是为实现一类One Page的Ajax应用而设计的，它模仿的是桌面应用的交互模型，而绝大多数的Web应用是不可能采用这种交互模型的。DWR也是一个跨浏览器端和服务器端的框架，但是DWR的RPC风格的API是我所不喜欢的。RPC架构和REST架构在可伸缩性方面的差距是巨大的，Ajax应用的最佳的架构是REST而不是RPC，同时REST在简化编程模型方面的效果也要比RPC更好。
要简化Ajax开发，我认为需要满足以下三个要求：
1. 由专业的DHTML开发者开发出的更加全面和强大的Widget库。这部分的开发应该由专业人士来做，这样就可以把负担从普通的Web开发者身上卸掉。开源软件是开发Widget库的必由之路。
2. Ajax组件库要与服务器端框架做更加紧密的集成。服务器端框架的架构需要加以改造以适应Ajax和REST的需求，不能指望以不变应万变。
3. 简化的编程模型。这包括两个方面：a) 通过与服务器端框架紧密集成，使得服务器端开发者仅仅使用服务器端编程语言就能够实现一些普通的Ajax需求。b) 更加复杂的交互需求如果必须要做DHTML开发，需要大幅降低DHTML开发的难度。
当我把眼光投向了Ruby on Rails之后，包括Ajax开发在内，一切都变得容易了很多。Rails通过其RJS模板集成了两个Ajax组件库Prototype和基于Prototype的script.aculo.us。Rails集成这两个组件库的方式显得非常自然，因为这两个组件库正是Rails和Ajax相结合的产物，它们都是由Rails的核心开发人员所开发的，充分考虑到了Rails在架构方面的需求。现在这两个组件库已经长大成人，完全可以独立应用在非Rails环境中。Rails + Prototype/script.aculo.us满足了上述三个要求，因此是目前做Ajax开发的最佳组合。当然，上述三个要求每一个都还有很大的改进余地，但是Rails + Prototype/script.aculo.us走在了正确的道路上，前景是非常光明的。
随着Ajax技术的普及，传统的DHTML组件库恢复了生机，并且加以改造以适应新的交互需求。这些DHTML组件获得了一个时髦的新名称——Widget。我一般是将Ajax组件库分成三部分：
1. 基础库。包括：a) 对于JavaScript语言的增强，为目前浏览器所支持的JavaScript 1.x版提供继承、包管理等等面向对象编程所需要的支持。b) 封装HTML DOM的API，提供编程模型更加简化的API。
2. Web Remoting库，通过XMLHttpRequest/IFrame/JSONP等等机制与服务器交互，从服务器获取数据。
3. 丰富的Widget库，用来实现各种交互需求，改善用户的交互体验。
Prototype库实现了第一部分和第二部分，script.aculo.us库实现了第三部分。在这三部分中，开发工作量最大的是Widget库。正是因为市场上对于Widget库有着巨大的需求，在2007年涌现出了大量Widget库，开源的包括script.aculo.us、Dojo、YUI、ExtJS、Mootools、jQuery UI、Spry、Tibco GI、Qooxdoo，私有的包括ASP.NET Ajax、Dorado、Zimbra等等，全部列举下来不下2、30个。Apple公司在这一年推出了iPhone手机，其中的Widget全部是使用DHTML开发的，达到了交互体验的极致，同时也展示出Widget开发的美好前景。很多人说2007年是Widget年，这个说法是有道理的。到了2008年，Google公司推出了Open Social，其核心是Google所提供的Widget开发API和Widget的部署容器。Google管这些Widget叫做Google Gadget，Gadget将Widget的开发水平推向了新的高度。
无论是基于现有的Widget开发Ajax功能，还是开发新的Widget，Prototype/script.aculo.us都是我们手中的一件利器。网上的很多投票都显示出，Prototype/script.aculo.us组合是最受欢迎的Ajax组件库。因为Prototype大受欢迎，其爱好者基于Prototype还开发了很多其他的组件库，Prototype家族成员的数量还在不断增加。很多Ajax组件库最大的问题是缺乏详尽的文档，API参考并不能代替文档。从文档的数量和质量来说，Prototype/script.aculo.us的文档在所有Ajax组件库中都是最棒的。《Prototype and script.aculo.us中文版》这本书的出版，为爱好者深入学习这两个组件库提供了极大的便利。这本书的副标题是“You Never Know JavaScript Could Do This!”，确实，正是通过这些优秀的Ajax组件库、这些勇于探索的Ajax顶尖高手们，我们才知道浏览器端脚本编程的世界原来是如此灿烂。基于Prototype/script.aculo.us做Ajax开发是一种很愉快的体验。学习越深入，这种愉快的感觉就越强烈。那么，你还在等什么呢？