前端一些误解

✅趴在床上娇喘，❎隔着网线叫唤

很久没有更新这个系列了，啊哈哈哈，上一篇都是很久以前了，今天上来更新一篇

主要是某些认知偏差，需要去解释一下

vite 并不快

最近老有人和我说 vite 好快，然后将他们的编译的截图发给我，是这样子的：

他惊呆了，他觉得这太快了，我也惊呆了，这只是预编译，你特么要 300 ms！

vite 这类打包工具，本地做的是预编译的工作，真正的编译发生在浏览器端，如果在浏览器端加一个这样的 loading

这才是真正的编译时间，不是你在控制台里看到的预编译时间

所以其实 vite 团队还是很狡猾的，其实从理论上讲，transform 同一个文件，vite 不可能更快，毕竟走 http 和走 file 本身就不是一个量级

当然，vite 确实可以改善开发体验，但其实和速度没什么关系，抛开瓶颈谈性能，就是在日最温柔的狗

vite 真正的意义是缩短链路，比如 HMR，以往 webpack-dev-server 一堆插件搞定的事情，vite 中比较容易继承

我很喜欢 vite 这种 dev-server 的总体思路，甚至之前还写了个 deku，主要也不是因为性能，而是因为可以摆脱 webpack 又长又臭的链路

svelte 的 runtime

这也是一个很常见的误解，经常看到有人说 react runtime 很重，svelte 的 runtime 很轻，其实这种说法是没问题的，但……

fre 的 runtime 是重还是轻呢？

fre 只有 1kb，一般人肯定会觉得 fre 的 runtime 很轻，但其实不是的

fre 用的算法，主要的遍历方式（fiber 链表的遍历）和 react 一模一样，它俩的 runtime 其实都很重

1kb 也可以很重，30kb 也可以很轻

runtime 重不重，主要看代码的时空复杂度，svelte 的很多遍历都是一层简单的别名，所以它的总体复杂度和原生 js 相当

所以不管 svelte 生成的代码有多少，它的 runtime 还是轻量的

哪怕在某个阈值之后，svelte 生成的代码比 vue 的代码多得多，但不妨碍 svelte 的内存方面，时间方面，都比 vue 要轻得多

所以尺寸和 runtime 没什么关系

Recommend