寫了十年JS卻不知道模塊化為何物？

模塊化這個(gè)問題并非一開始就存在，WWW剛剛問世的時(shí)候，html，JavaScript，CSS（JS和CSS都是后來在網(wǎng)景被引進(jìn)瀏覽器的）都是極其簡單的存在，不需要模塊化。

模塊化的需求是規(guī)模的產(chǎn)物，當(dāng)web page進(jìn)化到web application，瀏覽器端處理的邏輯越來越復(fù)雜，展現(xiàn)的樣式和動(dòng)畫越來多，對(duì)于工程的要求也就越來越高。于是模塊化的需求也就產(chǎn)生了。模塊化的意義：

• 組件的復(fù)用，降低開發(fā)成本和維護(hù)成本
• 組件單獨(dú)開發(fā)，方便分工合作
• 模塊化遵循標(biāo)準(zhǔn)，方便自動(dòng)化依賴管理，代碼優(yōu)化，部署

JavaScript長久以來被認(rèn)為是簡單的腳本語言，實(shí)際上情況早就發(fā)生來變化，在最新版的JavaScript是通用編程語言而不是腳本語言。腳本語言，比如shell并不是用來完成復(fù)雜功能的，只是用來做一些自動(dòng)化控制，是不需要模塊化的。而用于構(gòu)建復(fù)雜系統(tǒng)通用編程語言（比如Java）一般都有模塊的實(shí)現(xiàn)。

1.模塊化標(biāo)準(zhǔn)

ES6之前，JavaScript并沒有原生的模塊機(jī)制，好在JavaScript非常靈活，有很多種寫法可以將代碼天然隔離，起到模塊化的功能：

//define

var  modules  =  {}??

modules.mod1  =  {??

??foo  :  function(){...},

??bar  :  function(){...}

??...

}     //歡迎加入前端全棧開發(fā)交流圈一起學(xué)習(xí)交流：1007317281

//call

modules.mod1.foo()

在客戶端這種方式基本是夠用的，然而問題依然存在：你無法管理依賴，所有的代碼都必須load到內(nèi)存中，需要哪些模塊必須由人工處理。分模塊是工程化的產(chǎn)物，也是自然發(fā)展的結(jié)果，自然有很多嘗試。很顯然，模塊之間互相依賴需要編寫模塊的時(shí)候遵循一定的規(guī)范。現(xiàn)存的規(guī)范還真不少，不知道ES6 能否終結(jié)這場混戰(zhàn)：

• AMD
• CMD
• closure
• CommonJS
• ES6

AMD和CMD分別是requireJS和seaJS定義的標(biāo)準(zhǔn)。使用純?cè)腅S5語法意味者其只能使用閉包，書寫和閱讀都很怪異。值得一提的是AngularJS也使用類似的方式，以至于Angular的作者們都受不了，決定在AngularJS 2 使用新的語言AtScript，前端輪子太多，又造了一個(gè)，好在這個(gè)輪子造的比較好，兼容ES6 TypeScript規(guī)范，扯的遠(yuǎn)了，看看AMD長得啥樣：

AMD:

define(['./a',  './b'],  function(a,  b)  {??

??...

})

Closure是google出品的前端工具，Closure提供了一系列工具和庫，谷歌自己的多個(gè)項(xiàng)目都是使用Closure開發(fā)的。closure compiler通過模塊間依賴的聲明把所有被依賴的文件打包到一起，而且Closure的一大優(yōu)勢(shì)是如果采用破壞性壓縮（ADVANCED）壓縮率極高。

//文件A

goog.provide('module1')??

com.foo.bar  =  {??

 ...

}     //歡迎加入前端全棧開發(fā)交流圈一起學(xué)習(xí)交流：1007317281

//文件B

goog.require('module1')??

var  a  =  com.foo.bar;

然而Closure并不完美，不同的文件共享同一個(gè)全局對(duì)象，所以你不得不這樣寫 a.b.c=...。

CommonJS是Node.js使用的模塊化標(biāo)準(zhǔn)。Node.js對(duì)于前端開發(fā)者來說不僅僅可以提供一個(gè)Server，還是一個(gè)完美的開發(fā)平臺(tái)，在Node上使用Grunt/gulp構(gòu)建web項(xiàng)目是件很爽的事情。Node的模塊化聲明的方式與Closure類似，只是更進(jìn)一步，天然隔離了命名空間。上面的代碼如果使用CommonJS的模塊化規(guī)范可以這么寫

//文件A

module.exports  =  {...}??

//文件B

var  a  =  require('./foo/bar')

browserify讓使用CommonJS模塊化規(guī)范的代碼可以運(yùn)行在客戶端上。

2.靜態(tài)加載與動(dòng)態(tài)加載

在看ES6之前我們先看模塊加載的兩種方式：

• 靜態(tài)加載:在編譯階段進(jìn)行,把所有需要的依賴打包到一個(gè)文件中
• 動(dòng)態(tài)加載:在運(yùn)行時(shí)加載依賴

AMD標(biāo)準(zhǔn)是動(dòng)態(tài)加載的代表，而CommonJS是靜態(tài)加載的代表。AMD的目的是用在瀏覽器上，所以是異步加載的。而NodeJS是運(yùn)行在服務(wù)器上的，同步加載的方式顯然更容易被人接收，所以使用了CommonJS。同樣的道理，如果靜態(tài)加載，那就使用同步的加載方式，如果動(dòng)態(tài)加載就必須用異步的加載方式。

那么ES6采用何種加載機(jī)制？

ES6既希望用簡單的聲明方式來完成靜態(tài)加載，又不愿放棄動(dòng)態(tài)加載的特性，而這兩種方式幾乎不可能簡單的同時(shí)實(shí)現(xiàn)，所以ES6提供了兩種獨(dú)立的模塊加載方法。

2.1 聲明的方式

import  {foo}  from module1

2.2 通過System.import API的方式

System.import('some_module')??

????.then(some_module  =>  {

????????// Use some_module

????})

????.catch(error  =>  {

????????...

????});           //歡迎加入前端全棧開發(fā)交流圈一起學(xué)習(xí)交流：1007317281

再看下export的語法，與CommonJS很像，只不過沒有了module這個(gè)對(duì)象，而直接調(diào)用export。 可以export任何一個(gè) 函數(shù)，變量，對(duì)象

//expt.js

export function  abc(){}//export 一個(gè)命名的function??

export default  function(){}  //export default function??

export num=123  //export 一個(gè)數(shù)值??

export obj={}??

export  {  obj as  default  };

//import

import expt from  'expt'//default export??

import  {default  as  myModule}  from  'expt'  //rename??

import  {abc,num,obj}  from  'expt'

目前來看，使用預(yù)編譯的方式顯然要好于使用動(dòng)態(tài)加載，瀏覽器對(duì)ES6語法支持還很差，如果使用動(dòng)態(tài)加載ES6，在瀏覽器端要做ES6到ES5的翻譯工作，這個(gè)顯然是重復(fù)低效的。但是隨著瀏覽器對(duì)ES6支持增強(qiáng)，尤其是瀏覽器實(shí)現(xiàn)了動(dòng)態(tài)加載API后，動(dòng)態(tài)加載的優(yōu)勢(shì)就會(huì)展現(xiàn)：

• 更流暢的用戶體驗(yàn)，動(dòng)態(tài)加載可以實(shí)現(xiàn)類似lazyload的加載方式，將download的時(shí)間分散
• 更簡潔的項(xiàng)目，無需預(yù)編譯，項(xiàng)目可以少配置很多工具
• HTTP/2的普及更傾向于使用多個(gè)小的請(qǐng)求，適合動(dòng)態(tài)加載

3.實(shí)踐

如果現(xiàn)在使用ES6，可以選擇動(dòng)態(tài)加載模塊system.js 或者browserify的預(yù)編譯方法。

使用system.js+babel動(dòng)態(tài)加載依賴。system.js 是ES6動(dòng)態(tài)模塊加載的一個(gè)實(shí)現(xiàn)。寫了一個(gè)小DEMO：

項(xiàng)目初始化

bower install babel system.js  --save
index.html
????<script src="/bower_components/system.js/dist/system.js"></script>

????<script>

??????System.config({

??????????baseURL  :  "/scripts",

??????????transpiler  :  'babel',

??????????map  :  {

????????????babel:'/bower_components/babel/browser.js'

??????????}

????????}             //歡迎加入前端全棧開發(fā)交流圈一起學(xué)習(xí)交流：1007317281

??????)

??????System.import('main.js').then(function(m){

????????m.default.sayHello()

??????})

????</script>
main.js

export  default  {??

??sayHello  :  function(){

????console.log('hello')

??}

}

使用gulp+browserify+babel預(yù)編譯。gulp是一個(gè)Node.js平臺(tái)上的任務(wù)管理平臺(tái)。預(yù)編譯要做很多配置，非常繁瑣，推薦使用yeoman來生成項(xiàng)目骨架。比如使用generator-es6-webapp。

生成非常簡單,在項(xiàng)目目錄中執(zhí)行

yo es6-webapp

缺少依賴的化安裝依賴就好。

4.其他，關(guān)于前端化趨勢(shì)

ES6模塊化意味著什么？

更強(qiáng)大的前端，Web技術(shù)整體前移。HTML5的發(fā)展和某些優(yōu)秀瀏覽器的支持讓web技術(shù)整體前移，以前像渲染這種工作在后端進(jìn)行是由于瀏覽器薄弱，且有老IE這種拖后腿搗亂的選手。

簡化編程模型，人工管理JS依賴和將多個(gè)JS打包這種工作可以不需要了，而配合WebComponents標(biāo)準(zhǔn)，開發(fā)Web將不再借助模板引擎和預(yù)編譯引擎。

前端化還有更深遠(yuǎn)的影響--在過去瀏覽器是個(gè)工具，現(xiàn)在瀏覽器是個(gè)重要的工具，在未來瀏覽器就是用戶唯一的操作系統(tǒng)。

感謝您的觀看，如有不足之處，歡迎批評(píng)指正。
**獲取前端資料