(临时写的,待补充)

基于Web的前端开发有三大要素:界面结构、业务逻辑、修饰,对应到实现技术,分别是DOM结构(也就是HTML)、JavaScript、CSS,三者共同构成完整的Web。

三者之中,DOM结构最为核心,因为它表达了整个界面的语义。在分工良好的前端开发过程中,逻辑和交互是分离的,分别使用JavaScript和CSS来共同操作、修饰DOM结构。

所谓的工业化,最本质的含义是良好的协作关系,完善的流程,先进的工具。工业化的目标也很明确,就是提高效率。那么,在前端开发的过程中,有哪些地方是可以提高效率的呢?

首先我们想到的就是复用。复用的意思是,某一块东西多次出现,不必为它重复劳动,做一份,然后其他地方拿来用。

HTML部分的重用,现在方案很成熟,那就是模版。我们把要重用的HTML片段做成模版,借助于一些流行的模版库,就可以把它们放置到界面的各种需要的地方去了,模版除了可以是静态内容,也可以跟一些模型数据绑定。

JavaScript部分的重用,经历了几个阶段。最初的阶段,大家把公用的js代码从页面中抽取,放在单独的文件,哪个页面需要就引入进来,然后,经历了全局变量冲突的痛苦,大家意识到要引入命名空间的机制,再后来,require等按需载入手段被发明出来,对脚本部分的控制更加精细化了。

CSS部分,也经历了原始阶段到模版生成,现在的LESS、SASS等技术,起的就是这样的作用。

以上,我们看到了目前Web前端三个核心部分的复用状态。稍等,这里面有没有什么值得注意的地方?CSS这个部分,有些特别,特别在哪呢?它可以有一个编译生成的阶段,但HTML跟JS方向没有,我们来看看这个生成过程有什么好处。

在我看来,LESS这类机制最大的好处是让样式变得可管理、易维护了,比如说,它可以有变量,当要改整体风格的时候,可以直接把这些变量一改,生成的CSS文件就自动搞好了,这个非常方便,我们HTML跟JS的部分能不能学学?

先看JS吧,我们看看JS开发过程中有可能碰到一些什么问题。假设现在我们都符合AMD这样的规范,写了ABC三个模块,A跟B依赖于C,于是在A里面require一下C,在B里面也这么做,问题来了,如果C被修改了,修改C的人从哪里知道自己被谁引用了,有可能造成他们出问题?嗯,我们可以做项目内搜索,然后可以通知A跟B的开发人员,或者跑一下它们的单元测试。

但,如果依赖你的模块不在你的项目里,怎么办?有什么办法去通知这些模块的开发人员,让他们关注一下可能受影响的功能?传统方式可能就在版本的变更说明里写一下吧,但是这个,很多人真的不看。我们把问题简化一下,用大阿里来举例(举例之前先膜拜一下),大家知道阿里有KISSY框架,各其他产品依赖于它,如果KISSY里面某模块产生了变更,即使只改了个名字,可以用什么办法来通知所有依赖它的产品开发人员呢?很难,对吧?

再举个例子,这些模块的命名空间由谁来负责规划?如果多个产品里面存在相同命名路径的模块,单独运营的时候没问题,突然有一天某两个产品集成部署,模块冲突了怎么办?这些都是问题。

所以,从很多角度,我都认为需要有那么一个手段,把JS代码集中管理起来,包括命名规则和依赖关系,这样,无论是模块的变更还是产品代码的发布,甚至混淆和压缩发布过程,都可以在这里面做。从功能来讲,版本服务器已经不能满足需求了,必须有一个附加的管理系统。

另一方面,HTML模版也有类似的问题,一个模版被别人引用,如果自己的布局有所调整,怎么能够让引用它的界面都验证一下是否影响体验?所以它同样需要有依赖关系管理。

好了,我们得出了一个初步结论,我们需要一个统一的平台,管理和发布HTML、JS和CSS。但是,把这些零散的改进功能放在一起,是不是算工业化了?远远不是,这思路才达到电影《国产007》里面“要你命3000”这样的效果,我们需要更多。

统一的Web开发平台应当做到极致,它的管理功能,应当能把云端服务之外的一切静态资源全部管理起来,包括字体、图片等资源,国际化语言字符串,还有界面片段和逻辑的绑定关系。除此之外,需要管理代码的单元测试,能够在发布之前做全量的单元测试,也需要能够管理API文档。

传统的API文档是静态生成的,并不重视交互。这种文档,用的时候会看看,但是看到问题了想要反馈就有些麻烦,而文档的维护人员在接到反馈之后怎样能尽快更新,也是一个问题。如果这些文档都是类似博客那种形式,或者像github里面markdown的文档,而且文档下面还能评论交流,那该多好呢?

除了文档之外,我们经常也有代码片段需要分享,或者就是直接可运行的示例,前者就像gist,后者就像jsfiddle和jsbin,如果这些也能集成到平台中,就更好了。

无论是文档还是示例,甚至是被管理的代码模块和界面片段,都应当允许评论,并且这些是一个统一的外挂模块,除了当作评论,应该可以当作微博来使用,类似,文档模块除了写文档之外,也应当可以当博客使用。

有了这些,整个平台就生动活泼起来了,然后我们就可以给它添加更有价值的特性。比如说,可以添加可视化的界面模版创建过程,可视化的界面流设计,整个就完全变成一个二次开发平台,当在这个平台上做的基础部件达到一定程度之后,再新做一个功能就有很多的东西可用,有可能几步拖拉设置,就能把需要的功能开发出来,从这个角度,开发的效率大为提高。另外一个角度,因为我们集成了逻辑的单元测试,所以可靠性也大幅提高了。

这时候回头一望,可靠、高效,不就是我们想要的结果吗?