- 最好介绍远古世界
- 最好随性一点，不要太刻板 ，不然像背书
前端工程化的历史
互联网初期，09 年以前，页面只需要展示一些列表、表格、文章内容以及简单图片即可，其目的是为了传送信息。这个时候构建内容非常简单 html 即可，对文章内容进行一些简单排版可以传输就ok了。
互联网开始向个人普及的时候，更多的桌面应用的缺点越来越明显，越来越多的软件专项web应用，用户从科研人员变成了普通大众。相对的获取\传输信息依旧很重要，但是对于界面交互就希望有更高的要求。这个时候构建内容的工具从简单的 html 增加了一项 css 来美化html在浏览器上输出的内容。当然也是这段时间，人机交互也稍微复杂了一些，通过js来控制一些页面展示的效果（例如：轮播图、文字滚动）
第一阶段 桌面应用到web应用
越来越多的行业依赖软件，但明显桌面应用的限制越来越突出
- 一个软件一个包，
- 需要经常更新
- 跨端 跨电脑需要重新安装
随着软件需求爆炸性增长
后来互联网的用户数量爆炸式增长（个人PC普及后期），前端（页面展示，那个时候可能还没有专职的前端）需要负载的功能日益复杂，浏览器版本、种类层出不穷。这个时候需要解决的主要问题是不同浏览器的兼容性。2006年诞生的jquery就是其中的代表。兼容性问题要解决，交互问题同样需要解决。页面和服务器的交互逻辑受困于jsp等技术这些代码只能由服务端代码完成，有什么变更需要页面全部刷新。所以ajax应运而生。大概就是08年前后，jquery技术风靡数年至今。
第二阶段 web应用 到单页应用
- ajax 诞生
- 2008 html5
- 网速增加
- 浏览器和硬件升级
- 浏览器兼容性问题变少，前端h5，es5相继发布web 前端 的主要矛盾由 浏览器的兼容性问题 前端的工作有组织dom结构、动画效果、页面交互逻辑 变成 除此之外大量 JS 代码的组织，与 View 层的绑定。都比较麻烦。可以理解为开发效率和可维护性问题
可维护性举例
- js 的类型
- 庞大的 CSS包
- 打包
- 编码规范
2009 之后前端需要利用软件工程化的思想来解决瓶颈问题
当时出现了很多 template模板工具，基于 jq，实现简单的 view 和 model 层包装。也出现了了 gulp、
再往后就是以react\vue为主导的spa（单页面应用的时代），然后就是以扩充前端能力为主的浏览器+node全栈时代，前端的severless和*sr（ssr、nsr、csr...）百花齐放。这个时代如果没有工程化的支持，那~这些都不会存在。
SASS（英文全称：Syntactically Awesome Stylesheets）Sass 诞生于 2007 年，使用Ruby 编写，是一种对css的一种扩展提升，增加了规则、变量、混入、选择器、继承等等特性。可以理解为用js的方式去书写，然后编译成css。比如说，sass中可以把反复使用的css属性值定义成变量，然后通过变量名来引用它们，而无需重复书写这一属性值。
LESS（2009年开源的一个项目，受Sass的影响较大，但又使用CSS的语法，让大部分开发者和设计师更容易上手。LESS保留了css的任何功能，同时提供了多种方式能平滑的将写好的代码转化成标准的CSS代码，可以在任何使用随时切换到css的语法进行书写。
2011 年以前
大概 09 年 - 10 年期间，CommonJS 社区大牛云集。CommonJS 原来叫 ServerJS，推出 Modules/1.0 规范后，在 Node.js 等环境下取得了很不错的实践。
09年下半年这帮充满干劲的小伙子们想把 ServerJS 的成功经验进一步推广到浏览器端，于是将社区改名叫 CommonJS，同时激烈争论 Modules 的下一版规范。分歧和冲突由此诞生，逐步形成了三大流派：
- Modules/1.x 流派。这个观点觉得 1.x 规范已经够用，只要移植到浏览器端就好。要做的是新增 Modules/Transport 规范，即在浏览器上运行前，先通过转换工具将模块转换为符合 Transport 规范的代码。主流代表是服务端的开发人员。现在值得关注的有两个实现：越来越火的 component 和走在前沿的 es6 module transpiler。
- Modules/Async 流派。这个观点觉得浏览器有自身的特征，不应该直接用 Modules/1.x 规范。这个观点下的典型代表是 AMD 规范及其实现 RequireJS。这个稍后再细说。
- Modules/2.0 流派。这个观点觉得浏览器有自身的特征，不应该直接用 Modules/1.x 规范，但应该尽可能与 Modules/1.x 规范保持一致。这个观点下的典型代表是 BravoJS 和 FlyScript 的作者。BravoJS 作者对 CommonJS 的社区的贡献很大，这份 Modules/2.0-draft 规范花了很多心思。FlyScript 的作者提出了 Modules/Wrappings 规范，这规范是 CMD 规范的前身。可惜的是 BravoJS 太学院派，FlyScript 后来做了自我阉割，将整个网站（flyscript.org）下线了。这个故事有点悲壮，下文细说。
2015 年
前端的ES module发布后，rollup应声而出。
rollup编译ES6模块，提出了Tree-shaking，根据ES module静态语法特性，删除未被实际使用的代码，支持导出多种规范语法，并且导出的代码非常简洁，如果看过 vue 的dist 目录代码就知道导出的 vue 代码完全不影响阅读。
browserify、webpack、rollup、parcel这些工具的思想都是递归循环依赖，然后组装成依赖树，优化完依赖树后生成代码。但是这样做的缺点就是慢，需要遍历完所有依赖，即使 parcel 利用了多核，webpack 也支持多线程，在打包大型项目的时候依然慢可能会用上几分钟，存在性能瓶颈。
前端模块化/构建工具从最开始的基于浏览器运行时加载的 RequireJs/Sea.js 到将所有资源组装依赖打包 webpack/rollup/parcel的bundle类模块化构建工具，再到现在的bundleless基于浏览器原生 ES 模块的 snowpack/vite，前端的模块化/构建工具发展到现在已经快 10 年了。
工程化解决的问题就是提高整个工作系统的效率。大量的js代码，堆积的程序最麻烦的就是如何去维护。100行代码，看一遍，打着断点过一下，就知道是在做什么了。但是1000行，10000行甚至是10万行的代码，你怎么维护？真的要一点一点看？那这个对企业来说维护的成本就是天文数字甚至于不可估量。随着浏览器的不断更新迭代，大量的能力扩充，对我们构建前端应用来说也是一个挑战。
什么是前端工程化
- 历史背景
- 出现原因
- 主要工具
- 现状
- 未来展望
前端工程化是指，使用软件工程的技术和方法，将前端的开发流程、技术、工具、经验等规范化和标准化，其主要目的，是为了提高效率和降低成本，即提高开发过程中的开发效率，减少不必要的重复工作时间。前端工程化具体包含：
- 标准化，定义编码、目录结构、接口以及源码管理等规范；
- 组件化，组件分为HTML、JS和CSS；
- 模块化，功能封装；
- 自动化，持续集成和持续部署。
不同时代的理解
第一个阶段是选择框架、库：像jquery，这时候的工程化就是在开发时忽略对兼容性的考虑、提高编码效率降低开发成本
第二个阶段是优化构建：以grunt、gulp为代表的这些工具。这时候的工程化是解决应用体积变大后输出产物的优化
第三阶段是html+js+css模块化开发：这时候的工程化的代表是angluar。
第四个阶段是组件开发与资源的管理：在这个阶段 react/vue 引领了前端开发应用的潮流，webpack + rollup 则引领了优化构建的方向。
第五个阶段是前端能力的扩充与完善：以node全栈和h5规范为基础的百花齐放。说实在的h5规范现阶段扩充了很多能力并且浏览器厂商也在逐步支持，并且这些能力愈来愈强大，如视频/音频的播放能力、canvas与webGL、WebAssembly等等多样的能力意味着更多的接口、代码以及业务逻辑。node全栈给前端扩充了N多能力，首当其冲的是ssr，目前看来非常重要的数据安全性（以通过graphGL来进行数据组合过滤实现为代表）。其次是前端的serverless，不受制于传统后端与前端的业务范围。
首先前端工程化是把软件工程相关的方法和思想应用到前端开发中。
狭义上的理解： 将开发阶段的代码发布到生产环境，包含：构建，分支管理，自动化测试，部署
广义上理解： 前端工程化应该包含从编码开始到发布，运行和维护阶段
工具是工程化的手段，只要我们引入的方法、技术方案、工具可以提升开发效率、提高前端应用质量，那么都属于前端工程化
工程化主要特点是什么
- 不建议大家盲目地追求工程化，对于大部分规模不大的前端团队而言， 工程体系的建设和规范并不是当务之急
工程化如何实践
我的理解里把 前端工程化分为 5 类
开发、构建、部署、性能、规范化
还有第六类 需求
规范化需求
- 性能优化
- 团队规范
- 我对团队的贡献
- 开发
-
- 框架选型
- 前后端分离
- 组件化
- 脚手架
- 本地开发服务器
- mock 服务
- 微前端
- 构建
-
- 依赖打包
- 文件压缩
- 代码分割
- 增量更新与缓存
- 资源定位
- 图标合并
- es 与 babel
- css 预编译和 postcss
- 持续构建与集成
- 类库打包
- 构建优化
- 部署
-
- 持续部署
- 部署流程设计
- 静态资源部署策略
- nginx 反向代理
- spa 路由配置
- 跨域
- https 证书
- http2 配置
- 灰度发布
- 预发布环境
- 性能
-
- 缓存策略
- 缓存复用
- cdn 内容分发网络
- 按需加载
- 同步异步加载
- 请求合并
- 首屏渲染速度
- http2 服务推送
- 日志性能监控
- 预加载
- 性能测试
- 规范化
-
- 目录结构规范
- 编码规范
- 技术栈规范
- 前后端接口规范
- git 规范
-
-
- commit 规范
- 分支名、提交等规范
-
-
-
cr 规范
-
设计规范
-
图标规范
-
文档规范
-
版本规范
-
开发流程规范
-
发布规范（测试、灰度、预发、线上）
-
