vite相较于webpack的优势

当我们开始构建越来越大型的应用时，需要处理的 JavaScript 代码量也呈指数级增长。包含数千个模块的大型项目相当普遍。我们开始遇到性能瓶颈 —— 使用 JavaScript 开发的工具通常需要很长时间（甚至是几分钟！）才能启动开发服务器，即使使用 HMR(热更新)，文件修改后的效果也需要几秒钟才能在浏览器中反映出来。如此循环往复，迟钝的反馈会极大地影响开发者的开发效率和幸福感。

起因: 我们的项目越大 ----> 构建工具（webpack）所要处理的js代码就越多【跟webpack的一个构建过程（工作流程）有关系】

造成的结果: 构建工具需要很长时间才能启动开发服务器 (启动开发服务器 ---> 把项目跑起来)

yarn start
yarn dev

npm run dev 
npm run start

webpack能不能改? 如果一旦要改那么将会动到webpack的大动脉

webpack支持多种模块化: 你的工程可能不只是跑在浏览器端

// index.js
// 这一段代码最终会到浏览器里去运行
const lodash = require("lodash"); // commonjs 规范
import Vue from "vue"; // es6 module

// webpack是允许我们这么写的

webpack的编译原理, AST 抽象语法分析的工具分析出你写的这个js文件有哪些导入和导出操作构建工具是运行在服务端的

// webpack的一个转换结果
const lodash = webpack_require("lodash");
const Vue = webpack_require("vue");

(function(modules) {
    function webpack_require() {}
    // 入口是index.js
    // 通过webpack的配置文件得来的: webpack.config.js ./src/index.js
    modules[entry](webpack_require);

}, ({
    "./src/index.js": (webpack_require) => {
        const lodash = webpack_require("lodash");
        const Vue = webpack_require("vue");
    }
}))

因为webpack支持多种模块化, 他一开始必须要统一模块化代码, 所以意味着他需要将所有的依赖全部读一遍

vite会不会直接把webpack干翻, vite是基于es modules的, 侧重点不一样, webpack更多的关注兼容性, 而vite关注浏览器端的开发体验

vite的上手难度更低, webpack的配置是非常多的, loader, plugin

postcss

vite天生对postcss有非常良好的支持

全屋净水系统有一个了解

水龙头里来的水是自来水

自来水从管道里先到这个全屋净水系统给全屋净水系统做一些插槽 ---> 去除砂砾 --> 净化细菌微生物 ---> ... --> 输送到水龙头 --> 我们可以喝的纯净水（为了保证到我们嘴里喝的水是万无一失）

postcss 他的工作基本和全屋净水系统一致: 保证css在执行起来是万无一失的

都对postcss有一个误区: 他们认为postcss和less sass是差不多级别

我们写的css代码(怎么爽怎么来) --> postcss ---> less --> 再次对未来的高级css语法进行降级 --> 前缀补全 --> 浏览器客户端

目前来说 less和sass等一系列预处理器的postcss插件已经停止维护了 less插件你自己去用less和sass编译完了, 然后你把编译结果给我

所以业内就产生了一个新的说法: postcss是后处理器 less的postcss的插件就ok了

我们写的js代码(怎么爽怎么来) --> babel --> 将最新的ts语法进行转换js语法 --> 做一次语法降级 --> 浏览器客户端去执行

babel --> 帮助我们让js执行起来万无一失

class App {} // es6的写法

function App() {} // es3的语法

浏览器的兼容性你能考虑到吗, 预处理器并不能够解决这些问题:

对未来css属性的一些使用降级问题
前缀补全: Google非常卷 --webkit

Vite

vite相较于webpack的优势

postcss