从JSF和Ext看WebUI开发－－给对JavaScript 有恐惧感的朋友

话题由来：http://www.iteye.com/post/523520?page=1

把其中我的观点整理出来：

100％支持fins！！！ B端和S端彻底分开，分别有自己的框架，“UI层与系统其他层面的东西的唯一联系应该是"数据" ，UI层应该是在后台系统不变的情况下可切换的”，这种架构策略完全可行，而且实际代码上也比JSF/asp.net等“server page”变种优雅，本人已经在N个项目中实践过： http://www.xjawa.org/xjawa/kontent/10020.html 使用这个7wxAop框架（浏览器端7wx + 服务器端Aop），有个朋友喜欢用Ext做前端，他就把7wx替换成Ext， 照样跑得很好： http://www.deepsoft.com.cn/ext-aop/demo.html 那些不理解fins得同学，可能是没做过ajax开发，或者ajax用的比较少，或者思想已经被“server page ”方式禁锢。虽然本质上 jsf 还是“server page”，但确实比jsp、tag强很多；但是比起B/S完全分开得架构，jsf还是很丑陋。 我们公司有个项目组用得是SAP得WebDynpro，和jsf类似，要比jsf成熟，但实际开发起来也是很多问题。 个人认为，fins设想的这种架构之所以未被普遍关注，是因为它损害了J2ee大厂商的商业利益，因此他们控制的主流IT媒体不愿宣传。想想：如果Server只是用来接受数据->处理逻辑->返回数据，服务器端将非常Lightweight和Performance，大厂商的J2EE服务器还有高性能硬件还会有几个项目需要？  ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 。。。正如我前面提到的，不理解fins的人大多是思想被“server pages”禁锢者，总认为浏览器只能负责 html render，其他一切都应该在服务器上完成，就如IT业早期的主机－字符终端模式。这种思想本质上是把浏览器看作21世纪的字符终端，完全忽略和闲置了目前运行浏览器pc的强大计算功能。 。。。在一个server和UI无关的模式下（下面称为“server business”，与“server pages”对应），server只是一个business logic server（只接受UI请求改变或查询系统的state），大致相当于砍掉了J2EE的Web层，Lightweight是肯定的了，至于Performance，除了节省处理 'UI layer'(NOT ONLY 'presentation layer') 的CPU开销，更重要的是大量节省服务器的出口带宽开销。 。。。“server business”模式(SB)与“server pages”模式(SP)本质上是不同的,SP下的'presentation layer'概念并不适合SB模式。 。。。将ajax单纯地视为transition technology本身也没什么错，虽然Ext等前端组件已经超越了这一概念。用Javascript framework称呼基于浏览器的“全功能UI Layer"并不适当，后者 = HTML + DHTML(DOM) + JS，JS只是一个粘合剂，Ext等前端组件本质上只是扩展了HTML Element，假设HTML 6.0包含了功能强大的TreeView、ListView(GRID)等通用UI组件，则JS将回归为单纯的DHTML API操纵语言。 至于RIA(javaFx or Flex)，我认为它是侧重多媒体表现的“全功能UI Layer"的等价物，它的发展前景取决于厂商对它的定位，如果你认同RIA，就没有理由不认同“全功能UI Layer"的思路。

JSF：基于服务器端的UI模型，Ext:基于浏览器端的UI模型。

很多人质疑以JavaScript为中心的UI开发，其实是对html/JavaScript的恐惧。

1、 不要把《 HTML(含CSS) + DHTML（或DOM）API + JavaScript开发》 简单理解成 JavaScript 开发。很多人觉得“JavaScript”难以掌握，是因为他们混淆了JavaScript脚本语言本身和它所要操纵的API：其实JavaScript本 身 非常简单，但它所要操纵的API“非常复杂”，因为HTML(含CSS) + DHTML（或DOM）API所涉及的API对象、属性、方法、事件数量巨大，可以说和Win32 API,JDK API（不单是swing/awt）同一个数量级。

2、HTML(含CSS)作为UI的表达语言，其“潜在的”界面表达能力应该说远远超越任何已有高端UI组件库（asp.net，jsf，Ext...）,因为它们本 身 都是基于HTML(含CSS)开发的，要想完整地（还不含绘图）、无障碍表达WebUI，掌握HTML(含CSS)及其API--DHTML（或DOM）是必由之路。

3、所有高端UI组件库的设计思想都是提高组件粒度，以掩盖HTML(含css)的复杂性。不同在于，服务器端UI组件（asp.net，jsf）试图“彻底”掩盖，它们排斥直接使用HTML(含css)，并且操纵UI组件的API面向后端语言（C#,VB,java）；而浏览器端UI组件（Ext等）是“开放性的”封装，允许直接操作HTML(含css)，操纵UI组件的API面向javascript。

4、服务器端UI组件的使用者，一般不太关心组件的具体实现，而且使用中也缺乏HTML+JS的训练，当组件功能满足不了要求时，自己扩展组件的难度很大，也就时说使用组件和开发组件之间存在巨大鸿沟。而浏览器端UI组件的使用者，一般会大致了解组件的实现，使用中频繁接触HTML，JS操纵能力也得到训练，因此他们会比较自然地形成组件改造扩展能力，使用组件和扩展组件之间得学习曲线是平滑的。

5、因此，从开发人员自身职业发展的角度看，要想成为无障碍的Web开发者，使用浏览器端UI组件模式应该是更好的选择。

作为Web开发者，必须热情拥抱HTML（css）和javascript，否则只能是半拉子开发人员。