<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                # 模塊系統 ## 現狀 當今越來越多的網站已經從網頁模式進化到了 Webapp 模式,它們運行在現代的高級瀏覽器里,使用 HTML5、 CSS3、 ES6 等更新的技術來開發豐富的功能,網頁已經不僅僅是完成瀏覽的基本需求,并且webapp通常是一個單頁面應用,每一個視圖通過異步的方式加載,這導致頁面初始化和使用過程中會加載越來越多的 JavaScript 代碼,這給前端開發的流程和資源組織帶來了巨大的挑戰。 前端開發和其他開發工作的主要區別,首先是前端是基于多語言、多層次的編碼和組織工作,其次前端產品的交付是基于瀏覽器,這些資源是通過增量加載的方式運行到瀏覽器端,如何在開發環境組織好這些碎片化的代碼和資源,并且保證它們在瀏覽器端快速、優雅的加載和更新,就需要一個**模塊化系統**,這個理想中的模塊化系統是前端工程師多年來一直探索的難題。 * * * * * ## 模塊系統的演進 **模塊系統主要解決模塊的定義、依賴和導出。** ### 1.`<script>`標簽 ~~~html <script src="module1.js"></script> <script src="module2.js"></script> <script src="libraryA.js"></script> <script src="module3.js"></script> ~~~ 這是最原始的 JavaScript 文件加載方式,如果把每一個文件看做是一個模塊,那么他們的接口通常是暴露在全局作用域下,也就是定義在 window 對象中,不同模塊的接口調用都是一個作用域中,一些復雜的框架,會使用命名空間的概念來組織這些模塊的接口,典型的例子如 YUI 庫。 這種原始的加載方式暴露了一些顯而易見的弊端: * 全局作用域下容易造成變量沖突 * 文件只能按照 `<script>` 的書寫順序進行加載 * 開發人員必須主觀解決模塊和代碼庫的依賴關系 * 在大型項目中各種資源難以管理,長期積累的問題導致代碼庫混亂不堪 ### 2. CommonJS 服務器端的 Node.js 遵循 CommonJS規范,該規范的核心思想是允許模塊通過 require 方法來同步加載所要依賴的其他模塊,然后通過 exports 或 module.exports 來導出需要暴露的接口。 ~~~javascript require("module"); require("../file.js"); exports.doStuff = function() {}; module.exports = someValue; ~~~ **優點:** * 服務器端模塊便于重用 * NPM 中已經有將近20萬個可以使用模塊包 * 簡單并容易使用 **缺點:** * 同步的模塊加載方式不適合在瀏覽器環境中,同步意味著阻塞加載,瀏覽器資源是異步加載的 * 不能非阻塞的并行加載多個模塊 **實現:** * 服務器端的 Node.js * Browserify,瀏覽器端的 CommonJS 實現,可以使用 NPM 的模塊,但是編譯打包后的文件體積可能很大 * modules-webmake,類似Browserify,還不如 Browserify 靈活 * wreq,Browserify 的前身 ### 3. AMD Asynchronous Module Definition 規范其實只有一個主要接口` define(id?, dependencies?, factory)`,它要在聲明模塊的時候指定所有的依賴 dependencies,并且還要當做形參傳到 factory 中,對于依賴的模塊提前執行,依賴前置。 ~~~javascript define("module", ["dep1", "dep2"], function(d1, d2) { return someExportedValue; }); require(["module", "../file"], function(module, file) { /* ... */ }); ~~~ **優點:** * 適合在瀏覽器環境中異步加載模塊 * 可以并行加載多個模塊 **缺點:** * 提高了開發成本,代碼的閱讀和書寫比較困難,模塊定義方式的語義不順暢 * 不符合通用的模塊化思維方式,是一種妥協的實現 **實現:** * RequireJS * curl ### 4. CMD Common Module Definition 規范和 AMD 很相似,盡量保持簡單,并與 CommonJS 和 Node.js 的 Modules 規范保持了很大的兼容性。 ~~~javascript define(function(require, exports, module) { var $ = require('jquery'); var Spinning = require('./spinning'); exports.doSomething = ... module.exports = ... }) ~~~ **優點:** * 依賴就近,延遲執行 * 可以很容易在 Node.js 中運行 **缺點:** * 依賴 SPM 打包,模塊的加載邏輯偏重 **實現:** * Sea.js * coolie ### 5. UMD Universal Module Definition 規范類似于兼容 CommonJS 和 AMD 的語法糖,是模塊定義的跨平臺解決方案。 ### 6. ES6 模塊 ECMAScript6 標準增加了 JavaScript 語言層面的模塊體系定義。ES6 模塊的設計思想,是盡量的靜態化,使得編譯時就能確定模塊的依賴關系,以及輸入和輸出的變量。CommonJS 和 AMD 模塊,都只能在運行時確定這些東西。 ~~~javascript import "jquery"; export function doStuff() {} module "localModule" {} ~~~ **優點:** * 容易進行靜態分析 * 面向未來的 ECMAScript 標準 **缺點:** * 原生瀏覽器端還沒有實現該標準 * 全新的命令字,新版的 Node.js才支持 **實現:** * Babel * * * * * ## 期望的模塊系統 可以兼容多種模塊風格,盡量可以利用已有的代碼,不僅僅只是 JavaScript 模塊化,還有 CSS、圖片、字體等資源也需要模塊化。 ### 1. 前端模塊加載 前端模塊要在客戶端中執行,所以它們需要增量加載到瀏覽器中。 模塊的加載和傳輸,我們首先能想到兩種極端的方式,一種是每個模塊文件都單獨請求,另一種是把所有模塊打包成一個文件然后只請求一次。顯而易見,每個模塊都發起單獨的請求造成了請求次數過多,導致應用啟動速度慢;一次請求加載所有模塊導致流量浪費、初始化過程慢。這兩種方式都不是好的解決方案,它們過于簡單粗暴。 **分塊傳輸,按需進行懶加載**,在實際用到某些模塊的時候再增量更新,才是較為合理的模塊加載方案。 要實現模塊的按需加載,就需要一個對整個代碼庫中的模塊進行靜態分析、編譯打包的過程。 ### 2. 所有資源都是模塊 在上面的分析過程中,我們提到的模塊僅僅是指JavaScript模塊文件。然而,在前端開發過程中還涉及到樣式、圖片、字體、HTML 模板等等眾多的資源。這些資源還會以各種方言的形式存在,比如 coffeescript、 less、 sass、眾多的模板庫、多語言系統(i18n)等等。 如果他們都可以視作模塊,并且都可以通過require的方式來加載,將帶來優雅的開發體驗,比如: ~~~javascript require("./style.css"); require("./style.less"); require("./template.jade"); require("./image.png"); ~~~ 那么如何做到讓 require 能加載各種資源呢? ### 3. 靜態分析 在編譯的時候,要對整個代碼進行靜態分析,分析出各個模塊的類型和它們依賴關系,然后將不同類型的模塊提交給適配的加載器來處理。比如一個用 LESS 寫的樣式模塊,可以先用 LESS 加載器將它轉成一個CSS 模塊,在通過 CSS 模塊把他插入到頁面的 `<style> `標簽中執行。 Webpack 就是在這樣的需求中應運而生。 同時,為了能利用已經存在的各種框架、庫和已經寫好的文件,我們還需要一個模塊加載的兼容策略,來避免重寫所有的模塊。 * * * * * # Wepack概述 ![Markdown](http://i4.buimg.com/594495/55f9efa010206d3f.png) Webpack 是當下最熱門的前端資源模塊化管理和打包工具。它可以將許多松散的模塊按照依賴和規則打包成符合生產環境部署的前端資源。還可以將按需加載的模塊進行代碼分隔,等到實際需要的時候再異步加載。通過 loader 的轉換,任何形式的資源都可以視作模塊,比如 CommonJs 模塊、 AMD 模塊、 ES6 模塊、CSS、圖片、 JSON、Coffeescript、 LESS 等。 簡單來說,Webpack 就是一個模塊打包器。它將根據模塊的依賴關系進行靜態分析,然后將這些模塊按照指定的規則生成對應的靜態資源。 ## Webpack 的特點 ### 1.代碼拆分 Webpack 有兩種組織模塊依賴的方式,同步和異步。異步依賴作為分割點,形成一個新的塊。在優化了依賴樹后,每一個異步區塊都作為一個文件被打包。 ### 2.Loader Webpack 本身只能處理原生的 JavaScript 模塊,但是 loader 轉換器可以將各種類型的資源轉換成 JavaScript 模塊。這樣,任何資源都可以成為 Webpack 可以處理的模塊。 ### 3.智能解析 Webpack 有一個智能解析器,幾乎可以處理任何第三方庫,無論它們的模塊形式是 CommonJS、 AMD 還是普通的 JS 文件。甚至在加載依賴的時候,允許使用動態表達式 `require("./templates/" + name + ".jade")。` ### 4.插件系統 Webpack 還有一個功能豐富的插件系統。大多數內容功能都是基于這個插件系統運行的,還可以開發和使用開源的 Webpack 插件,來滿足各式各樣的需求。 ### 5.快速運行 Webpack 使用異步 I/O 和多級緩存提高運行效率,這使得 Webpack 能夠以令人難以置信的速度快速增量編譯。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看