前端對框架(庫)的大小更敏感 前端內容的渲染和交互效果的實現如果依賴JS框架(庫)，需要先將這些框架(庫)下載到客戶端，此時框架(庫)的大小將直接影響到前端的首屏渲染速度。框架(庫)越小，加載的速度就越快，而隨著功能的越來越全，框架(庫)必然會越來越大，要保證性能，需要制定加載策略。 便于制定加載策略 解決框架(庫)變大的常見加載策略是將框架分為核心部分和擴展部分，核心部分在首屏渲染前必須下載完成，并且這部分的加載文件盡可能的少和小，擴展部分則可以模塊化方式來懶加載。 核心部分的JS在發布時，可對文件合并，數量盡可能少，單個文件在gzip壓縮后最好不要超過20K。核心部分可以是實現“JS語言擴展(面向對象)，DOM操作API，數據交互方法(ajax)，導航策略，模塊化底層實現，事件底層實現，模版解析”等。擴展部分一般是一些可異步加載的UI組件，例如：輸入控件、彈出窗、動畫API、文件上傳及預覽、圖表控件、富文本編輯器等。 上面的實現模式，在主流的JS框架(庫)中，有三類選擇：一類是以ExtJS為代表的大而全的框架(庫)，這類框架雖然功能滿足，但往往無法拆分為核心部分和擴展部分來加載，因此基本不予考慮；一類是相對輕量的YUI3、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組件/框架/庫都依賴它。 最后的總結 上面提到的問題的性質需具體情況具體分析，根據應用產品的場景和開發團隊要求，可能是大問題，也可能不是問題。如果有一個穩定的前端團隊，并且開發的產品打算長期優化，那么積累并完善自己的框架(庫)就非常有必要了。當團隊沒有積累，而又有產品開發的進度限制時，可以根據產品的形態和場景，先選擇成熟的第三方庫（不一定是當前非常流行的），在長期的產品的優化和完善過程中會不斷發現問題并解決問題，這個過程可以逐步來構建和完善自己的框架（庫）。

?

轉載于:https://www.cnblogs.com/littlehb/p/3867140.html

總結

以上是生活随笔為你收集整理的为什么需要自己实现前端框架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。