Component，中文称为组件，或者构件。使用非常比较广泛，它的核心意义在于复用，相对模块，对于依赖性有更高的要求。
Module, 中文为模块或模组。它的核心意义是分离职责，属于代码级模块化的产出。它本身是提供服务的功能逻辑，是一组具有一定内聚性代码的组合，职责明确。
组件(Component)和模块(Module)又是一对容易混淆的名词，也常常被用来相互替换。个人总结，从设计上来看，组件强调复用，模块强调职责(内聚、分离)，或者说组件是达到可复用要求的模块（记得有次面试的时候，面试官都搞错了这两个概念！）。
前端Web应用中的组件，是指一些设计为通用性的，用来构建较大型应用程序的软件，这些组件有多种表现形式。它可以是有UI（用户界面）的，也可以是作为 “服务”的纯逻辑代码。因为有视觉上的表现形式，UI组件更容易理解。UI组件简单的例子包括按钮、输入框和文本域。不论是汉堡包状的菜单按钮（无论你是否喜欢）、标签页、日历、选项菜单或者所见即所得的富文本编辑器则是一些更加高级的例子。提供服务类型的组件可能会让人难以理解，这种类型的例子包括跨浏览器的AJAX支持，日志记录或者提供某种数据持久化的功能。
基于组件开发，最重要的就是组件可以用来构成其他组件，而富文本编辑器就是个很好的例子。它是由按钮、下拉菜单和一些可视化组件等组成。另一个例子是HTML5上的video元素。它同样包含按钮，也同时含有一个能从视频数据流渲染内容的元素。

为什么要构建组件？

高内聚

我们将相关的一些功能组织在一起，把一切封装起来，而在组件的例子中，就可能是相关的功能逻辑和静态资源：JavaScript、HTML、CSS以及图像等。这就是我们所说的内聚。这种做法将让组件更容易维护，并且这么做之后，组件的可靠性也将提高。同时，它也能让组件的功能明确，增大组件重用的可能性。

可重用

你看到的示例组件，尤其是Web Component，更关心可重用的问题。功能明确，实现清晰，API易于理解。自然就能促进组件复用。通过构建可重用组件，我们不仅保持了 DRY（不要重复造轮子）原则，还得到了相应的好处。
这里要提醒： 不要过分尝试构建可重用组件。你更应该关注应用程序上所需要的那些特定部分。如果之后相应需求出现，或者组件的确到了可重用的地步，就花一点额外时间让组件重用。事实上，开发者都喜欢去创造可重用功能块（库、组件、模块、插件等），做得太早将会让你后来痛苦不堪。所以，吸取基于组件开发的其他好处，并且接受不是所有组件都能重用的事实。

可互换

一个功能明确好组件的API能让人轻易地更改其内部的功能实现。要是程序内部的组件是松耦合的，那事实上可以用一个组件轻易地替换另一个组件，只要遵循相同的 API/接口/约定。

可组合

基于组件的架构让组件组合成新组件更加容易。这样的设计让组件更加专注，也让其他组件中构建和暴露的功能更好利用。不论是给程序添加功能，还是用来制作完整的程序，更加复杂的功能也能如法炮制。这就是这种方法的主要好处。

组件化开发

如上图，简单解读一下：

• 页面上的每个独立的可视/可交互区域视为一个组件；
• 每个组件对应一个工程目录，组件所需的各种资源都在这个目录下就近维护；
• 由于组件具有独立性，因此组件与组件之间可以 自由组合；
• 页面只不过是组件的容器，负责组合组件形成功能完整的界面；
• 当不需要某个组件，或者想要替换组件时，可以整个目录删除/替换。

其中第二项描述的就近维护原则，是我觉得最具工程价值的地方，它为前端开发提供了很好的分治策略，每个开发者都将清楚的知道，自己所开发维护的功能单元，其代码必然存在于对应的组件目录中，在那个目录下能找到有关这个功能单元的所有内部逻辑，样式也好，JS也好，页面结构也好，都在那里。
基于这样的工程理念，我们很容易将系统以独立的组件为单元进行分工划分：

由于系统功能被分治到独立的组件中，粒度比较精细，组织形式松散，开发者之间不会产生开发时序的依赖，大幅提升并行的开发效率，也更容易支持多个团队共同维护一个大型站点的开发。

整个前端项目可以划分为这么几种开发概念：
- JS模块：独立的算法和数据单元，浏览器环境检测(detect)，网络请求(ajax)，应用配置(config)，DOM操作(dom)，工具函数(utils)，以及组件里的JS单元；
- CSS模块：独立的功能性样式单元，栅格系统(grid)，字体图标(icon-fonts)，动画样式(animate)，以及组件里的CSS单元；
- UI组件：独立的可视/可交互功能单元 ，页头(header)，页尾(footer)，导航栏(nav)，搜索框(search)；
- 页面：前端这种GUI软件的界面状态，是UI组件的容器 首页(index)，列表页(list)，用户管理(user)；
- 应用：整个项目或整个站点被称之为应用，由多个页面组成。

基于这些理念，前端开发就成了这个样子：

！整个Web应用由页面组成

综合上面的描述，对于一般中小规模的项目，大致可以规划出这样的源码目录结构：

前端组件的复用性

所谓组件化，核心意义莫过于提取真正有复用价值的东西。那怎样的东西有复用价值呢？

公共样式的复用性也是比较容易认可的，因此也会有bootstrap，foundation，semantic这些东西的流行，不过它们也不是纯粹的样式库了，也带有一些小的逻辑封装。业务逻辑这一块的复用是存在很多争议的，一方面，很多人不认同业务逻辑也需要组件化，另一方面，这块东西究竟怎样去组件化，也很需要思考。除了这些之外，还有大量的业务界面，这块东西很显然复用价值很低，基本不存在复用性，但仍然有很多方案中把它们“组件化”了，使得它们成为了“不具有复用性的组件”。
组件化的本质目的并不一定是要为了可复用，而是提升可维护性。

对于一个有一定规模的Web应用来说，把所有东西都“组件化”，在管理上会有较大的便利性。我举个例子，同样是编写代码，短代码明显比长代码的可读性更高，所以很多语言里会建议“一个方法一般不要超过多少行，一个类最好不要超过多少行”之类。
这个时候我们再看HTML的部分，如果不考虑模板等技术的使用，某些界面光布局代码写起来就非常多了，像一些表单，都需要一层套一层，很多简单的表单元素都需要套个三层左右，更不必说一些有复杂布局的东西了。尤其是整个系统单页化之后，界面的header，footer，各种nav或者aside，很可能都有一定复杂性。如果这些东西的代码不作切分，那么主界面的HTML一定比较难看。
从这个角度看，这些拆出去的东西都像组件，但如果从复用性的角度看，很可能多数东西，每一块都只有一个地方用，压根没有复用度。这个拆出去，纯粹是为了使得整个工程易于管理，易于维护。

这时候我们再来关注不同框架/库对UI层组件化的处理方式，发现有两个类型，模板和函数。
模板是一种很常见的东西，它用HTML字符串的方式表达界面的原始结构，然后通过代入数据的方式生成真正的界面，有的是生成目标HTML，有的还生成各种事件的自动绑定。前者是静态模板，后者是动态模板。
另外有一些框架/库偏爱用函数逻辑来生成界面，早期的ExtJS，现在的React（它内部还是可能使用模板，而且对外提供的是组件创建接口的进一步封装——jsx）等，这种实现技术的优势是不同平台上编程体验一致，甚至可以给每种平台封装相同的组件，调用方轻松写一份代码，在Web和不同Native平台上可用。但这种方式也有比较麻烦的地方，那就是界面调整比较繁琐。

有这么一个简单场景：一个雇员列表界面包括两个部分，雇员表格和用于填写雇员信息的表单。在这个场景下，存在哪些组件？

对于这个问题，主要存在两种倾向，一种是仅仅把“控件”和比较有通用性的东西封装成组件，另外一种是整个应用都组件化。对前一种方式来说，这里面只存在数据表格这么一个组件。 对后一种方式来说，这里面有可能存在：数据表格，雇员表单，甚至还包括雇员列表界面这么一个更大的组件。这两种方式，就是我们之前所说的“局部组件化”，“全组件化”。

我们前面提到，全组件化在管理上是存在优势的，它可以把不同层面的东西都搞成类似结构，比如刚才的这个业务场景，很可能最后写起来是这个样子：

<Employee-Panel>
<Employee-List></Employee-List>
<Employee-Form></Employee-Form>
</Employee-Panel>

全标签化的问题主要有这些：
第一，语义化代价太大。只要用了标签，就一定需要给它合适的语义，也就是命名。但实际用的时候，很可能只是为了把一堆html简化一下而已，到底简化出来的那东西应当叫什么名字，光是起名也费不知多少脑细胞。第二，配置过于复杂。有很多东西其实不太适合封装，不但封装的代价大，使用的代价也会很大。有时候会发现，调用代码的绝大部分都是在写各种配置。

这个问题讨论完了，我们来看看另外一个问题：如果UI组件有业务逻辑，应该如何处理。

比如说，性别选择的下拉框，它是一个非常通用化的功能，照理说是很适合被当做组件来提供的。但是究竟如何封装它，我们就有些犯难了。这个组件里除了界面，还有数据，这些数据应当内置在组件里吗？理论上从组件的封装性来说，是都应当在里面的，于是就这么造了一个组件：

<GenderSelect></GenderSelect>

性别的数据很自然地是放在组件的实现内部，一个写死的数组中。这个太简单了，我们改一下，改成商品销售的国家下拉框。但我们有个要求，本公司商品销售的国家的信息是统一配置的，也就是说，这个数据来源于服务端。这时候，你是不是想把一个http请求封装到这组件里？

这样做也不是不可以，但存在至少两个问题：

如果这类组件在同一个界面中出现多次，就可能存在请求的浪费，因为有一个组件实例就会产生一个请求。 如果国家信息的配置界面与这个组件同时存在，当我们在配置界面中新增一个国家了，下拉框组件中的数据并不会实时刷新。 第一个问题只是资源的浪费，第二个就是数据的不一致了。曾经在很多系统中，大家都是手动刷新当前页面来解决这问题的，但到了这个时代，人们都是追求体验的，在一个全组件化的解决方案中，不应再出现此类问题。
如何解决这样的问题呢？那就是引入一层Store的概念，每个组件不直接去到服务端请求数据，而是到对应的前端数据缓存中去获取数据，让这个缓存自己去跟服务端保持同步。所以，在实际做方案的过程中，不管是基于Angular，React，Polymer，最后肯定都做出一层Store了，不然会有很多问题。