㈠ 怎么看待前端 组件化 开源 知乎
前端相对后端又有点后台化，因为既要懂得网站前台的事情又要懂得后台代码的事情！
㈡ 如何通过 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都是后端动态生成的
后端开发还得基于前端来做
组件化开发可以减少页面开发成本 提高页面的可维护性和拓展性