这是我参与「第五届青训营」笔记创作活动的第二十五天
前端工程的痛点 | 为什么需要工程化
- 简单来说，前端项目就是由一系列的资源构成的，可以是逻辑代码，可以使样式代码，也可以是静态资源等等
- 模块化 => 把项目分成不同的模块，分别进行开发和维护，这样就可以把项目拆分成不同的模块，然后分而治之。在Python，Go等其它语言中，都有一些语言标准的模块化规范，而JS却没有统一的规范(主要有
ESM, CommonJS, UMD) - 资源编译 => 当今的前端工程中，可以经常看到
TS, JSX, Sass等这些高级语法，基本上成为了项目的标配，这些语法浏览器是不认识的，所以我们需要将它们编译为浏览器认识的形式，这背后就涉及到一系列的工具链，因此对与编译工具链的集成，也成了刚需 (也可以认为是，浏览器的标准赶不上前端开发者的脑洞，前端开发者制造出了非常多的语法特性，非常多的语法糖，非常多的工具来提升我们的开发体验，但我们的浏览器对这些高级语法是不支持的) - 产物质量 => 线上的代码需要压缩，否则体积会比较庞大，会影响到线上的性能，及用户体验，对于未用到的模块，我们需要将它们从构建产物中剔除掉，来优化产物体积; 兼容性的问题，一般来说，需要兼容到安卓4.4，ios9，也就是低端的浏览器，如果不考虑的化，可能会出现白屏等事故
- 开发效率 => 比如说你改动代码后，想立刻看到最新的改动，来提高开发效率和体验，但是没有构建工具来做的化，这个开发效率的提升，是没有办法完成的
前端构建工具的意义 | 如何解决以上问题的
- 模块化方案 => 比如说
Webpack里有一个Webpack runtime，是一个模块加载器，来对每一个模块的导入导出进行一个规范的统一 - 语法转译 => 构建工具一般会集成一系列的编译工具链，比如说Sass，TS等相关的一些工具 (比如说
web pack中的loader, CSS loader, style loader 啊等等, 像这些loader就是来做语法的转译的)，资源加载，也是属于语法转译的一部分 - 产物质量
- 开发效率
