银安

2012年前后的Grunt/Gulp的“任务流”阶段，虽然能自动执行压缩、合并，但依然存在严重问题，前端不只是要自动化，还需要把所有资源视为模块，统一管理和输出...

在模块化之后，前端项目不再是几个小文件，各种代码、资源越来越多，文件体积越来越大，人们需要一个自动执行重复构建任务的工具，以避免手工操作带来的各种问题

为什么会有“工程化”？ 我们从问题出发： 项目规模变大 90s/2000s 前端：一个页面，几个 JS/CSS 文件。 到 2010s：动辄上万行 JS，几十上百个模块。 👉 手工管理文件，完全不可维

“浏览器模块化” 和 “服务器模块化” 其实目标一致（解决代码拆分、依赖管理、作用域隔离），但是 运行环境完全不同，导致了实现方式和代码写法都有差别

AMD虽然初步解决了浏览器端模块化问题，但其写法别扭，和CommonJS差别太大，不符合大多数开发者的直觉，在这段历史过渡期，人们想出了哪些折中方案呢？

2009s 出现的CommonJS，初步解决了服务器端的模块化问题，那么浏览器端应当如何模块化？可不可以把CommonJS思路搬到浏览器呢？

在2009s前，IIFE 虽然能封装作用域，但随着项目越来越大，仍然存在严重的问题：依赖管理混乱、代码难以复用、无法按需加载等等问题，人们开始思考：能否有一个模块系统，让每个文件独立，彼此通过明确接口

在 2000s 的“动态交互时代”，随着前端业务逻辑逐渐复杂，JavaScript 代码也越来越长，不同文件中的变量、函数容易相互覆盖，如何避免它们之间的冲突？

为什么需要模块化？在 2000s 动态交互时代，前端开发逐渐复杂化： 一个网页可能引入 几十个 JS 文件。 依赖关系要靠人为记忆...