组件化：搭建系统、智慧活动
目的：内聚性、耦合性、避免因业务引起重复劳动、协同合作、提高可维护性
组件化前提：制定标准，接触耦合
第一代：YUI
太过于学院派。要求每个用这个程序员熟悉整套UI规范和使用规范。就是要熟悉YUI的CSS，HTML，JS，这样才能用非常爽
第二代 ExtJS
ExtJS是踩着YUI的尸体走过来的，extjs比YUI进步在那儿呢，首先它表面上有一套漂亮的UI。这个实质上就是你不用写CSS了，它帮你写好了。另外你HTML也不用写了，它也帮你写好了。这不对啊，前端页面怎么可以没有HTML和CSS呢，extjs都帮你封装到js里了
extjs用是很简单，定制的话，还是改错一处，全局。
被边缘化
第三代：web component
shadow dom/custom element/template/import
这规范到不成熟，到处是坑
the end...
当然，组件化的时代已经开启，为了填原生的坑，已经有无数勇士已经又踩着前者的尸体冲上来了
他们是：
Angular Directives
Ember Components
React Components
KnockoutJS Components
Vue.js Components
Backbone Components
CanJS Components
Famous Components
Anything.JS Components?
贺师俊：
之所以一直说对custom element持谨慎态度，是因为正如本问题所表达出来的，大多数工程师对组件如何设计划分是缺乏经验的。相对来说基于 is 属性对原有html元素做扩展比较不容易出偏。
组件设计说到底是要做某种抽象。难就难在这种抽象要考虑很多的因素，比如适应UI设计师的建模、工程上的可维护性要求、常见用例和边缘用例的矛盾、自定义组件和标准html元素的穿插交互、适应将来需求变化发展的可扩展性和可定制性……其中很多点是在开始设计开发时很难确定的，或者随着业务发展经常会变化。这就是为什么组件领域比其他技术领域更容易出现抽象泄漏的悲剧。
