友达亲测Vue3和Svelte（19个组件后Vue更优！）这实际上让我很感兴趣，因为我最近在一个商业项目中使用Svelte进行了开发。那么结果如何呢？（往前看，我还以为友达要写Svelte代码测评呢，Vue大家都很熟悉了，不知道Svelte是什么？可以看看后起之秀前端框架Svelte从入门到原理。总的来说，Svelte是一个NoRuntime——没有运行时代码的框架。下面是JacekSchae的统计，他使用市面上的主流框架写出同样的Realword应用量：请看下面详细的研究步骤，如果对研究步骤不感兴趣，可以跳到最后看结论。研究步骤是为了公平起见，特别是我选择了todomvc进行构建对比，然后列出了一系列步骤。两个框架都实现了一个简单的todomvc组件，符合规范，功能相同。Vue：todomvc.vue（使用syntax)Svelte:todomvc.svelte(基于official实现，为公平起见去掉了uuid方法，我很失望，原来是裕达自己写的组件）组件分别使用各自框架Vue的在线SFC编译器编译：sfc.vuejs。org@3.1.4->todomvc.vue.jsSvelte:svelte.dev/repl@3.38.3->todomvc.svelte.js使用TerserREPL压缩编译后的文件，然后删除ES导入导出。这是因为在一个bundle应用程序中，这些导入/导出不是必需的，也不需要在多个组件之间共享。（可以理解为类似于第三方代码，不会影响组件内部实现的大小）Vue:todomvc.vue.min.jsSvelte:todomvc.svelte.min.js然后使用gzip和brotli进行压缩Vue的文件（Brotli是一个开源数据压缩程序库，类似gzip）：todomvc.vue.min.js.gz/todomvc.vue.min.js.brotliSvelte：todomvc.svelte.min.js.gz/todomvc.svelte.min.js.brotli此外，在SSR的上下文中，Svelte需要以“hydratable”模式编译其组件，这会引入额外的代码生成。编译Svelte时，使用选项hydratable:true启用SSR并重复步骤2-4。Vue在SSR环境中生成的代码完全相同，但引入了一些额外的特定于hydration的运行时代码（~0.89kbmin+brotli）。对于每个框架，默认情况下使用Vite来创建和打包构建（Svelte使用hyderable:false）。每个应用程序还设置SSR的模式并重新构建。默认情况下，Vite打包生成一个供应商块（=框架运行时代码）和一个索引块（=组件代码）。VueVue(SSR)SvelteSvelte(SSR)Source3.93kb-3.31kb-无导入编译(min)2.73kb-5.01kb(183.52%)6.59kb(241.39%)无导入编译(min+gz)1.25kb-2.13kb(170.40%)2.68kb(214.40%)无导入编译(min+brotli)1.10kb-1.88kb(170.91%)2.33kb(211.82%)Vite组件块(min+brotli)1.13kb-1.95kb(172.26%)2.41kb(213.27%)Vitevendorchunk(min+brotli)16.89kb17.78kb1.85kb2.13kb注：w/o表示没有，"remove"表示Analysis客户端模式，从Vitevendorchunk(min+brotli)列开始分析。SvelteApp导入1.85kbmin+brotli框架代码，比Vue轻15.04kb。这可能看起来非常强大，但这是因为框架运行时的差异。（Svelte没有运行时，Vue有运行时）查看组件代码，Svelte的最小+压缩输出大小是Vue的~1.7倍。在这种情况下，单个组件会导致0.78kb的大小差异。在SSR的情况下，该比率进一步上升至约2.1倍，其中单个组件导致1.23kb的大小差异。Todomvc很有代表性，代表了大多数用户在应用场景中构建和使用的组件。我们可以合理地假设在现实场景中会发现类似的大小差异。也就是说，理论上，如果应用程序包含超过15.04/0.78~=19Todomvc大小的组件，Svelte应用程序最终将比Vue应用程序更大。在SSR场景下，这个门槛会更低。在SSR模式下，虽然帧差为15.65KB，但CompnentCountthreshold下降到15.65/1.23~=13！显然，在现实世界的应用程序中，还有许多其他因素：将从框架中导入更多功能，并将使用第三方库。大小曲线会受到项目中纯组件代码百分比的影响。但是，据保守估计，如果Svelte大于19个组件（或SSR模式下为13个）的阈值，它的尺寸优势将更小。结语友达在仓库的README中给出了两个结语，所以我移到了最后。Svelte单体组件在普通模式下比Vue3单体组件大70%左右，SSR模式下大110%（公众号作者秋峰注：其实你这里说的有问题，这个70%是指与当前的todomvc组件大小比较并不意味着所有Svelte组件都比Vue3组件大70%。换句话说，如果一个Vue组件大小为100k，Svelte组件可能只有101k而不是170k！）对于项目，当写组件超过19个组件（SSR模式13个组件）Svelte相比Vue3的优势不存在。总的来说，这项研究的目的不是说哪个框架更好——它侧重于分析不同框架策略对体积大小的影响。从数据中可以看出，这两个框架在捆绑包大小方面具有不同的优势——具体取决于您的用例。Svelte仍然非常适合一次性组件（例如包装为自定义元素），但它的大小实际上是它在大型应用程序中的缺点，尤其是SSR。从更广泛的意义上说，这项研究旨在展示框架如何在编译时编译和运行时频谱运行时之间找到平衡：Vue在源代码上使用了一定的编译时编译时优化，但选择了更重的编译时回报较小的生成代码。Svelte选择了最小的运行时，但代价是生成的代码更重。Svelte能否进一步改进其代码生成以减少代码输出？Vue能否进一步改进tree-shaking以使基线（运行时框架）更小？另一个框架能否找到更好的平衡点？上述所有问题的答案可能都是肯定的——但现在我们需要弄清楚，“帧大小”是一个比仅仅比较HelloWorld应用程序的大小要微妙得多的话题，这项研究就是为了证明这一点。个人观点以下为作者公众号的个人观点，并非裕达研究中的观点。其实有大总要强调的是，在框架的比较中，单独使用JacekSchae算的RealWord应用有些不公平，应该需要更详细的比较。事实上，关于Svelte包的大小，React和Svelte很早以前就在SvelteGithub上被广泛讨论过。Svelte确实有一个阈值，会在一定级别后使其变小，但一般来说，只要不是特别复杂的中后台管理应用，Svelte应该比其他框架更小。尤其是在一些H5游戏中，如果想用React/Vue以数据驱动的方式编写应用，又不想引入这么大的runtime，确实是一个很好的解决方案。最近在开发一个基于Three.js的移动网页。初步估计，与使用React相比，体积减少了30-50%。无法给出具体值，因为迁移还没有完成。资料齐全。还有一点，非运行时框架对于首屏的渲染也有很大的帮助。您可以拆分第一个屏幕组件。非运行时首屏组件其实很小，这对于移动端来说非常重要。很友好，因为毕竟用SSR对应服务器还是有一定的压力要求的。以上是我看了友达的分析比较后的浅见~如有不足之处，请指出。原创研究文章https://github.com/yyx990803/...回头看看作者之前的高赞文章，说不定还能收获更多！2021前端学习之路书单-自我成长之路：570+点赞从破解一个设计网站谈前端水印（详细教程）：790+点赞本文带你解开“文件”的奥秘层层下载》：140+Likes10个跨域解决方案（有绝招）：940+likesConclusionNotes，一个专注于前端面试、工程、开源的前端公众号
