在過去的很長的一段時間，我都從事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還沒有一個日歷控件能支持時間的。我一個人的精力有限，而且我很多的時間都在寫項目代碼(說到底還是領導不重視)。我擔心我當時做的決定會對將來造成負面影響。
冒昧發在首頁上，真誠的希望大家提出自己的看法，在企業級應用系統上界面層應該怎樣做，文中的有些觀點如有不對的地方還請大家指教