snowpack和vite:noWebpack,无bundle的代表

noWebpack的代表:snowpack和vite

  • "noWebpack",无bundle的代表:snowpack和vite
    • 背景
    • snowpack
      • 支持情况
      • 上手使用
        • 安装
        • 初始化新项目
          • 旧项目迁移
        • 配置
        • 开发调试
        • 生产打包
        • 基本原理
    • vite
      • 上手使用
        • 安装及初始化
        • 基本原理
    • 选型和展望
        • 相关链接

“noWebpack”,无bundle的代表:snowpack和vite

前段时间Vue3.0生态的介绍提到了vite这个工具,借此文简单整理记录"no webpack,no bundle"的相关内容。

背景

In 20192020, you should use a bundler because you want to, not because you need to.

在过去的几年中,如webpack 之类的bundle打包工具,已经从一个只限于输出优化bundle JavaScript的工具演变成一个需要为大多数web应用程序构建的必要步骤。不管你喜欢还是讨厌它,很难否认bundlers大幅增加了新web开发的复杂性。

为何会孕育出js捆绑打包的构建时代呢?个人认为有两个主要原因:

  • 1.http1.x的队头阻塞,使得合并请求变得很必要:http1.x的情况下,浏览器客户端在同一时间,针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞,从而影响性能,因此合并请求成为了普遍认同的优化原则;
  • 2.npm的运作限制。nodejs的模块体系,无论是Common.js 还是 CJS,无法在web浏览器上直接运行,我们必须依赖bundling。

这也导致如今很难看到一个前端项目没有webpack介入,由此一个项目的复杂性也大大增加。以create-react-app为例,我们单纯只想在页面中显示一个"Hello world",但是我们需要安装200.9MB的node_modules,其中包含1,300+不同的依赖,10s~几十s的构建时间,这仅仅只是为了输出一个"Hello world"。

那么基于以上两点,现如今有没有其他更好的处理方式呢?

  • 1.http2解决对头阻塞:多路复用作为http2的一大特性,允许同时通过单一的 http2 连接发起多重的请求-响应消息,而且随着 http2 的普及,合并请求变得没那么必要。
  • 2.浏览器开始支持ESM模块功能:模块功能的核心importexport,它们在浏览器端现在的兼容情况如下:
    • import
      snowpack和vite:noWebpack,无bundle的代表_第1张图片

    • export
      snowpack和vite:noWebpack,无bundle的代表_第2张图片

    • 并且作为模块的定义,

你可能感兴趣的:(前端,js,webpack,vue.js,javascript,webpack,前端,node.js)