Component，中文称为程序集或组件。 应用非常广泛，其核心意义是复用，对模块的依赖性有更高的要求。Module，中文为模块或模块。 其核心意义是分离责任，是代码级模块化生产。 它本身就是服务的功能逻辑，是具有一定凝聚性的代码组合，责任明确。
组件(Component )和模块(Module )又是一对混淆的名词，常常彼此替换。 个人总结，从设计上来看，组件强调复用，模块强调职责(内聚、分离)，或组件是满足可复用要求的模块。 (请参阅。
前端web APP应用程序的组件是旨在构建更大规模的APP应用程序的软件，这些组件有多种表示形式。 它可能具有用户界面(UI )，也可能是纯逻辑代码作为“服务”。 因为有视觉表现，所以UI组件更容易理解。 UI组件的一个简单示例包括按钮、输入框和文本字段。 汉堡状菜单按钮、选项卡、日历、选项菜单或可见的富文本编辑器是更高级的示例。 提供服务类型的组件可能很难理解。 这种类型的示例包括跨浏览器提供AJAX支持、日志记录或某种数据持久化功能。
基于组件开发，最重要的是组件可以用来构成其他组件。 富格文本编辑器就是一个很好的例子。 它由按钮、下拉菜单和几个可视组件等组成。 另一个例子是HTML5上的视频元素。 它还包含按钮和从视频流中渲染内容的元素。
为什么要构建组件？ 高聚集我们总结了一些相关的功能并封装了所有功能，但在组件的示例中，相关的功能逻辑和静态资源可能是JavaScript、HTML、CSS、图像等。 这就是我们说的凝聚。 这使组件更容易维护，也提高了组件的可靠性。 另外，还可以明确组件的功能，提高组件复用的可能性。
可以重用显示的示例组件。 Web Component特别关心可复用问题。 功能明确，实现清晰，API容易理解。 可以自然地促进零件的再利用。 通过构建可复用的组件，我们不仅保留了DRY (不重复制造车轮)的原则，而且获得了相应的好处。
这里需要注意的是，不要过度尝试构建可重用的组件。 请注意APP应用所需的特定部分。 然后，如果出现适当的需求，或者组件达到可重用的级别，则重用组件需要一点时间。 事实上，开发人员喜欢创建可重用的功能块(库、组件、模块、插件等)，如果太早，以后会受苦。 因此，我们将引入基于组件开发的其他好处，并接受不是所有组件都可以重用的事实。
允许更换功能明确的组件的API可以轻松更改内部功能实现。 如果程序中的组件是松散耦合的，则只要遵循相同的API/接口/约定，就可以很容易地用一个组件替换另一个组件。
基于组件的体系结构的组合有助于将组件组合成新组件。 这样的设计可以让您专注于组件，利用其他组件构建和暴露的功能。 无论是在程序中添加功能，还是用于制作完整的程序，更复杂的功能都可以用同样的方法制作。 这是这种方法的主要好处。
组件化开发
如上图所示，我们来简单解读一下：
页面上的每个独立的可见性/交互区域被视为一个组件。 每个组件都支持工程目录，组件所需的各种资源在此目录下就近维护组件是独立的，因此组件和组件之间可以自由组合页面只是组件的容器，负责组合组件形成功能性接口； 如果不需要组件或替换组件，可以删除/替换整个目录。 其中，第二个说明的就近维护原则是我认为最有工程价值的地方，为前端开发提供了很好的分布式策略。 每个开发者都清楚，自己开发和维护的功能单元，其代码一定存在于对应的组件目录中，在该目录下，与该功能单元相关的所有内部逻辑、样式、JS、页面结构都在其中
基于这种工程理念，我们很容易将系统按独立的组件单位分工分类。
由于系统功能分布在独立的组件中，粒度较细、组织形式松散，开发人员之间不依赖开发时机，大大提高了并行开发效率，还可以方便地支持多个团队共同维护一个大站点的开发
整个前端项目可分为以下开发概念：
- JS模块：独立算法和数据单元、浏览器环境检测(detect )、网络请求(ajax )、APP应用程序配置(config )、DOM操作(DOM )、工具函数(utils )、
- CSS模块：独立的功能样式单元、栅格系统(grid )、字体图标(icon-fonts )、动画样式(animate )和部件中的CSS单元；
- UI组件：独立的可视和交互功能单元、页眉(header )、页脚(nav )、导航栏(nav )、搜索框(search )；
-页面： GUI软件的界面状态为： UI组件的容器首页(索引)、列表页面(列表)列表(用户管理)用户)；
- APP应用程序：整个项目或整个站点称为APP应用程序，由多个页面组成。
基于这些理念，前端开发变成了这样：
！ 整个web APP应用程序由页面组成
综合上面的描述，对于一般中小规模的项目，大致可以规划出这样的源码目录结构：
前端组件的复用性所谓组件化，核心意义莫过于提取真正有复用价值的东西。那怎样的东西有复用价值呢？
公共样式的复用性也是比较容易认可的，因此也会有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了，不然会有很多问题。