前言

svelte 是新兴的前端框架，它借鉴了很多前辈的优点，同时也在底层做了新的架构设计。

传统框架无论是 react、vue 的 虚拟DOM ，还是 angular 中 digest 的 脏检查 ，架构上都更偏向于 runtime ，而 svelte 则更偏向于 编译。

这篇文章不会聊到 svelte 自身，而更聚焦在不同的人在面对 svelte 时的上手问题。

上手难度

下面是我目前的总结，后面会简单解释下原因。

• 新手
  • ng > react > svelte > vue
• 老手（熟悉一个框架之后学习新框架）
  • ng > react > vue = svelte
• 后端
  • ng > react > vue > svelte

新手

对于新手而言 ng > react > vue 应该算是前端开发者的共识了，ng 的优点在于全面，上手的难度也来自于全面。而 react 的优点在于灵活，上手难度也来自于灵活。

关于 svelte 而言，我最初是想把它放在和 vue 相等的位置。同样的模板语法，同样 for 、if 指令，带来了类似的上手难度。

但在我真正上手学习时，发现一些问题。

二是 svelte 的文档并不像是面向新手的。比如计算属性，大多数新手并不知道计算属性是做什么的，double 的例子可以很好的描述出计算属性怎么用，但新手很难清楚的知道我们什么时候应该用计算属性，这也是我将 svelte 的上手难度排在 vue 之上的原因。

老手

对于熟悉几大框架之一的开发者而言，svelte 、vue 的功能基本上可以在其他项目上找到类似的功能。同时，它也没有 ng 的的全面带来的难度，没有 react 的灵活性带来的难度。所以它和 vue 基本上是等价的（vue2）。

后端

这里大家一定会好奇为什么后端中 svelte 的上手难度会小于 vue 。下面我将讲讲原因。

首先，对于后端开发者而言，多多少少会接触一些前端代码（HTML、JS、CSS）。基于该层面，后端同学学习 vue 、 svelte 这种模板语法很有优势。 同时， svelte 更偏向于编译而不是 runtime 带来的好处显而易见，我们可以更清楚的看到编译后的代码。并不像传统框架中有太多的黑盒 runtime 操作（虚拟DOM、fiber、diff、digest 等），这种可见性对于后端的学习难度会带来显著的降低。

关于后端开发者上手前端的一些思考

在学习 svelte 的过程中，我发现很多后端开发者对 svelte 赞不绝口。那让我们想想，为什么会造成这种差异？为什么后端开发者对 vue 、 react 、 ng 都有一些抵触？

知乎上的后端发言： 对于我这种，webgl开发者来说，这个svelte真是天使般的存在！因为主要的业务场景都需要在原生dom上绑事件， 还有各种windows document操作, 界面开发上又想具备组件的能力，对我来说就是html style js写在一起！😁做为古董程序员被迫学了下vue react只能好都很牛逼，但都把我的window document隔离了， 逼的我都想自己造个原生dom的组件框架了， 目的很简单， 就是保留我们古董程序员的老物件老知识体系，让 html还是那个html ,js还是那个js, 去掉什么vdom router啥啥啥的新概念！因为我老旧的头脑到现在也没玩明白！ 在一个安静的夜晚…我洗漱完成，孩子睡去，准备造轮子的开始！第一步谷歌上查找相关资料… 无意中就看到了 svelte… 当然这个单词已经触及到我的词汇量盲区了，所以并没在意，直到在github上点了一堆链接又回到了svelte才引起了我的关注，先看作者， 陪感亲切！是我是爱的rollup老哥… 在这里不禁要吐槽一下webpack...是的我知道你们都在用并用得都很开心… 但这东西简直就是跟我的价值观范相… 它那配置的一坨都是什么呀……它那圢包出来的那一坨又是什么呀…… 原谅我并不是职业前端 … 但我还是有些代码洁癖的，包括打包前和打包后，我要清楚的知道我用的这个工具干了什么，不然浑身难受… 所以当时知道rollup后，果断爱上，并且会在使用的过程中感受到去作者价值观上的共鸣！ 说回svelte………… 所以在知道作者是这个老哥的时候我知道我们又想到一块儿去了！！区别是他的牛逼程度只是我的1000 陪而已！ 我还在意淫的时间人家已经搞出来了，而且搞得很牛逼！测试用了用，浑身舒爽……… 没什么华丽的新概率 五分钟上手 html 还是html js 还是js 你不会再在使用window document的时候畏畏缩缩， 还是这个次元的东西， 就给你一个组件开发的能力！ 你可以 import require 或标签合入…… 感觉老年人受到了关爱

通过上面这种类型的回答，我们可以感受到以下问题：

• 高度封装对上手速度的影响（典型的 vue 、 ng 问题）
• 魔法的不可见性
  • svelte 其实有很多魔法操作，但是这些魔法都有一个特点，这个特点就是在上手初期，你是看不到这些魔法的。但当你在写业务的过程中会发现，有一些你不得不使用的魔法操作。
• 通过编译查看到生成的代码
  • 虚拟 DOM 这种 runtime 的代码会导致数据更新的不可见性，因此你不知道你写出来的代码最终的形态是什么。像 vue 的双向绑定、 react 的 fiber 其实都有这种特点。由于这些问题，很少有人会查看 react 、 vue 的编译后代码，因为它们其实不具备太大的参考价值。

最后

这里单论上手难度问题，给大家一些建议。

如果你是 前端开发者 ：我建议你尝试学习一下 svelte ，因为它并没有太多的上手成本，且语法和 vue 极其相似。而且 svelte 编译后的代码会让你对你写的内容有一个直观的体会，了解框架究竟帮你做了什么。

如果你是 后端开发者 ：如果你还未学习其他前端框架，我强烈建议你尝试下 svelte ，它对后端同学的上手速度非常友好，且可以让你的一些想法可以通过该框架快速实现。如果你刚好又想做一些自己的小东西，那就再好不过了。

如果你是 新手开发者 ：我暂时不建议你接触 svelte ，因为它的文档极其不友好。中文文档更新慢是一方面；英文文档方面，它对很多概念是默认你清楚的，这是其二；其三是你在国内能找到好的学习资源很少。最后一点，它对你的求职几乎没有什么好处，国内使用 svelte 的公司太少了。

文章规划

我这里对 svelte 的介绍大概会分为以下几篇文章：

1. svelte 的基础介绍
2. svelte 的上手难度
3. svelte 的架构设计
4. svelte 的框架对比（性能、生态、问题等）
5. svelte 的入门指南
6. svelte 的高阶操作（魔法）

这些文章逐个介绍 svelte 这个框架。由于 《svelte 的基础介绍》 篇，暂时写的还不太满意，先放出来了第二篇 《svelte 的上手难度》 。

在这些文章都完成后，我会合成一篇至少 2W+ 字的 《svelte指南》 合成篇。