工程化要素

工程化要素

前端工程化的问题

代码组织

关键因子

回顾 Web 技术的发展历程,可以清晰地看到三类促使变革发生的关键因子:引擎,开发套件与分工模式。

引擎

引擎:有四大引擎显得尤为重要:

  • V8:不仅提升了 JS 的执行效率,助力 ES 规范落地,而且催生了 Node.js
  • 浏览器引擎:以 Webkit、Blink、Chromium 为典型代表,浏览器的高速发展为 Web 的繁荣奠定了基础
  • Node.js:大大拓展了前端的生存空间,以至于“Any application that can be written in JavaScript, will eventually be written in JavaScript.”
  • Hybrid 容器:让被 App 统治的移动互联网时代也给 Web 开发留下了一席之地,小程序是典型代表

开发套件

开发套件:语法、框架、工具、类库在社区的推动下一直在蓬勃发展,优秀的开源项目灿若星河,前端生态也成为技术圈中最活跃的。虽然以 React 为核心的主流技术栈上手成本还比较高,也做不到让开发人员只关心业务逻辑,但不可否认应用开发正在变简单。有些类型的应用甚至做到了无需 Coding 通过专门的可视化搭建平台就可以完成,比如:门户网站、营销活动、问卷调查等。

分工模式

分工模式:前后端分离、BFF(Backend For Frontend)、全栈、全端、大前端等分工模式的创新不仅提高了前端和其它工种的协作效率,也让前端有机会承担应用研发。由“前端 + 设计”组合形成的“体验技术部”也成为很多业务的标配,部分前端团队甚至发展为应用研发团队并且拥有了自研产品。前端的影响圈已经从应用开发延展到了用户体验甚至产品设计,以人机交互为本的 体验科技 也开始崭露头角。

这些变革因子的背后是两条主线:

  • 让现有研发工作做得更好:开发套件是主要推手,一些分工模式(比如:前后端分离)的创新也归属这条线
  • 开辟新战场:引擎是主要推手,一些分工模式(比如:全栈)的创新也归属这条线上

这些变革之所以会发生,是因为有一个刚需:客户端软件的生产力水平满足不了飞速增长的互联网应用诉求,而前端技术恰好能提升应用研发的生产力水平。虽然移动互联网的崛起曾一度让前端缺少发力之处,但寄生于超级 App 上的 Hybrid 容器又让前端焕发了生机,小程序更是将之推向了和 PC 时代同样重要的。

DevOps

打包部署

以前的大部分 Web UI 是通过 MVC 的方式来提供给用户的,前端页面大部分是通过后端模版渲染生成静态资源(HTML/CSS/JS)不经任何加工提供给浏览器的。也就是说,当时前端的静态资源相当于后端服务表现层(Presentation Layer)的一部分,复杂的交互通常都由后端来完成。因此前端静态资源通常非常简单,不需要经过复杂的编译打包,最多就是压缩(Minify)成更小的文件。

而现在的情况完全不同了,用户对于交互性的需求逐渐增大,通常不愿意花过多的时间来等待页面响应。传统的 MVC 模式受限于网络传输,通常需要几百毫秒甚至更多来完成一次页面导航,而这是非常影响用户体验的。因此,前端项目逐渐分离出来,单独作为一个应用运行在浏览器中,交互在浏览器端进行,速度非常快。但是,复杂交互都集中在前端里面,让前端项目变得更复杂,更臃肿,也更难以管理。因此,庞大的项目源码需要被压缩成很小的静态文件,尽可能少的占用网络资源传输给浏览器。现在稍微大一点的前端项目的依赖文件就会超过 500MB。相信你不会傻到将这么多文件一股脑塞给用户吧!

因此,你需要一个非常强大的打包和编译工具。Webpack[1] 是现在比较主流的打包工具,能够配合编译工具(例如 Babel[2])将各种类型的项目源代码文件(例如 .vue、.ts、.tsx、.sass)打包成原生的 .js、.css、.html 等静态文件,直接提供给浏览器运行。下图是 Webpack 官方网站的流程示意图。Webpack 通过检查源代码文件的各种依赖关系,分析编译后生成对应的静态资源文件。这就跟编译 Java、C# 代码编译是一个道理。

Links

下一页