企业级b/s应用系统采用怎样的javascript框架

在过去的很长的一段时间，我都从事b/s应用系统开发，我要做的事情就是怎样做界面规范以保证UI风格统一，同时保证开发的高效性。具体而言，我要做的工作需要把css写好，开发者做界面时能方便的写html和样式。可更多的经历我都花在javascript上。

　　问题一：要不要采用javascript框架？

　　我刚到公司的时候，我们的技术架构师是不同意使用javascript 框架。理由很多，javascript 没有得到应有的重视是主要的原因，他一直强调我们做的是应用系统。所以他只在网上找到几个js放在项目下面，然后页面上很乱，要写一颗树展现真是麻烦又麻烦。而且大家的javascript水平都很一般，基本只是稍微了解一点。用的最多的还是数据校验，写的方法还是document.form1.formname,document.add['id']之类的写法。这让我这个天天关注界面的技术人员(冒昧自称技术人员，其实只是在界面层上有点研究而已)真是抓狂。很讽刺的是，为了使用一个小窗口弹出错误信息，把jqeury+ui搬出来。整个项目也只有这么一个地方用到jquery,去年的时候jquery的人气正在攀升。我来了之后，由于自己辈分小，在技术上说不上话，后来大家界面上开发的时候遇到这个那个问题解决不了的时候，大家慢慢的认识到了我的价值。新的项目领导让我负责界面规范这块，公司也想把这个项目做成一个产品。经过很多次“力荐”，我终于说服了大家，我们不能再"IE only" 了。

　　我认为使用的理由： 一，我们要有兼容各种浏览器的能力，现在新的浏览器大战正在打响，将来的浏览器市场还很难说。在css这方面 我借鉴了ext 的兼容思想，在body标签上加上class "IE IE6",这样我们不要使用hack 去兼容浏览器了。对于javascript上，基本上只有IE和非IE的差别了。主流的javascript框架都提供了很好的浏览器支持。二，用javascript框架的目的是提高开发效率。这与主流的javascript不谋而合。三，web应用正在飞速发展，界面层应用越来越复杂，javascript不在一个校验数据的脚本了，ajax的应用能很好的提升用户体验，有些场合使用ajax，用户操作更加方便。举个很简单的例子，很多的记录需要排序，虽然在数据上来看，只要改变排序值能解决问题，但在界面上，难道要用户去填写排序值，这样用户会觉得很难操作，而用上sortable，这个问题不仅简单，而且操作起来不知道清晰多少。我们从传统的c/s走到b/s不仅是因为b/s 不需要安装，升级容易。还是因为b/s具有更前的表现力
当然，反对使用javascript框架的理由也很尖锐。一，开发人员的水平很难以掌握现有的javascript框架。二，大家坚持认为，其实现在用的javascript的地方还不是很多。从需求上将屈指可数，tree,borderlayout,grid,calendar。

　　对此，我提出的想法就是，大家如果觉得难以使用的话，我在javascript框架上做一次封装，降低使用难度。第二个理由更好说，虽然现在使用的地方就那么几个，那好，你能拿出更好的方案么。曾经架构师说，我们希望每一个界面控件都是单独的，能单独使用。当然现在的主流javascript 都是这样的。这样，我就在大家仍用怀疑的眼光注视我的时候开始了javascript框架之旅。

　　问题二：用哪个javascript框架？

　　这个问题不是在讨论或者争执哪个好哪个不好，未免大家再又争执，我让他们自己找javascript框架，甚至可以把他们最熟悉的拿出来使用。大伙都说没有时间，这样我也不担心有人说后话了。

　　我把目前主流的javascript分为三类。

　　诸如：prototype/jquery/mootools这样的javascript框架，只能是javascript工具。他的优势就是扩展性强，社区支持很好，尤其是jquery

　　第二类就是：yui/ext/dojo/qooxdoo这样的框架。他们是一套全系列的纯客户端的ui解决方案，使用方便，能满足我们的需要。缺点是入口很高，适用于做富客户端。虽然我们现在的应用还是很多，但是还没有到那个地步。

　　还有一类就是与服务器端技术结合的ajax框架，他只能叫ajax框架,他基本只做数据交换。事实上只要做一个简单的servlet(j2ee)或者HttpHanlder(.Net)再在客户端加以封装，使用起来也是很方便的。所以这类ajax框架我认为不需要考虑。

　　在我看来，并不是那个框架绝对的好坏，而是什么样的框架能最好的满足你的需求。

　　论个人阅历上来讲，三类的多个框架我都知道一二。但是我最喜欢jquery,所以使用了jquery了，他的好处就是轻量级，扩展性强，现有的插件足以满足需要。代码非常简介而且执行效率高。于是我找了一大堆jquery插件。再自己封装城稍微简单的方法。本着不重复发明轮子的原则。很多的界面问题都能解决了。

　　问题三：真的是那样么？

　　时至2009,项目完了，到了需要再次封装城产品的时候，麻烦也就来了。我发现虽然jquery插件很多，很全，但是由于是百花齐放，我就不想修改里面的代码。慢慢的使用发现很多插件不是很稳定，像jstree,jquery ui 由于先前用的版本比较低，导致很有的bug自己写一些修正。现在回过头来看那时候做的东西，发现新的版本已经修复了这些功能。而换上新版本的jquery，变化还是蛮多，比如jquery.browser就不推荐使用了，怎么办。

　　将来。

　　本文就是在使用jquery之后，发现维护工作量也不小的背景下写下来的。我不知道是不是我当初选择jquery是错误的。是不是应该选择ext 之类的有着更强表现能力，更稳定的框架么？现在的代码还是不是那么理想。由于很多的历史原因，大家还在用ecside ，jscalendar。使用ecside是因为历史原因。使用jscalendar是因为jquery还没有一个日历控件能支持时间的。我一个人的精力有限，而且我很多的时间都在写项目代码(说到底还是领导不重视)。我担心我当时做的决定会对将来造成负面影响。

　　冒昧发在首页上，真诚的希望大家提出自己的看法，在企业级应用系统上界面层应该怎样做，文中的有些观点如有不对的地方还请大家指教