㈠ 怎麼看待前端 組件化 開源 知乎
前端相對後端又有點後台化，因為既要懂得網站前台的事情又要懂得後台代碼的事情！
㈡ 如何通過 Vue+Webpack 來做通用的前端組件化架構設計
angular:
我覺得angularjs的學習上手周期比較長，可能遇到問題，都無法立刻解決，而且編碼的質量明顯的很差，如果團隊沒有制定規范，那寫出來的代碼就沒法看。對於一個選用angularjs的團隊來說，我認為編碼規范是很重要的，否則對編碼能力是沒有提升的。
avalon:
avalonjs文檔資料沒有那麼全，我感覺一些開源支持的力量不夠多。不過，如果有項目需求，需要去做IE瀏覽器的支持話，我建議選擇avalonjs
vue：
vuejs 文檔比較齊全，vue吸取了angularjs
的一些優點，規避了一些缺點，至少編碼規范上有了一個質的飛躍，學習上手的周期比較短。vue起初只是一個輕量級的類庫，用來做類似於react的事情，
同時vue也是可以拿來做前端架構設計的，比如：vueify + vue-router （spa框架）。
vue學習地址：http://cn.vuejs.org/
以上說了那麼多沒用的，下面就來點幹活了！
我的前端組件化架構設計，目錄如下：
項目架構用到的知識點，還是挺多的，知識清單如下：
［1］： gulp + webpack 構建打包工具， 使用了一系列的loader，比如：vue-loader, sass-loader, babel-loader , 以及 postcss，postcss-custom-properties，等等
[2] : postcss-custom-properties : 用來做樣式全局化， 只需要通過變數去維護，通過編譯變數既可以換膚。
[3] : vue-loader （vue文件組件化）：用來去編譯處理 *.vue 的文件，一個vue 文件就是一個單獨的組件，vue組件開發具有高獨立且易維護。組件的劃分可大可小，一個頁面也可以看作成由多個vue 組件構成的，一個頁面也可以是一個vue組件， vue 文件結構如下：
[4] ： babel-loader ：實現對vue文件中 es6 語法的編譯解析
[5] ： vue-router ：用來做路由分發，而且文檔非常的齊全（學習地址：http://vuejs.github.io/vue-router/zh-cn/index.html）。
[6] ： vue （插件式方式）：vue本身提供了一個install 方式用來注入，我們可以注入一些全局的（屬性、方法、以及通用的ui組件）。
下面說說文件夾的含義：
common 文件夾： 是用來存一些通用的東西，比如樣式，以及全局的js等等
components 文件夾：用來放獨立的組件，我打算後期做細分，ui 組件，以及page 組件等等，這裡面就是團隊的心血，以後就能做成獨立的組件庫了。
filters 文件夾：用來放通用的過濾器操作。
plugins 文件夾：用來放 Vue.use 注入到Vue全局的插件庫，比如：請求載入、彈框、分頁、ui組件 等等。plugins 只是把 componets 組件暴露給 Vue全局。
views 文件夾： 用來存放頁面模塊
app.vue 文件：第一次啟動的主程序模塊
app.js 文件：啟動前的載入，注入，實例化
router.config.js 文件：路由模塊
目前該架構在前後台的SPA架構都適用，可能還是有很多不完善，不過我還很年輕，vue也還狠年輕，望各位道友多給我們年輕人一些機會。
㈢ 前端怎麼進行組件化的開發，以及如何解決組件之間依賴
可以用webpack，目前最火的前端構建工具。只要載入loader，你想引用什麼模塊就引用什麼模塊。現在用的就是webpack+react，組件化太方便了。更多問題可以去php中文網問答社區提問
㈣ 在前端中什麼是組件化 什麼是模塊化
模塊化更一種開發規范，比如cmd amd 是為了更好的解藕，比如一個網站，按照不同的模塊來開發，比如你有個評論區，a 項目有，b 項目有，如果僅是單純的模塊開發，這個js 文件你就可以單獨來回引用，
更比如 ，一個頁面 分好多個功能， 這時候你要是都寫在一個js 中 會越來越大，
而你把他分成不同的模塊，
比如評論是一塊
分頁又是一塊，
已經上線，或你不做了，後期別人拉手，或你接手別人的項目， 這時候來個需求讓你把分頁去掉，或修改 你可以清楚的找到對應模塊文件 進行修改 或去掉
模塊是自定義的，
組件，更想當於一個通用的東西，有的分功能組件，有的分業務組件
大圖切換，這種就是單純的一個效果展示，只要調用就ok
一個分頁，也是只單純的調用，
組件更是一個多處都可以使用 ，不需要再單獨開發的
㈤ UI組件化極大提高了工作效率嗎
ui組件化提高了工作效率？答案毋庸置疑、是！web前端是距離用戶最近的工程師、關於這一點我也應該有更多的發言權。現在團隊內部、大部分都是基於antd來開發小二後台等內部系統、效率的提升也得益於此。當然antd不僅僅只做到了ui組件化這么簡單、它更多的優勢是在ui基礎上做了基礎邏輯的封裝、這使得它的適用性進一步擴大。
當然、ui組件化還有一個表現在於對sketch、ps等的自動解析並生成頁面的能力、這在大廠中也作為一個提效的策略被廣泛推薦、常見的如schema2form等ui轉換能力。通過自動解析、甚至演算法識別的能力、可以將一些視覺側和交互側的基礎能力封裝、沉澱、並真正意義上做到ui組件化。而這對效率的提升也是水到渠成的。
㈥ 如何理解前端模塊化
前端模塊化
在JavaScript發展初期就是為了實現簡單的頁面交互邏輯，寥寥數語即可；如今CPU、瀏覽器性能得到了極大的提升，很多頁面邏輯遷移到了客戶端（表單驗證等），隨著web2.0時代的到來，Ajax技術得到廣泛應用，jQuery等前端庫層出不窮，前端代碼日益膨脹
這時候JavaScript作為嵌入式的腳本語言的定位動搖了，JavaScript卻沒有為組織代碼提供任何明顯幫助，甚至沒有類的概念，更不用說模塊（mole）了，JavaScript極其簡單的代碼組織規范不足以駕馭如此龐大規模的代碼
模塊
既然JavaScript不能handle如此大規模的代碼，我們可以借鑒一下其它語言是怎麼處理大規模程序設計的，在Java中有一個重要帶概念——package，邏輯上相關的代碼組織到同一個包內，包內是一個相對獨立的王國，不用擔心命名沖突什麼的，那麼外部如果使用呢？直接import對應的package即可
import java.util.ArrayList;
遺憾的是JavaScript在設計時定位原因，沒有提供類似的功能，開發者需要模擬出類似的功能，來隔離、組織復雜的JavaScript代碼，我們稱為模塊化。
一個模塊就是實現特定功能的文件，有了模塊，我們就可以更方便地使用別人的代碼，想要什麼功能，就載入什麼模塊。模塊開發需要遵循一定的規范，各行其是就都亂套了
規范形成的過程是痛苦的，前端的先驅在刀耕火種、茹毛飲血的階段開始，發展到現在初具規模，簡單了解一下這段不凡的歷程
函數封裝
我們在講函數的時候提到，函數一個功能就是實現特定邏輯的一組語句打包，而且JavaScript的作用域就是基於函數的，所以把函數作為模塊化的第一步是很自然的事情，在一個文件裡面編寫幾個相關函數就是最開始的模塊了
function fn1(){
statement
}
function fn2(){
statement
}
這樣在需要的以後夾在函數所在文件，調用函數就可以了
這種做法的缺點很明顯：污染了全局變數，無法保證不與其他模塊發生變數名沖突，而且模塊成員之間沒什麼關系。
對象
為了解決上面問題，對象的寫法應運而生，可以把所有的模塊成員封裝在一個對象中
var myMole = {
var1: 1,
var2: 2,
fn1: function(){
},
fn2: function(){
}
}
這樣我們在希望調用模塊的時候引用對應文件，然後
myMole.fn2();
這樣避免了變數污染，只要保證模塊名唯一即可，同時同一模塊內的成員也有了關系
看似不錯的解決方案，但是也有缺陷，外部可以隨意修改內部成員
myModel.var1 = 100;
這樣就會產生意外的安全問題
立即執行函數
可以通過立即執行函數，來達到隱藏細節的目的
var myMole = (function(){
var var1 = 1;
var var2 = 2;
function fn1(){
}
function fn2(){
}
return {
fn1: fn1,
fn2: fn2
};
})();
這樣在模塊外部無法修改我們沒有暴露出來的變數、函數
上述做法就是我們模塊化的基礎，目前，通行的JavaScript模塊規范主要有兩種：CommonJS和AMD
CommonJS
我們先從CommonJS談起，因為在網頁端沒有模塊化編程只是頁面JavaScript邏輯復雜，但也可以工作下去，在伺服器端卻一定要有模塊，所以雖然JavaScript在web端發展這么多年，第一個流行的模塊化規范卻由伺服器端的JavaScript應用帶來，CommonJS規范是由NodeJS發揚光大，這標志著JavaScript模塊化編程正式登上舞台。
定義模塊
根據CommonJS規范，一個單獨的文件就是一個模塊。每一個模塊都是一個單獨的作用域，也就是說，在該模塊內部定義的變數，無法被其他模塊讀取，除非定義為global對象的屬性
模塊輸出：
模塊只有一個出口，mole.exports對象，我們需要把模塊希望輸出的內容放入該對象
載入模塊：
載入模塊使用require方法，該方法讀取一個文件並執行，返迴文件內部的mole.exports對象
㈦ 什麼叫組件化開發
張克軍 提出的「組件化就是函數式界面開發」這一說法我是難以接受的，函數式界面開發就讓它好好地叫「函數式組件化」吧，不然我們會在所謂的「傳統UI框架」和「函數式界面開發」之間出現一個Gap，豈不是又要造個詞給填上，多累……
我前面說會有一個Gap，這個Gap很可能就是我們現在想用「組件化」這個定義去表達的一些點，我想在此做一些個人的見解
我將之理解為以下幾要素：
組件是對邏輯的封裝，不限於圖形元素。即我們可以把if做成組件、把一個倒計時做成組件、把一段動畫做成組件、把路由做成組件、把數據架構做成組件，而這些並不能稱為控制項
組件具備單個可移植性，即「隨載入隨用」，不需要為其准備復雜的基礎條件（如引入樣式、引入框架等）。然而這一點現有那些所謂組件庫做得並不好，技術上也不大現實
組件是聲明式定義的，而非命令式。這個不想多說，很大程度上是自己主觀的一個想法
而上面最重要的就是第一點，所以要問我什麼是「組件化開發」，我的說法是：
把圖形、非圖形的各種邏輯均抽象為一個統一的概念（組件）來實現開發的模式
這與傳統開發框架的最大區別就是統一了圖形元素與非圖形元素，除此之外我再想不出其它真正體現區別的點了
在這個概念下，包括router、ajax、mole loader、timer、animation、interval等，都是組件，共享統一的生命周期管理和對外介面，且都是聲明式地進行組合
我的一位同事告訴我去年的深JS上，有位淘寶的朋友的話題叫做「前端組件服務化」，這裡面提的那些個概念，是很符合我對「組件化」的認識的，他要是不給再強安個「服務化」的噱頭就好了- -
不過話說回來，在這個要求之下，組件其實不是那麼好進行抽象設計的，隨便說幾個例子，有難的也有簡單的：
非圖形元素的各種需求如何統一介面，如timer和ajax
組件可以橫向組件，但是縱向復用如何解決，如希望任何圖形元素都可以實現被滑鼠拖拽的效果，則滑鼠拖拽應該也是個組件，這個組件與其它組件的關系是什麼
有些組件對其可被組合的組件是有要求的，比如HTML里就不大好意思把一個<p>放進一個<span>里，這一點如何在組件上表達（實現不難，表達比較難）
一些我們原本想當然認為純的小函數的東西，是不是也能當組件玩，比如underscore.pick要不要也是個組件
㈧ 如何在不使用前端框架的情況下嘗試組件化開發
一個組件包括三個內容！
組件的結構（html）、組件的表現（css）、組件的行為（javascript）；
在你引入其中一個的時候，順帶將其他部分引入就可以了，
不過還有一個問題，就是作用於，css和js如果不限定作用於的話，會影響到其他組件，這些在很多blog裡面有說明的，詳細請 https://segmentfault.com 等網站查找吧
㈨ 既然html都是由後端動態生成，為什麼前端還要強調組件化開發
誰告訴你html都是後端動態生成的
後端開發還得基於前端來做
組件化開發可以減少頁面開發成本 提高頁面的可維護性和拓展性