React的編程模式其實(shí)不必特別考慮Web標(biāo)準(zhǔn)，它的遷移成本并不算高，甚至由于其實(shí)現(xiàn)機(jī)制，屏蔽了UI層實(shí)現(xiàn)方式，所以大家能看到在native上的使用，canvas上的使用，這都是與基于DOM的編程方式大為不同的，所以對它來說，處理Web Components的兼容問題要在封裝標(biāo)簽的時(shí)候解決，反正之前也是要封裝。

Angular 1.x的版本，可以說是跟同時(shí)代的多數(shù)框架/庫一樣，對未來標(biāo)準(zhǔn)的兼容基本沒有考慮，但是重新規(guī)劃之后的2.0版本對此有了很多權(quán)衡，變成了激進(jìn)變更，突然就變成一個(gè)未來的東西了。

這三個(gè)東西各有千秋，在可以預(yù)見的幾年內(nèi)將會鼎足三分，也許還會有新的框架出現(xiàn)，能不能比這幾個(gè)流行就難說了。

此外，原Angular 2.0的成員Rob Eisenberg創(chuàng)建了自己的新一代框架aurelia，該框架將成為Angular 2.0強(qiáng)有力的競爭者。

前端組件的復(fù)用性

看過了已有的一些東西之后，我們可以大致來討論一下前端組件化的一些理念。假設(shè)我們有了某種底層的組件機(jī)制，先不管它是瀏覽器原生的，或者是某種框架/庫實(shí)現(xiàn)的約定，現(xiàn)在打算用它來做一個(gè)大型的Web應(yīng)用，應(yīng)該怎么做呢?

所謂組件化，核心意義莫過于提取真正有復(fù)用價(jià)值的東西。那怎樣的東西有復(fù)用價(jià)值呢?

控件

基礎(chǔ)邏輯功能

公共樣式

穩(wěn)定的業(yè)務(wù)邏輯

對于控件的可復(fù)用性，基本上是沒有爭議的，因?yàn)檫@是實(shí)實(shí)在在的通用功能，并且比較獨(dú)立。

基礎(chǔ)邏輯功能主要指的是一些與界面無關(guān)的東西，比如underscore這樣的輔助庫，或者一些校驗(yàn)等等純邏輯功能。

公共樣式的復(fù)用性也是比較容易認(rèn)可的，因此也會有bootstrap，foundation，semantic這些東西的流行，不過它們也不是純粹的樣式庫了，也帶有一些小的邏輯封裝。

**后一塊，也就是業(yè)務(wù)邏輯。這一塊的復(fù)用是存在很多爭議的，一方面是，很多人不認(rèn)同業(yè)務(wù)邏輯也需要組件化，另一方面，這塊東西究竟怎樣去組件化，也很需要思考。

除了上面列出的這些之外，還有大量的業(yè)務(wù)界面，這塊東西很顯然復(fù)用價(jià)值很低，基本不存在復(fù)用性，但仍然有很多方案中把它們“組件化”了，使得它們成為了“不具有復(fù)用性的組件”。為什么會出現(xiàn)這種情況呢?

組件化的本質(zhì)目的并不一定是要為了可復(fù)用，而是提升可維護(hù)性。這一點(diǎn)正如面向?qū)ο笳Z言，Java要比C 純粹，因?yàn)樗辉试S例外情況的出現(xiàn)，連main函數(shù)都必須寫到某個(gè)類里，所以Java是純面向?qū)ο笳Z言，而C 不是。

在我們這種情況下，也可以把組件化分為：全組件化，局部組件化。怎么理解這兩個(gè)東西的區(qū)別呢，有人問過js框架和庫的區(qū)別是什么，一般來說，有某種較強(qiáng)約定的東西，稱為框架，而約定比較松散的，稱為庫?？蚣芎芏喽际怯腥M件化理念的，比如說，很多年前就出現(xiàn)的ExtJS，它是全組件化框架，而jQuery和它的插件體系，則是局部組件化。所以用ExtJS寫東西，不管寫什么都是差不多一樣的寫法，而用jQuery的時(shí)候，大部分地方是原始HTML，哪里需要有些不一樣的東西，就只在那個(gè)地方調(diào)用插件做一下特殊化。

對于一個(gè)有一定規(guī)模的Web應(yīng)用來說，把所有東西都“組件化”，在管理上會有較大的便利性。我舉個(gè)例子，同樣是編寫代碼，短代碼明顯比長代碼的可讀性更高，所以很多語言里會建議“一個(gè)方法一般不要超過多少行，一個(gè)類**不要超過多少行”之類。在Web前端這個(gè)體系里，Java這塊是做得相對較好的，現(xiàn)在入門水平的人，也已經(jīng)很少會有把一堆js都寫在一起的了。CSS這塊，**近在SASS，LESS等框架的引領(lǐng)下，也逐步往模塊化方面發(fā)展，否則直接編寫bootstrap那種css，會非常痛苦。

這個(gè)時(shí)候我們再看HTML的部分，如果不考慮模板等技術(shù)的使用，某些界面光布局代碼寫起來就非常多了，像一些表單，都需要一層套一層，很多簡單的表單元素都需要套個(gè)三層左右，更不必說一些有復(fù)雜布局的東西了。尤其是整個(gè)系統(tǒng)單頁化之后，界面的header，footer，各種nav或者aside，很可能都有一定復(fù)雜性。如果這些東西的代碼不作切分，那么主界面的HTML一定比較難看。

我們先不管用什么方式切分了，比如用某種模板，用類似Angular中的include，或者Polymer，React中的標(biāo)簽，或者直接使用原生Web Components，總之是把一塊一塊都拆開了，然后包含進(jìn)來。從這個(gè)角度看，這些拆出去的東西都像組件，但如果從復(fù)用性的角度看，很可能多數(shù)東西，每一塊都只有一個(gè)地方用，壓根沒有復(fù)用度。這個(gè)拆出去，純粹是為了使得整個(gè)工程易于管理，易于維護(hù)。

這時(shí)候我們再來關(guān)注不同框架/庫對UI層組件化的處理方式，發(fā)現(xiàn)有兩個(gè)類型，模板和函數(shù)。

模板是一種很常見的東西，它用HTML字符串的方式表達(dá)界面的原始結(jié)構(gòu)，然后**代入數(shù)據(jù)的方式生成真正的界面，有的是生成目標(biāo)HTML，有的還生成各種事件的自動(dòng)綁定。前者是靜態(tài)模板，后者是動(dòng)態(tài)模板。

另外有一些框架/庫偏愛用函數(shù)邏輯來生成界面，早期的ExtJS，現(xiàn)在的React(它內(nèi)部還是可能使用模板，而且對外提供的是組件創(chuàng)建接口的進(jìn)一步封裝——jsx)等，這種實(shí)現(xiàn)技術(shù)的優(yōu)勢是不同平臺上編程體驗(yàn)一致，甚至可以給每種平臺封裝相同的組件，調(diào)用方**寫一份代碼，在Web和不同Native平臺上可用。但這種方式也有比較麻煩的地方，那就是界面調(diào)整比較繁瑣。

希望以上對你將要學(xué)習(xí)HTM5或即將從事HTML5的你有所幫助!