昨天我们聊到了前后端开发的分离，以及针对用户体验问题的一些解决思路。今天我们继续聊一下前端的发展历程。

工具&组件化

我们可以看到，一个典型的互联网应用，一般页面都要上千个，每个页面都要保持一致的用户体验和展示。要保持开发效率，就要求我们一定要复用一些页面模块。组件化是要考虑的一个问题。

另外，前端的开发流程太琐碎了，很多优化更新工作需要我们手工去做。大规模协作开发的时候就是个麻烦。虽然有SVN/Git等版本管理工具，但只能做到代码层面基本的共享和协作。要想让大家高效协作起来，就得让开发流程有统一的工具、流程、约定或制度等等。比如什么目录放什么东西，互相怎么依赖的一些约定，编译过程的约定等等。有了这些约定，我们才可以开发各种工具脚本，让整个流程自动化起来。

当然，这些工具也是需要不断更新维护的。我们就需要一个工具库，大家可以方便的获取各种工具。同时当工具更新后，大家也可以及时更新。去看看npm和webpack，是不是就实现了我们这个想法。

组件化设计思路

下面我们来详细聊一下组件化的设计思路。

在讨论设计思路之前，我们先来了解一下Web组件的绘制机制。浏览器加载一个Html页面时，会将页面上的各个控件解析成树状的结构。这个结构就是Dom对象。同时浏览器为Javascript代码提供了解析引擎。这样，我们自定义的组件，就可以通过JS代码来操纵Dom对象完成渲染。这里我们可以看到，每次对Dom的操作都需要由JS引擎调用浏览器代码完成。每次操作都是有代价的。频繁的Dom操作会导致页面加载的卡顿。

我们看一个可被复用的组件，会有css/js/html三个部分构成。下面我们分别看一下这三个部分怎么设计，复用起来会更方便。

先来看一下css样式部分，我们期望组件体系应该有公用的一些样式，可以整体替换风格。同时也有一些组件自己的样式，可以灵活调整。最简单的方式，我们可以把公用和独特样式代码抽去出来，分到不同的文件。当复用的时候，通过控制加载不同的文件来实现。

当然，当样式多到一定程度，管理起来会非常麻烦。我们可以在预编译阶段帮我们做一些支撑。这样，我们在CSS代码阶段就可以按可理解的方式去编写，比如定义环境变量，按变量去判断加载等等。感兴趣的同学可以去研究下SASS等框架。

再看一下js和html部分的复用。一个简单的方式，就是把组件代码放到单独的模板页面中，通过后端的include方式来复用。比如，每个页面的统一的header和foot可以这么实现。但是有一个问题，如果一个页面中出现多个该组件呢。就有可能会加载多次js文件，同时html和js对象命名，就有可能冲突。

要解决命名空间冲突的问题，我们就需要为每个组件的生命周期做统一的管理。这样，组件就需要有一个对应的js类，这个类将组件的生命周期、渲染和事件处理封装起来。当我们复用这个组件的时候，就需要创建这个js类就可以。

再来看一下组件的渲染问题，这就牵扯到这个html部分怎么和js类勾连起来。如果放开用户自己编写html，那就需要使用方做这部分和js类的初始化。这样做的优点是用户清楚html部分的代码，可以灵活的扩展和修改展示样式。同时，没有过多的js对dom的操作，渲染效率很高。缺点是封装得不够彻底，用户需要了解很多组件内部的细节。

如果不放开用户编写html，可以完全通过js类来完成渲染的过程。这样也是可以的，优点是组件封装很好，用户不需要了解具体实现细节。缺点是对dom操作比较频繁，页面展示性能不高。

大家看看jquery ui和extjs是不是就是这两种方式的实现。感兴趣的同学可以去深入研究一下。

通过这两种方式实现后，其实还有一些问题需要解决。当页面数据变化后，组件展示也需要跟着变化，我们还是需要有大量的界面交互代码需要编写。这就是MVC的架构，这样的组件化仍然不够优雅。

那如果我们把数据与组件之间的绑定关系隐藏掉呢。我们复用一个组件的时候，就不需要了解组件的细节，只需要关注组件绑定的数据。当数据发生变化的时候，组件的展示会自动变化。当用户操作组件后，数据也会自动发生变化。这样，我们复用起来是不是就足够简单。这是MVVM的架构。

大家可以看看argular/vue等框架，他们都或多或少实现了我们的想法。如果熟悉这两个框架的同学就会知道，虽然使用起来很方便，但是编写他的代码并不优雅，有很多约定的写法。

这里延伸出一个问题，语言或者框架的编写是否应该容易让人理解。我觉得这个点非常重要，越容易被理解的代码，其实质量越高，越容易被扩展。怎么让编写代码的方式更适合人的理解，这就需要各种工具的支撑，IDE的支撑、预编译的支撑、语言运行时的支撑等等。

总结一下，互联网应用的复杂度和团队协作的需求，推动了前端技术的飞速发展。更好用的工具支撑、组件化、让人更容易理解的编码方式是未来的方向。