大家好，我是三元同学。今天给大家介绍一款非常强大的前端搭建工具——Snowpack。也许你之前听说过很多前端领域的打包工具，比如Webpack、Rollup、Parcel，甚至是现在前端圈流行的Bundleless构建工具Vite，但你可能没有注意到积雪。事实上，它于2019年2月诞生于开源社区，可以说是业界第一个提出并实现的Bundleless解决方案。现在在社会上有很大的影响力。Github上的star已超过20,000。Big自己也承认，早期Vite的设计确实受到了Snowpack的启发。不管怎样，Snowpack本身就是一个非常好的解决方案，其背后的开发团队也是值得尊重的团队。我觉得有必要把这个解决方案分享给大家。时代先锋——PikaSnowpack的开发团队名为Pika。团队技术紧跟时代前沿。在开发新时代前端构建工具Snowpack的同时，还率先提出了第三方ESM格式Skypack，造福大众。图书馆的CDN服务（这个服务到底有多吸引人，后面会详细说）。他们有一个使命：使Web项目的构建速度提高90%。因为走在时代前沿，他们始终贯穿着一个研发宗旨：你应该能用bundler，因为你想用，而不是因为你需要用。换句话说，在当前的Web开发时代，打包不再是必需的选项，而只是一种优化手段，无需打包也能运行你的应用。现代Web建设即将变革，未来即将进入Bundleless时代（顾名思义，封装更少，建设速度更快）。在经历了Web领域的一系列工程变革之后，即将迎来另一个时代的创新浪潮，而Snowpack之父——鼠兔团队就是跨时代的浪潮。Snowpack是鼠兔队开创新纪元的第一枪！为什么？Snowpack为何诞生？Web建设为何进入Bundleless时代？为什么鼠兔团队更愿意全力以赴改变Web项目建设的现状？在真正介绍Snowpack之前，必须弄清楚这些问题。很久以前，网页前端的开发好像没有这么复杂的工具链和框架，写一些原生的HTML代码，CSS和一些JavaScript代码，那时候项目是怎么启动的？直接打开HTML文件！我更改了代码如何查看更新？直接刷新网页！一切看起来都是那么顺利，所见即所得。可以说那个时候的前端已经够直白了，够简单粗暴，简单到甚至让人有些怀念。直到后来，随着前端的逻辑越来越复杂，模块化的需求也越来越强烈。CommonJS（2009）、AMD（2010）、UMD（2011）等模块规范逐渐出现。底层规范出现并稳定下来之后，必然会有上层工具来实现，出现了一系列工程化的解决方案：模块加载器，比如SeaJS包管理器，比如npm打包器，比如Browserify、Gulp，Webpack更重要的是，在2009年，RyanDahl写了一个叫做Node.js的东西，它给JS带来了新的可能性。以前可以用Java和C++写的工具，现在用JS也可以写！它变得越来越复杂，各种工具链也越来越让人着迷。尤其是在2015年，ESModule标准的诞生，再次将工程解决方案的争论推向了风口浪尖。最终的赢家很明显，就是在座的几乎都是天天都能碰到的Webpack和Babel，甚至在今天已经成为了前端工程的代名词。不用说，Babel是一个著名的JavaScript编译器。在琳琅满目的语法标准中，它可以灵活地将一段JS代码从一种语法标准转换为另一种语法标准。Webpack有什么作用？它对自己的定位其实很简单，就是一个模块打包器。它的理念是：一切皆模块。不管代码里的依赖有多复杂，按照它的模块导入导出语法写，写完把入口丢给它，它会帮你把所有的依赖都整理出来，最后打包给你一个产品，不管你是否能看懂这个产品，浏览器都能看懂，代码性能和安全性都不会差，你大可放心。当然，作为打包者，Rollup和Parcel现在也很抢眼，但在Webpack强大的生态和行业基础面前，两者相形见绌。但一般来说，对于这样的打包器，肯定存在潜在的性能风险，因为它的构建时间与项目的整体规模成正比，也就是说，当项目规模变大时，很难避免构建时间变长不断越来越多，现在的前端项目可以说是多如牛毛，包装器这种性质的后果可想而知。果然，这一天来了。五年前用过Webpack打包，上手还挺快的。五年过去了，我还在用Webpack打包。团队多了20个人，代码多了20万行。现在每次启动需要10分钟！一旦更改代码，需要30,000ms才能看到结果更新！😭直到2018年2019年的一天，主流浏览器Chrome/Safafi/Firefox开始支持ESModule，并告诉开发者，你只需要扔入口代码，我会要求你所有需要导入的模块，你不用不需要再写包装了。把代码放在一起。这时，鼠兔团队登场，向世界宣布：未来的曙光已经出现，想要摆脱当下的困境，就请跟随我们，向着光明奔跑吧！这个曙光指的是浏览器开始支持ESModule标准，他们必须坚信这件事，而且由于HTTP/2的流行，之前将多个静态资源打包在一起以减少请求数的性能优化方式已经不行了不再需要，因此不再需要包装过程。基于这样的信念和基础，一年后他们宣布了Snowpack的诞生，新时代的第一个Bundleless解决方案终于问世。与Webpack的关系一方面，与Webpack相比，Snowpack的优势在于其构建速度非常快。这个速度主要体现在两个方面：开发阶段相当于启动一个DevServer，不需要打包业务代码，也省去了分析依赖和代码打包的一系列繁琐过程，甚至可以秒级直接启动.无论项目规模如何增加，构建时间复杂度始终为O(1)，不会随着项目规模的增加而增长。可以看出，当文件发生变化时，对于Webpack来说，需要重新构建依赖图才能进行整体打包，而对于代表Bundleless的Snowpack则不然??。每次都是单文件编译，构建速度不再受限。项目的规模也带来了文件变化后极快的更新速度。另一方面，Snowpack并不排斥Webpack。在生产环境搭建阶段，Snowpack本身也提供了插件机制来集成其他打包器，官方提供了开箱即用的插件@snowpack/plugin-webpack直接集成Webpack。这也比Vite更灵活。Vite生产环境打包只能选择Rollup，不能直接打包Snowpack，也可以选择集成任意打包器（Webpack、Rollup、Esbuild）打包。小结这次我们仔细分析了Snowpack诞生的历史背景和实现依据。相信大家对Bundleless已经有了初步的了解。当然，知道这些还不够。关于Snowpack和Bundleless，还有很多细节需要开发，包括预置依赖、StreamingImports、插件架构、HMR系统、服务端渲染支持等，后面我们会逐步从使用走向内部实施，一步步深入Snowpack的方方面面，让你一窥新时代建筑工具的风采。
