Google Polymer是前端組件化的未來！那對於現在當下，又該採用什麼技術實現組件化呢？AngularJs可以勝任嗎？

01-05

我想實現，Google Polymer 提的一切皆組件的 web app，
比如知乎的這個頁面，我把每一個紅色圈住的區塊都看做一個當前頁面的組件。

已有的答覆基本都認同。我來總結一下，再補充幾句。

1. 組件化不僅僅意味著UI層的組件化，而是包括業務數據和業務邏輯的綜合考慮，只是由於在有些項目中，後面這塊太薄，導致組件化幾乎只剩UI層的組件化了。

2. 在UI層組件化的實現方式上，Polymer只是其中一種，各框架的實現方式可謂五花八門，Web Components是實現這一層組件化的未來標準，所以Polymer有先天優勢。與它處於同一層面的React也是有不少優勢的。如果只是說要實現題主問的這個問題，那可用的實現方式非常多。

3. 對於 @sapjax答案中提到的：

&> Polymer更強調「組件」的概念，更適用於常規的web頁面開發。而不是像angularJs，ember.js這些似乎更適合開發後台管理界面。

這句結論我同意，但那個組件的含義是表示「UI層組件」。Angular和Ember這類，是在各層面上都做組件化，特別Angular，因為使用了依賴注入，所以每個模塊的組件化程度更好了，它把依賴都隔離出去了，比如邏輯組件的單元測試之類就比較方便。如果從一個較高的視角來管理這些組件的話，會感到非常清晰。

4. 組件化不代表通用化。一套成熟的組件只有在同構系統中才能發揮最大優勢，跟別的任何東西混用都可能大打折扣，在這方面，只針對上層UI做的組件在可復用性方面有較大優勢，從上到下都做的框架一般跟其他系統整合就比較困難。

不同的框架只是用不同的形式封裝組件，組件內部對外是透明的，而 Shadow DOM 只是從系統和標準層面給了開發者另一種封裝形式的選擇。就本問題講，AngularJS 當然可以勝任，就算是 Polymer 從封裝的角度講也不一定就比 AngularJS 好，只不過是用了更先進的技術而已。

大家說的很明白了，只說一句：沒事別瞎折騰，組件化的最大目的是可復用性和團隊開發時候的分工。

如果你的頁面沒有特別大的需求，別想著折騰這些，先把前端工程化和表層面的模塊化和前端團隊的規範化做好再說吧。

普通的web頁面組件化後，如果你的復用很少，基本上的後果就是維護成本陡增，關鍵是並沒有特別大的意義。

做任何事情前，衡量好其成本，其目的，其價值，最後是否能夠達成目的。

AngularJS的確是目前承上啟下比較好的選擇。

工作至今，用過的幾個主要框架，都實現了組件化，不過就是風格、側重點不一樣。但在整個Web開發都在朝HTML5轉向的這個時節點，AngularJS的確是最佳選擇。

先看已有的一些：

Sencha（ExtJS）：超強的組件化框架，基於類的組件，JSON格式模板聲明，對Responsive Design有很好的支持（這點很不容易，大多數框架都是讓你自生自滅），API介面設計精良，要擴展也挺容易的（前提是要學習一下它的widget系統），還有配套開發工具，文檔、社區也不錯。問題就是太貴，適合壕團隊用；API是Java、C#這類後端語言的組件風格，至少UI部分和未來趨勢不一致，但這點不致命，以它的質量，應該生命期還長著。
Dojo：基於類的組件，有HTML模板聲明支持，開發團隊里有一些人也參與在CommonJS里，所以一些API（如text plugin，Defer）已經被添加進CommonJS或者ES規範里。缺點就是實現質量實在太差，文檔也爛，社區不活躍。IBM背書的，大家懂的。
YUI：其實還不錯，但是Yahoo都跑路了……

然後，AngularJS和它們對比，幾個優勢很明顯：

回歸Web本質。上面幾個框架，可能是開發年代關係，都很喜歡以JavaScript的「類」為中心。而「類」其實在JavaScript世界並不重要，尤其是UI方面。這些框架把很多實現都放在JavaScript類裡面，容易導致一些問題，比如常見的Inheritance Hell，在Dojo上很明顯；而且過於強調JavaScript，並不是未來的趨勢。
更加強大的模板語法，而且支持雙向綁定、一次性綁定等等。這個的好處，開發過Flex的人應該知道。
為了未來做好準備。只是個人的粗略感覺，AngularJS的很多地方，雖然不是按照未來規範設計的，但是也很接近，未來遷徙的話，成本不會很大。比如它其實不是AMD的，但是提供了對依賴注入的支持，你將來要改成AMD的也不會太麻煩。

和Polymer相比，AngularJS更加現實。Polymer是基於未來規範的，但我感覺還需要時間去考驗一下。

眾所周知，W3C的東西，也不是一貫正確的，有些方面，微軟的做法才是正道。
工具鏈需要時間去成熟，畢竟WebComponent那套，和現有做法區別還是蠻大的。
有些特性，margin value不是特別大。比如，Shadow DOM的css作用域限制，如果你是用LESS、SASS這類CSS工具的話，其實污染的概率是很小的。而且，有些情況下，這種污染可能是有益的。

組件化不在於用什麼工具，還在於開發者自己對於業務的認知，當然工具一部分程度上可以讓開發者畫狐類虎

實現組件化跟這哥倆沒啥必然關係啊。

使用者拿到組件好用，易用不就行了，裡面是黑盒的，又不在乎用啥技術（特性）什麼的

只要能整出可重用，發布，單獨測試，單獨開發的，符合你業務需求的東東不就好了……

這兩個，一個是橫向解決一個問題，一個是縱向，各有他的應用場景。

polymer,如果粗略的說，比較適合業務模塊比較鬆散的協同合作。

angular, 粗略的說，適合協同緊密的開發團隊。

但是這個說法很粗略，還要看你團隊的需要。

react腦殘粉表示不服

polymer 是基於新的的 webcomponents 規範來實現組件化，我們我們編寫組件變得簡單和高效，但不意味這目前就沒有解決方案了。目前實現組件化的形式，根據業務形態的不同會有很多，贊同@薛端陽的看法，angular 只是實現某種業務形態其中一種手段而已，目前組件化還包含更多恭喜，比如工具。

augustdong/com-browserify · GitHub

現實開發中，組件化真有那麼重要嗎？這個概念在Java服務端已經存在很長時間了，沒看到很成功的組件化產品。去年接觸到一個200多人的大項目也是用AngularJS, 大部分和業務相關的組件都需要重新開發的，甚至比如日曆這一類底層的，開發出來的組件並不能脫離開這個項目平台使用（當然設計上也沒有這個需求）。

個人感覺directive已經可以很好的解決UI端代碼重用的問題，夠用了

目前我做的幾個項目就是按照題主的思路，把頁面分成很多很多塊，單獨開發某個塊的代碼，塊與塊之間是完全獨立的，最後在一個容器頁面中把每個塊組合起來，應用就可以跑起來了~

Transformers (https://github.com/hex-ci/Transformers) 框架就是為題主這個需求而生的。

前端組件化一個是angularjs的directive，一個就是html5的shdow dom，其實很早以前微軟有htc也是做這個的。HTML Components 當然，自己從頭造輪子也可以，我支持你，像你截圖的這個東西用微軟的web part就可以，user control也可以。

ReactJS

目前AngularJS確實是比較好的選擇，我們幾個項目，有移動端App，管理後台等都用它，確實比較方便，開發效率高，維護成本低

對於這個問題我已經有了解決之道……詳細請看：【總結】AngularJs學習總結