WEB技术随着互联网的崛起而崛起，又随着移动互联网的发展而呈现更加多样化的趋势。
黑暗时代：大约在2005年以前，所谓的WEB开发主要还是美工的活，HTML/CSS占主导，Dreamwaver做为页面设计三剑客之一，成为大多数WEB程序员的必备利器。Javascript能不用就不用，能少用就少用，浏览器只考虑IE。那时候的Javascript显得非常异类、原型继承、语法灵活多变、调试困难（还记得在IE中调试Javascript的痛苦经历吗？），一般程序员都不愿意干前端的活。好不容易出来一个Bindows，被许多程序员捧为神器。但稍加试用就发现慢如蜗牛，问题不断，根本不能实用。由此可见那时的浏览器也不重视Javascript引擎的优化。那是WEB开发的黑暗时代。 文艺复兴：到了2005年左右，大家慢慢也都注重用户体验了，AJAX技术也日益普及了，ＷEB2.0的提法也甚嚣尘上，自己的应用若不贴上WEB2.0的标签都不好意思和人打招呼了。那时候的Java社区在Struts/Spring/Hibernate的带领下风风火火、异常活跃。此时，Ruby On Rails出现了！其约定优先的理念，简直让SSH模式下繁杂的XML配置方式无地自容。在新技术新理念层出不穷的大背景下，jQuery于2006年横空出世。jQuery的出现，彻底终结了WEB开发的黑暗时代，迎来了WEB领域的“文艺复兴”。Ajax技术的广泛运用、WEB标准化的逐步推进、浏览器市场的缓慢变化，等等，都是这种“复兴”的佐证。 百花齐放：如今，在距离Apple于2007年推出首部IPhone以来，时间已过去６年多，这正是移动互联网从起步到高速发展的年份。对用户体验的极致追求，导致WEB技术发生了更加深刻的变化。Javascript走向服务端成就了node.js，而Flush技术由于商业和技术的原因似乎正逐步走向衰落，各种基于Javascipt的MVC框架层出不穷，流式布局、响应式布局、自适应、拟物化设计、扁平化设计等概念不断涌现，现今正是WEB领域百花齐放的时代。
现在做WEB开发，也如同做Java服务端开发一样，要在众多的基础库、开发框架当中做出合适的选择：
jQuery：以简洁的链式操作而闻名，封装了底层浏览器的API，屏蔽浏览器实现的差异，是当前最流行的基础库；不过随着HTML５标准逐渐被各大浏览器厂商所接受，jQuery的作用也大打折扣，其发行包大小也常常为人们所诟病。 mootools：当年与jQuery一较高下的框架有prototype.js和mootools。当年prototype得到ruby社区的大力支持，一度与jQuery较量得不相上下。而mootools则得到Java阵营的支持，虽然比不上前两者，但由于其api设计比较符合java程序员的习惯，因此也发展得风生水起。前段时间看到prototype作者撰文承认了prototype的失败，如今在底层库的选择上还是jQuery一家独大的局面； dojo：dojo是类似于java swing的完整框架，既包含了基础库，也包含了大量的UI组件。尽管dojo得到了struts２的大力支持，但还是无法扭转其江湖地位； extjs：类似当年的Bindows，在WEB中实现类似桌面程序的效果。当年Bindows因为性能问题惨死沙场，只能说它生不逢时。不过extjs如今的命运也让人堪忧，一成不变的界面风格和操作模式其实是违背WEB千变万化的本质特征的； easyui：基于jQuery的声明式UI组件库。所谓声明式组件，是指不需要象传统桌面程序一样通过写代码的方式创建和设置组件，只需要遵循最原始的HTML声明式理念，在原始HTML Tag上设置属性就能得到想要的效果；类似easyui的国产框架DWZ也是类似思路； backbone：基于Javascript的MVC框架，MVC理念在浏览器中的完整实现。可以想见，这类框架在处理客户端多视图数据同步方面具有很大的优势，可以大大简化客户端展现及交互逻辑的开发过程；选择上述某一种或某几种基础库或开发框架，就意味着选择了一种开发模式。从开发模式的角度我们可简单总结一下：
传统的HTML+CSS+JS模式：这种模式下，开发人员需要编写大量的HTML代码，用于实现页面的展现逻辑，编写JS代码用于实现交互逻辑。这是最传统的开发方式，同时也是运用最广泛的开发方式，不论企业级管理系统还是电商类网站、拟或手机WEB应用，都可以采用这种方式实现；该方式的缺点是实现单页面应用或复杂交互应用时JS代码量较大； 桌面应用开发模式：如EXTJS，页面全部使用JS来实现，开发人员基本不需要编写HTML代码，大量的展现逻辑和交互逻辑使用JS代码完成。这种方式用于实现单页面应用非常方便；但要求开发人员对JS及开发框架的组件库有深入了解；思维模式上要适应基于组件的事件机制； 声明式UI开发模式：如easyui及国产DWZ，页面的展现逻辑如同第一种模式一样使用HTML实现，但是相比第一种模式，这种模式对组件的抽象做得更好，部分传统模式下用JS实现的展现逻辑甚至是交互逻辑也可以使用声明方式实现。可以说这是对第一种模式的增强； 客户端MVC开发模式：如backbone，这种模式与桌面模式相似，通过大量的JS代码实现页面的展现和交互逻辑，但通过在客户端维护数据模型及其状态，再运用视图与模型的绑定机制，可以大大减少JS代码量；第一种模式与第三模式相似，都是以HTML代码实现展现逻辑、以JS代码实现交互逻辑，只是第三种模式通过更多的抽象组件，尽量使用HTML实现尽可能多的展现和交互逻辑；第二种模式与第四种模式类似，都是偏重于尽量使用JS实现展现逻辑和交互逻辑，HTML仅仅做为页面布局或页面容器。相对来讲，第二种模式偏重于使用JS实现界面视图的组装，而第四模式偏重于使用JS实现完整的MVC机制，在backbone中，视图也通常是使用基于HTML代码片断的模板方式来实现。
由于第三种模式是第一种模式的增强，因此在实际项目中可以尽量选择第三种开发模式；第二种模式相比第一种和第三种模式来讲，主要是开发方式的不同，前者侧重于JS，后两者侧重于HTML，除此之外，两者的应用场景和应用范围都很相似。
尽管第四模式与第二种模式一样也是偏重于使用JS实现页面逻辑，但由于其强大的MVC机制，因此它与第二种模式有着本质的不同。试想对于gmail之类的应用，如果客户端底层没有维护一套邮件的数据模型的话，要单纯使用前面三种方式实现当前gmail的页面交互效果将是非常困难的。
总之，对于WEB开发模式的选择，现阶段个人建议优先选择第三种模式。如果应用交互非常复杂，或者需要实现更好的交互体验（比如支持本地存储、undo、redo等），而导致大量的JS代码的话，则可以考虑使用第四模式。
