说到前端构建工具，就不得不提强大的Webpack，尤其是最新版本提出的ModuleFederation功能，进一步提升了Webpack的实际作用。相信以Webpack这几年的积累，未来几年恐怕没有任何打包工具能与之匹敌，但这并不妨碍我们讨论新工具Snowpack。现代捆绑器的问题使用Snowpack，当您构建现代Web应用程序（使用React、Vue等）时，您不需要使用像Webpack、Parcel和Rollup这样的捆绑器。每次点击保存时无需等待打包程序重建。相反，所有文件更改都会立即反映在浏览器中。请马上注意这个词，bundleless？这是什么意思？为什么我会如此关注这个工具。对于一些项目和开发者来说，这可能并没有太大的感觉，但是对于我来说，开发中的打包曾经是一场噩梦。几年前，我从零开始开发一个Sass前端项目，项目一开始使用Vue和Webpack，根据业务线构建多个页面。过去几个月，有十几个模块。当我修改一个小地方时，需要将近一分钟的时间才能完成热更新。当时我们只能在项目启动的时候设置哪些页面需要编译。苦了一周后，我们不得不开始拆分项目。由于开发人员和项目开发的效率，我们不可能按照业务拆分项目。我们只能抽取项目中改动较少的基础服务和封装的业务组件。使用Webpack的外部组件来辅助开发。这个方案很好的解决了项目当时的痛点。同时，这件事也让我对模块划分和性能优化有了一定的理解和感悟。所以，在我看来，bundleless解决了大部分前端开发者的一大痛点，就是流量）。当一个程序员被打断时，他需要10-15分钟才能恢复到之前的编程状态。当你完成了一小块功能，想要查看结果，发现当前项目还在建设中，此时很可能会停止流程。当然，还是有一些聪明的程序员，完成了整个功能，然后再查看结果。同时开发的bug也很少。该工具对此类程序员也不是很有帮助。说到这里，我真的很想多说几句。虽然程序员需要学习和使用很多工具来辅助开发，但其实很多工具确实可以提高效率，只是有时候需要逼自己逼迫自己。处在资源不是那么充足的情况下，因为只有这样才能真正提升自己的能力。这里推荐一篇博客断点单步跟踪是一种低效的调试方式。无论你同意还是否认，我想你都可以从这篇博客中得到思考。前端项目的演进就目前成熟的前端框架而言，都会提供一套脚手架工具供用户使用。我们之前也是直接把项目从Webpack转移到VueCli3。因为VueCli3内部封装了Webpack，开发中基本不需要Webpack的基础配置，我们需要的依赖项目也大大减少，底层依赖升级也转移到了VueCli，也是变相的开发量减少了很多。在讨论新的构建工具Snowpack之前，我想问一个问题，我们为什么要使用Webpack？其中一个当然是因为Webpack确实提供了很多高效有用的工程实践来赋能前端开发者。如果让我们自己研究和使用，投入的时间和需要掌握的知识远远高于配置学习的成本。二是因为它是静态JavaScript应用的静态模块打包工具。主要重点是该工具为前端提供模块和包装。JavaScript的设计初衷是为了保持简单，缺乏其他通用语言所具有的模块化特性。而这个功能正是组织大型复杂项目所需要的。但是当时JavaScript的工作就是实现简单的表单提交，几行代码就可以实现功能。尽管Ajax标志着Web2.0时代的到来，但前端开发的重点仍然是减少全局变量，所以我们开始使用IIFE（立即调用函数表达式）来减少全局变量的污染，以及问题与IIFE方法的区别在于没有清晰的依赖树。开发人员必须按照准确的顺序组织文件列表，以保留模块之间的依赖关系。由于网页的生命周期短，加上当时的后端渲染机制，保证了网页的依赖可控。之后，Node.js诞生了，让JavaScript来开发后端。在Node.js的众多创新中，值得一提的是CommonJS模块系统，简称CJS。CommonJS标准具有更传统的模块加载机制，利用了Node.js程序可以访问文件系统这一事实。在CommonJS中，每个文件都是一个模块，具有自己的范围和上下文。当然，这个机制虽然也是来自底层，但也来自于IIFE（立即调用函数表达式）。这种创新的爆炸式增长不仅来自创造力，还来自必然性：当应用程序变得越来越复杂时。控制代码之间的依赖越来越难，可维护性越来越差。我们需要模块系统来适应这些扩展和变化，然后围绕它们的生态系统将开发出更好的工具、更好的库、更好的编码实践、架构、标准和模式。最后，随着模块系统的实现，JavaScript终于有了开发大型复杂项目的可能。虽然后来开发了各种模块加载机制，比如AMD的UMD等，但是要等到ES6的到来。JavaScript刚刚正式获得了自己的模块，通常称为ECMAScript模块（ESM）。也是SnowPack依赖的基础，后面会展开。相对于CommonJS，ESmodule是官方标准，明确了JavaScript语言的发展方向，而CommonJSmodule是一种特殊的传统格式，在ESM提出之前作为临时解决方案使用。ESM允许进行静态分析，从而实现摇树优化等优化，并提供循环引用和动态绑定等高级功能。同时在Nodev8.5.0之后，在实现标准的情况下也可以使用ESM。随着Node13.9.0的发布，ESM已经可以在没有实验标志的情况下使用。Webpack一方面解决了构建大型前端项目的问题，另一方面提供了优化Web前端性能的插件。例如，它从资源合并和压缩方面解决了HTTP请求过程的问题，将小图片打包成base64以减少请求量，并提供了Tree-Shaking和动态导入。随着HTTP协议的升级，网速的不断加快，我也希望以后这些工作能逐渐成为负担。ESM（ecmascript模块）已经到来SnowPack是一个基于ESM的工具。想要用一次安装替换重建每个更改的构建步骤。ESM现在可以在浏览器中使用了！我们可以使用[Caniuse]()来查看ESM的可用性。可以看出，基本上现代的浏览器都已经提供了支持，实际上我们不需要等到所有的浏览器都提供了支持。我们不需要提供跨浏览器的一致体验，我们也不能。其实我们可以在这件事情上实现渐进式的增强。对于不支持的浏览器，这个语句根本无法理解，js也不会被加载。例如前端库instant.page可以提供页面预加载。该库在不支持ESM的浏览器上根本不会执行。同时对于暂时不支持的浏览器，js还是可以加载的。唯一需要做的就是为不支持同时我们可以通过type="module来判断现代浏览器“设备。支持type="module"的浏览器支持你熟悉的大部分ES6语法。通过这个特性，我们可以将两种代码打包，为现代浏览器提供新代码，为不支持ESM的浏览器提供新代码。提供了另一组代码。详情请参考PhillipWalton的精彩博文。这里还有一个翻译版的如何在生产环境中部署ES2015+。如果现在的项目已经开始从webpack阵营转向VueCLI阵营，那么恭喜你，上面的方案已经内置到VueCLI中了。只需使用以下指令，项目将生成两个版本的包。详情请参考VueCLI现代模式。Snowpack解决了什么问题？出于对主流浏览器的判断，SnowPack大胆采用了ESM，其原理也很简单。在内部，它帮助我们将node_modules的代码组织和安装到一个名为web_modules的文件夹中。需要的时候直接导入到这个文件夹中。能。它的目标也是为了解决引入第三方代码的问题。（注：需要Nodev10.17.0以上版本才能安装Snowpack）当然如果只是为了解决第三方引入的问题，其实我们也可以手动解决，但是面对错综复杂的第三方库，我们自己用node来解决。构建起来有点太复杂了。同时该工具依然会提供使用TypeScript和Babel的解决方案，同时也会为我们提供少量的配置选项来帮助我们管理第三方依赖。同时，Snowpack也可以通过--nomodule来支持旧版浏览器。同时，它还可以根据当前导入的模块自动构建依赖。当浏览器本身已经开始支持模块，如果网速不再是限制，我们是不是应该离开复杂的构建环境，转向简单的代码？答案是肯定的，简单的解决方案一定会赢得开发者的青睐。说到这里，我不禁想到，刚学软件的时候，总是在BS（浏览器和服务器）架构和CS（客户端和服务器）架构之间遇到问题和选择。历史的选择告诉我们，能使用BS架构的软件，一定会使用BS架构。如果说桌面端从CS到BS的转型是一条漫长的探索之路，那么移动端从CS到BS的转型就是必经之路。对于Vue这样的渐进式框架，即使没有打包工具，我们仍然可以直接在html中引入开发，而对于React、Svelte等需要先编译后才能使用的库，SnowPack也提供了解决方案，帮助我们协同解决方案。对于css图片，浏览器不支持用js导入，需要我们修改。具体实现可以直接参考Snowpack官网和Snowpack示例。说到Snowpack的优点，还得说说Snowpack的缺点。过于激进必定是劣势。毕竟现在还有很多库不支持ESM。面对企业应用开发，我们还是需要稳定的工具。同时，在强大的脚手架工具面前，显得过于捉襟见肘，需要更多的精力去维护系统的一致性。同时，浏览器使用模块化后，前端代码更容易分析。这是否会影响项目本身，其实还有待商榷。没有模块热更新功能，开发起来很痛苦。题外话vite前两天发布了Vue3beta版本。在直播中，Vue开发者游雨溪还谈到了为Vue3提供的“小”工具vite，我也是在闲暇之余把玩了一下。这个工具也是基于浏览器ESM结合node，为每个变化的模块提供即时编译，直接提供给浏览器。也就是说，当你在开发中修改了一个vue文件，node会对该文件进行编译，并通过HMR将当前编译好的vue文件提供给浏览器。与Snowpack相比，这个方案更加优雅（个人感觉）。开发和生产环境都被考虑在内。虽然现阶段还不能投产，但相信vite在未来一定会大放异彩。展望过去几年，我们需要Webpack配置工程师。随着Parcel的发布，Webpack也提供了零配置。随着依赖升级越来越复杂，各个框架也都使用Webpack作为自己的依赖来提供更好的Tools，withbundleless。我们可以看到，前端开发难度降低的同时，体验也得到了提升，这是一件好事。同时，云Serverless架构也降低了创业公司对基础设施的需求。说不定以后真的会有业务人员参与开发。而我们也有更多的时间投入到业务场景和业务需求上。鼓励如果您觉得这篇文章不错，希望您能给我一些鼓励，帮我在我的github博客下star。博客地址参考Snowpack官网VueCLI现代模式如何在生产环境部署ES2015+snowpack提高打包速度10倍断点单步跟踪是一种低效的调试方式vite
