对于这个预测，我和一些朋友认为孟岩老师过于乐观了。我预测至少到2010年，基于Web标准的界面开发技术仍然将是Web界面开发的主流技术，而这些技术的集大成者就是Ajax。Ajax技术在最近两年中取得了很大的发展，并且仍然在迅速发展的过程中，现在就断言Ajax技术即将没落还为时尚早。

　　诚然，从纯技术的角度来看，我们也早就认为XUL/XAML一类使用XML来描述界面组件和布局的技术肯定是Web界面开发技术的发展趋势。W3C今年成立了一个工作组，希望将XUL、XAML、MXML等几种界面描述语言统一为一种标准的格式(http://www.w3.org/2006/appformats/)。所以我们认为孟岩老师所看到的趋势是没有大问题的。从纯技术的角度来看，将来的Web界面开发肯定会发展到这种技术。

　　然而，能看到趋势当然很重要，但是我们还是需要解决很多现实的问题。我在这里提出几个问题来与大家探讨。

　　第一个问题是:这种趋势将会以多快的速度成为现实?

　　技术的发展和演进往往都是一个长期的过程。面向对象开发取代面向过程开发、Java取代C++、Ruby逐渐取代Java都是一个长期的过程。孟岩老师所预测的2年和我所预测的4年似乎相差不大，但是对于我们现阶段所要采取的行动其实影响很大。

　　即使正如孟岩老师所预言的，这确实是技术发展的趋势又能怎样?我们是否一定要在今天为明天和后天发生的事情而买单。过早为将来发生的事情买单，很可能会代价高昂。这跟炒股差不多，有经验的玩家会在最适当的时机入手。过早入手、过晚入手，都会蒙受损失。在这种趋势成为现实之前，我们是否坐等共产主义的实现?我认为等待并不是一种积极的态度。

　　第二个问题是:Ajax有何优点?

　　我认为孟岩老师并没有充分地看到Ajax的优点。孟岩说:“昨天我还在说Ajax是过渡技术，没想到几个小时之后就得到印证。” 其实严格说来，任何的技术都可以称为是过渡技术，但是这并不会妨碍使用这种技术来为用户创造价值。孟岩只看到了使用基于Web标准的界面开发技术开发效率低下的一面。但是目前国内做界面开发的开发者有多少人真正理解了Web标准呢?根据笔者的经验，采用完全的CSS布局，将页面的结构、表现、行为三部分分离开，注重页面各部分的重用。经过一段时间的积累之后，基于Web标准的界面开发完全可以达到比较理想的开发效率。而配合使用Dojo、Scriptaculous、YUI等成熟的Ajax组件库，还可以更进一步提高界面的开发效率。在笔者看来，影响开发效率的问题主要有两个方面:

　　1 Web界面开发者没有充分理解Web标准。
　　2 Web界面开发者没有尝试过组件化的开发方式。
　　相对于其他技术而言，Ajax最大的优点有这三点:

　　1 Ajax是完全基于Web标准的技术，Ajax所用到的所有的技术都是真正的Web标准。
　　2 Ajax应用可以毫无障碍地部署到几乎所有的桌面电脑上。
　　3 Ajax应用的开发和部署成本很低。
　　对于第一个优点，有人可能会争论说，标准其实并不重要。例如EJB 2.x是标准又如何，现在不是也一样被抛弃了吗?但是这两种标准是不可相提并论的。EJB的标准在推出之时，完全没有经过开发实践的检验，与开发实践严重脱节。然而Web标准却是从开发实践中积累而来的。Ajax所基于的这些Web标准都是先有了非常成熟的应用和成功的商业案例之后才会形成标准。Web标准之所以成为了今天这个样子，是经得起历史考验的。如同TCP/IP标准一样，它仍然会长期沿用下去。

　　第二个优点其实是第一个优点所派生的。上世纪90年代末，在Web标准组织和W3C的不懈努力下，结束了浏览器大战，各种浏览器都承诺支持真正的Web标准。今天这种支持到了开花结果的时候，结出的果实就是诞生了一种称作Ajax的新技术。正是因为今天所有主流的浏览器都已经能够很好地支持Web标准(通常即XHTML+CSS+JavaScript)，而几乎所有桌面电脑上都安装了某种主流的浏览器(IE、Firefox/Mozilla、Opera、Safari、etc.)，因此Ajax应用可以无痛地部署到几乎所有的桌面电脑上。尽管今天不同的浏览器对于Web标准某些部分的理解还略有歧义，实现上略有差异。但是只要基于成熟的组件库来做开发，这些差异可以被最小化，已经不会成为开发的障碍。

　　如果我在这两三年内想建立一个电子商务网站，却只能部署到几百万个安装了XAML render引擎的用户机器上(而不是像Ajax那样几乎所有的桌面电脑)。除非我的脑子坏掉了，我不会做出这样的选择。对于面向互联网的应用而言，基于真正Web标准来做开发，并且随着Web标准及其浏览器实现的发展而演进，是实现最大商业利益的必然选择。

　　Ajax应用可以被部署到几乎所有桌面电脑上这个事实是其他所有技术多年来梦寐以求而不可达的理想国。另外一种现实的选择是Flash UI，Flash的部署范围也已经达到了足以大规模应用的程度。出于现实的商业考虑，我在几年之内都不会选择基于XAML建造我们的应用，除非它的部署范围达到了某个临界值，并且有朝一日成为真正的Web标准。

　　第三个优点是因为，开发Ajax应用所需要的工具几乎全部都是开源软件，可以免费获得，因此不必花钱去购买昂贵的开发工具。其实开发简单的Ajax应用，一个主流的浏览器，再加上一个文本编辑器就已经足够了。只要你所开发的代码质量足够高，Ajax应用的部署可以达到完全的零成本。

　　第三个问题是:基于浏览器和Web标准的开发技术是否一定会没落?

　　我和孟岩老师的一个主要的分歧在于，我并不认为基于浏览器和Web标准的开发技术一定会没落。其实早在3年之前，当我尝试基于XMLHttpRequest来设计我们的架构和开发我们的应用时，当时已经有很多人预言基于HTML(或者XHTML)+JavaScript的开发方式必然会很快没落，对于我对JavaScript如此热衷很不理解。但是几年过去了，这种开发技术非但没有没落，反而焕发出了勃勃的生机。这是在其没落或灭亡之前的回光返照吗?至少在我看来并不是这样，而是有其内在的规律。正是因为上面我所说到的这种开发技术的优点，今天几乎所有的Web用户都在使用这种技术。有庞大用户量广泛使用的技术必然会不断发展，而不可能很快没落。其实XAML最终是否会取代Ajax，这并不是一个纯技术的考量，而是涉及到整个Web应用生态系统的迁移。今天90%以上(我的保守估计)的Web应用都建立在基于Web标准的界面开发技术之上，轻言这种技术在两年之内必然会没落是不严肃的。单靠微软等几个大公司想要扭转这种长期以来自然形成的状况，谈何容易?我认为不大可能。

　　所以在我看来，这种开发技术仍然会不断地发展和进步，自然地演化到一些新的Web标准(例如XHTML 2.0、CSS 3.0、JavaScript 2.0)。它的生命力会历久弥新，我敢与任何人打这个赌，至少到2010年，这种技术仍然将会是Web开发技术的主流。当然到了那个时候，XAML也可能会发展为Web开发技术的主流，因此会出现一种百花齐放的状况。这并不是一场零和的游戏，只会出现一个赢家，其他人都会输，赢家通吃的情况我认为并不会出现。

　　第四个问题是:是否深入学习Ajax就无法得到“这一代Web技术和体系的理解”?

　　孟岩老师说:“我们今天所说的Web开发高手，有多少是把自己的身家性命押宝在对这一代Web技术和体系的理解上?”

　　这句话有很大的误导性，似乎深入学习Ajax就无法得到“这一代Web技术和体系的理解”。至少根据我的个人经验，深入学习Ajax可以帮助我们更好的获得“这一代Web技术和体系的理解”。我今年组织翻译了《Ajax in Action》、《Ajax Practices and Best Practices》，还将要从台湾引进《Ajax Design Patterns》。这几本书使得我对于国外的Web开发高手的水平叹服不已，并且很大地加深了我对于“这一代Web技术和体系的理解”。

　　孟岩老师还说:“且不说他们日常工作中大多数时间花在了界面开发之上，就算是很多人引以为傲的所谓“大负载量Web站点架构”，也将随着 RIA的兴起而发生一场巨大变革。大量页面状态将前移到客户端，Web服务端将以全新的观点重新组织资源，逐渐变成真正意义上的Web Services集合。旧的知识和经验迅速贬值，新的机会快速涌现，有的人沉下去，有的人飘起来，历史又要重来一遍了”

　　我可以肯定孟岩老师并没有深入研究过Ajax应用的架构，因此才会误以为“大量页面状态将前移到客户端，Web服务端将以全新的观点重新组织资源，逐渐变成真正意义上的Web Services集合。”与Ajax是完全矛盾的。与孟岩老师这种大开大合的革命性预测不同，我认为技术从来都不是以这种方式进步的。技术进步是一个自然的缓慢演化过程，面向对象逐渐取代面向过程、Java逐渐取代C++、Ruby逐渐取代Java，都有很大的传承关系在里面。将某种技术描述为横空出世的“天生石猴孙悟空”，我认为是不严肃的，也是没有做深入研究的体现。我并不认为以前在传统Web开发技术方面所积累的知识就会很快贬值。只要自己与时俱进，不断补充新的营养，“大负载Web站点架构”的经验永远都是很宝贵的实践经验。Ajax技术，正是目前绝大多数传统的Web开发团队向RIA时代迁移的最自然的选择路径。

　　第五个问题是:程序员做界面开发是否是不可能的?这是否就是Web应用开发效率的瓶颈所在?

　　孟岩老师说:“因为今天Web开发中，设计人员基本只是解决页面布局与图片效果的设计，而大量动态界面效果还需要开发者来完成。 Expression + Visual Studio的模型则将“与用户交互的界面部分”与“后台业务逻辑”完全分开。设计人员凭借类似Flash的方式，就可以开发出类似视频游戏那样的用户界面。”

　　我是做Java开发的，如果我作为技术负责人，我的团队中将会有这些分工:

　　1 业务逻辑开发人员，使用Java和Spring等框架做开发。
　　2 界面逻辑开发人员，负责View的开发，精通FreeMarker、XHTML、CSS、JavaScript等技术。
　　3 美工，负责制作图片，对于页面的样式和配色提供指导，用Photoshop设计出页面样式，交给界面逻辑开发人员来制作。
　　由界面逻辑开发人员来制作页面，制作的页面必须达到我的要求。例如，完全基于CSS的布局，在各种主流浏览器上都要正常显示等等。在我这里，业务逻辑开发人员和界面逻辑开发人员并不存在谁高谁低之分，薪水也是基本相同的水平。孟岩认为在基于Web标准的开发过程中，程序员不应该做页面，这个看法是错误的。程序员是否做页面也并不是开发效率的瓶颈。如果某个程序员精通了上述这些技术，他完全可以迅速开发出美观的页面。特别是在注重页面中XHTML/CSS/JavaScript各部分的重用的情况下，积累上一年之后，要开发的很多东西都是相似的。孟岩老师认为完全的分工可以达到最大的开发效率，这是一种幻想。为什么Web开发从J2EE非常清晰的分层又变成了在RoR中不是很清晰的分层?软件开发并不是流水线式生产。分工应该适当，分工太细，不同层次之间沟通的成本就会迅速上升。这又回到了《人月神话》中的命题:主要的成本在于沟通的成本。依靠细致的分工降低对开发人员素质的要求，实现流水线式生产，创造大批软件蓝领，这本身就是一个幻想。Ruby解决问题的思路与此是不同的，Ruby的思路是提高抽象的层次，使得一个开发人员有能力承担更多功能的开发。

转自:http://searchwebservices.techtarget.com.cn/comment/469/2691469_3.shtml