爲何須要本身實現前端框架

前端對框架(庫)的大小更敏感

 

    前端內容的渲染和交互效果的實現若是依賴JS框架(庫)，須要先將這些框架(庫)下載到客戶端，此時框架(庫)的大小將直接影響到前端的首屏渲染速度。框架(庫)越小，加載的速度就越快，而隨着功能的愈來愈全，框架(庫)必然會愈來愈大，要保證性能，須要制定加載策略。

 

便於制定加載策略

 

    解決框架(庫)變大的常見加載策略是將框架分爲核心部分和擴展部分，核心部分在首屏渲染前必須下載完成，而且這部分的加載文件儘量的少和小，擴展部分則能夠模塊化方式來懶加載。

    

    核心部分的JS在發佈時，可對文件合併，數量儘量少，單個文件在gzip壓縮後最好不要超過20K。核心部分能夠是實現「JS語言擴展(面向對象)，DOM操做API，數據交互方法(ajax)，導航策略，模塊化底層實現，事件底層實現，模版解析」等。擴展部分通常是一些可異步加載的UI組件，例如：輸入控件、彈出窗、動畫API、文件上傳及預覽、圖表控件、富文本編輯器等。

 

    上面的實現模式，在主流的JS框架(庫)中，有三類選擇：一類是以ExtJS爲表明的大而全的框架(庫)，這類框架雖然功能知足，但每每沒法拆分爲核心部分和擴展部分來加載，所以基本不予考慮；一類是相對輕量的YUI三、Dojo等框架(庫)；一類是近來流行的前端MV*系列Backbone、Ember、Angular，這類在充當核心部分時，還須要組合Underscore、RequireJS，jQuery等第三方庫。

 

    後面兩類能夠知足要求，但我的以爲不是完美的方案，由於在開發實際產品時，將這兩類做爲核心部分時，每每裏面有不少是不須要的，而還有些須要本身來額外補充近來，能夠是本身開發，也能夠集成第三方的實現。而核心部分框架(庫)若是是本身實現，則能夠保證在功能完整的狀況下，很少出其它的東西，加載的JS能夠控制到最小，並且代碼風格也統一。

 

便於擴展

    

    前端代碼與用戶的交互直接相關，而交互的設計變化和不肯定性很是大，現成的第三方實現每每難以直接利用，須要改造。有時改造第三方的框架，先要很是熟悉框架，當這個框架比較複雜時，這樣的工做量和難度就大大加大了。而自實現的框架(庫)則能夠根據須要任意擴展，能夠根據需求制定對應的規範和API。

 

便於統一開發規範

 

    不一樣的JS框架(庫)，調用方式每每也不一樣（模塊化規範，DOM操做API，面向對象語法糖等）。在使用第三方框架(庫)，特別是組合多個第三方框架(庫)時，若是要實現產品代碼書寫規範的一致，須要實現本身代碼來包裝第三方框架(庫)，達到調用接口的書寫風格一致。本身實現的框架(庫)則能夠免去這一步驟。

 

減小升級帶來的風險

 

    有些第三方框架(庫)在版本升級後，API、瀏覽器兼容性支持度、實現理念可能會發生變化。例如：ExtJs3和ExtJs4的差異就很是大，若是產品急於ExtJs3開發，想升級到4幾乎就要作產品重構了，並且ExtJs4再也不支持低版本IE瀏覽器。當組合使用多個框架(庫)時，其中一個升級也可能會引發彼此之間的兼容性問題。還有可能出現引用的框架(庫)在升級前，在產品中沒有出現問題，升級後，由於框架(庫)的理念變化，致使再也不適合在當前產品中使用，不然會出現性能問題。

 

什麼狀況適合使用第三方實現

 

    (1) 非「核心庫、影響到產品集成與結構的部分、經常使用UI組件」

 

    爲了保證性能和擴展的方便，核心包和經常使用的UI組件能夠選擇自實現。由於難以找到一個第三方框架能夠包含全部的核心包所需的功能，這樣核心包就會由多個第三方包組合加上部分的自行實現。在組合第三包時，每每會帶來不少不須要的代碼，這樣就不能保證核心包的精簡。UI組件每每由於須要依賴於一些核心庫(框架)，經常使用的UI組件本身實現，一來是能夠依賴本身的核心庫(框架)，減小大小，一來是這些經常使用UI組件每每會在系統的中大量使用，對頁面的的視覺等待加載時間會有大的影響，或者是有深刻的個性化需求，本身實現量身打造，而且方便擴展。

 

    (2) 複雜的UI組件

     

    複雜的UI組件，例如：富文本編輯器，日曆，動畫效果，圖表等。這些不會影響產品的架構，技術方向和性能，而實現又比較複雜，當產品須要時，能夠選擇合適的第三方實現，經過模塊化方式異步加載。若是有個性化需求，而其又沒有擴展接口，則可嘗試修改其源碼。

 

    (3) 文件小、依賴少、功能單一

 

    不少人會將本身些的一些框架(庫)放到github上開源。像kissy，qwrap等大而全的框架(庫)不多會有人去將其用到本身的產品中，通常是去學習它們的實現理念。而對於SeaJS等只實現單一功能，而且文件小，不依賴其它第三方庫(框架)則大受歡迎，不少公司和我的都在本身的產品中使用。

 

    (4) jQuery

 

    jQuery是個特例，雖然通常只用到了它的DOM操做和ajax相關的API，這種狀況下，要引入一個gzip壓縮後30多K的文件，不算小了。可是jQuery太流行，它的寫法已經成了前端開發事實上的規範，你們都會用它，並且不少第三方UI組件/框架/庫都依賴它。

 

最後的總結

 

    上面提到的問題的性質需具體狀況具體分析，根據應用產品的場景和開發團隊要求，多是大問題，也可能不是問題。若是有一個穩定的前端團隊，而且開發的產品打算長期優化，那麼積累並完善本身的框架(庫)就很是有必要了。當團隊沒有積累，而又有產品開發的進度限制時，能夠根據產品的形態和場景，先選擇成熟的第三方庫（不必定是當前很是流行的），在長期的產品的優化和完善過程當中會不斷髮現問題並解決問題，這個過程能夠逐步來構建和完善本身的框架（庫）。