在過去的很長的一段時間，我都從事b/s應(yīng)用系統(tǒng)開發(fā)，我要做的事情就是怎樣做界面規(guī)范以保證UI風(fēng)格統(tǒng)一，同時保證開發(fā)的高效性。具體而言，我要做的工作需要把css寫好，開發(fā)者做界面時能方便的寫html和樣式。可更多的經(jīng)歷我都花在javascript上。
問題一：要不要采用javascript框架？
我剛到公司的時候，我們的技術(shù)架構(gòu)師是不同意使用javascript 框架。理由很多，javascript 沒有得到應(yīng)有的重視是主要的原因，他一直強調(diào)我們做的是應(yīng)用系統(tǒng)。所以他只在網(wǎng)上找到幾個js放在項目下面，然后頁面上很亂，要寫一顆樹展現(xiàn)真是麻煩又麻煩。而且大家的javascript水平都很一般，基本只是稍微了解一點。用的最多的還是數(shù)據(jù)校驗，寫的方法還是document.form1.formname,document.add['id']之類的寫法。這讓我這個天天關(guān)注界面的技術(shù)人員(冒昧自稱技術(shù)人員，其實只是在界面層上有點研究而已)真是抓狂。很諷刺的是，為了使用一個小窗口彈出錯誤信息，把jqeury+ui搬出來。整個項目也只有這么一個地方用到j(luò)query,去年的時候jquery的人氣正在攀升。我來了之后，由于自己輩分小，在技術(shù)上說不上話，后來大家界面上開發(fā)的時候遇到這個那個問題解決不了的時候，大家慢慢的認(rèn)識到了我的價值。新的項目領(lǐng)導(dǎo)讓我負(fù)責(zé)界面規(guī)范這塊，公司也想把這個項目做成一個產(chǎn)品。經(jīng)過很多次“力薦”，我終于說服了大家，我們不能再"IE only" 了。
我認(rèn)為使用的理由： 一，我們要有兼容各種瀏覽器的能力，現(xiàn)在新的瀏覽器大戰(zhàn)正在打響，將來的瀏覽器市場還很難說。在css這方面 我借鑒了ext 的兼容思想，在body標(biāo)簽上加上class "IE IE6",這樣我們不要使用hack 去兼容瀏覽器了。對于javascript上，基本上只有IE和非IE的差別了。主流的javascript框架都提供了很好的瀏覽器支持。二，用javascript框架的目的是提高開發(fā)效率。這與主流的javascript不謀而合。三，web應(yīng)用正在飛速發(fā)展，界面層應(yīng)用越來越復(fù)雜，javascript不在一個校驗數(shù)據(jù)的腳本了，ajax的應(yīng)用能很好的提升用戶體驗，有些場合使用ajax，用戶操作更加方便。舉個很簡單的例子，很多的記錄需要排序，雖然在數(shù)據(jù)上來看，只要改變排序值能解決問題，但在界面上，難道要用戶去填寫排序值，這樣用戶會覺得很難操作，而用上sortable，這個問題不僅簡單，而且操作起來不知道清晰多少。我們從傳統(tǒng)的c/s走到b/s不僅是因為b/s 不需要安裝，升級容易。還是因為b/s具有更前的表現(xiàn)力。
當(dāng)然，反對使用javascript框架的理由也很尖銳。一，開發(fā)人員的水平很難以掌握現(xiàn)有的javascript框架。二，大家堅持認(rèn)為，其實現(xiàn)在用的javascript的地方還不是很多。從需求上將屈指可數(shù)，tree,borderlayout,grid,calendar。
對此，我提出的想法就是，大家如果覺得難以使用的話，我在javascript框架上做一次封裝，降低使用難度。第二個理由更好說，雖然現(xiàn)在使用的地方就那么幾個，那好，你能拿出更好的方案么。曾經(jīng)架構(gòu)師說，我們希望每一個界面控件都是單獨的，能單獨使用。當(dāng)然現(xiàn)在的主流javascript 都是這樣的。這樣，我就在大家仍用懷疑的眼光注視我的時候開始了javascript框架之旅。
問題二：用哪個javascript框架？
這個問題不是在討論或者爭執(zhí)哪個好哪個不好，未免大家再又爭執(zhí)，我讓他們自己找javascript框架，甚至可以把他們最熟悉的拿出來使用。大伙都說沒有時間，這樣我也不擔(dān)心有人說后話了。
我把目前主流的javascript分為三類。
諸如：prototype/jquery/mootools這樣的javascript框架，只能是javascript工具。他的優(yōu)勢就是擴(kuò)展性強，社區(qū)支持很好，尤其是jquery
第二類就是：yui/ext/dojo/qooxdoo這樣的框架。他們是一套全系列的純客戶端的ui解決方案，使用方便，能滿足我們的需要。缺點是入口很高，適用于做富客戶端。雖然我們現(xiàn)在的應(yīng)用還是很多，但是還沒有到那個地步。
還有一類就是與服務(wù)器端技術(shù)結(jié)合的ajax框架，他只能叫ajax框架,他基本只做數(shù)據(jù)交換。事實上只要做一個簡單的servlet(j2ee)或者HttpHanlder(.Net)再在客戶端加以封裝，使用起來也是很方便的。所以這類ajax框架我認(rèn)為不需要考慮。
在我看來，并不是那個框架絕對的好壞，而是什么樣的框架能最好的滿足你的需求。
論個人閱歷上來講，三類的多個框架我都知道一二。但是我最喜歡jquery,所以使用了jquery了，他的好處就是輕量級，擴(kuò)展性強，現(xiàn)有的插件足以滿足需要。代碼非常簡介而且執(zhí)行效率高。于是我找了一大堆jquery插件。再自己封裝城稍微簡單的方法。本著不重復(fù)發(fā)明輪子的原則。很多的界面問題都能解決了。
問題三：真的是那樣么？
時至2009,項目完了，到了需要再次封裝城產(chǎn)品的時候，麻煩也就來了。我發(fā)現(xiàn)雖然jquery插件很多，很全，但是由于是百花齊放，我就不想修改里面的代碼。慢慢的使用發(fā)現(xiàn)很多插件不是很穩(wěn)定，像jstree,jquery ui 由于先前用的版本比較低，導(dǎo)致很有的bug自己寫一些修正。現(xiàn)在回過頭來看那時候做的東西，發(fā)現(xiàn)新的版本已經(jīng)修復(fù)了這些功能。而換上新版本的jquery，變化還是蠻多，比如jquery.browser就不推薦使用了，怎么辦。
將來。
本文就是在使用jquery之后，發(fā)現(xiàn)維護(hù)工作量也不小的背景下寫下來的。我不知道是不是我當(dāng)初選擇jquery是錯誤的。是不是應(yīng)該選擇ext 之類的有著更強表現(xiàn)能力，更穩(wěn)定的框架么？現(xiàn)在的代碼還是不是那么理想。由于很多的歷史原因，大家還在用ecside ，jscalendar。使用ecside是因為歷史原因。使用jscalendar是因為jquery還沒有一個日歷控件能支持時間的。我一個人的精力有限，而且我很多的時間都在寫項目代碼(說到底還是領(lǐng)導(dǎo)不重視)。我擔(dān)心我當(dāng)時做的決定會對將來造成負(fù)面影響。
冒昧發(fā)在首頁上，真誠的希望大家提出自己的看法，在企業(yè)級應(yīng)用系統(tǒng)上界面層應(yīng)該怎樣做，文中的有些觀點如有不對的地方還請大家指教