等等，你说这个框架有
runtime,额。。。谢谢，我看还是算了吧。 --来自2018年的前端开发者
我们向我们的用户输出了太多的代码。像许多前端开发人员一样，我之前一直在否认这个事实。我认为在页面中加载100kb的javascript代码是正常的，就像使用一张jpg一样。并且一旦你的应用可以与用户交互之后我们真正关心的是它的性能。
但是我错了。100kb的.js不等于100kb的.jpg，影响应用程序性能的不仅仅是网络加载时间，还有解析脚本的时间。而在此期间浏览器完全没有响应。在移动设备上，这些时间会被放大。
如果你不认为这是一个问题，你可以在Twitter上关注Alex Russell，Alex最近没有在框架社区交朋友，但是他没有说错。但是与使用像Angular，React和Ember，Ploymer相反的提议还没有在前端界萌芽。这绝对不是缺乏市场的问题。
也许，我们应该重新思考整件事情。
普遍的认为，框架可以使你更简单的管理复杂的代码：框架通过类似virtual DOM差异算法把复杂的实现细节抽象出来。但是这并不正确，充其量，框架只是把你那些你不得不写的那部分代码和你没有放入你代码中的部分代码移动到了别处。
相反，像React这样的想法是如此粗暴和理所当然的成功的理由是它可以更容易的管理概念的复杂度。框架主要是一个构建你想法的工具，而不是你的代码本身。
假设，要是框架没有实际运行在浏览器会怎样？要是它能把你的应用转化成纯粹的原生Javascript代码，就像babel把ES2015转化成ES5那会怎样？你不需要预先为一个强大的runtime花费运行时间。并且你的应用可以变得非常的快，因为你的应用和浏览器之间没有任何抽象。
Svelte恰好就是这样一个新框架，你可以用HTML，CSS，和Javascript（加上一些小知识点，你花5分钟就能学会）来写一个组件，并且在你构建过程中，Svelte会把它编译成独立的Javascript模块，通过静态分析组件模板，我们可以尽可能的确保浏览器做很少量的工作。
基于Svelte实现了的TodoMVC压缩后仅3.6kb，与之相对的，React加ReactDom没有任何额外代码的情况下压缩后也有45kb。浏览器需要先花上数十倍的时间解析React，才能开始像Svelte一样，运行一个可交互的TodoMVC
一旦你的应用开始启动并运行，根据js框架性能测试，Svelte非常的快，它比React、Vue、Angular、Ember、Ractive、Preact、Riot、Mithril都快，它与Inferno有竞争力，Inferno可能是世界上最快的UI框架，因为Dominic Gannaway是一个魔法师（Svelte在删除元素的时候比较慢，我们正在努力）。
它基本上与原生JS一样快，这是有道理的，因为它就是原生JS，你不需要写的那种原生JS
没错，性能很重要。尽管如此，我们最终可以解决在web开发中这些棘手的问题。这种做法是令人兴奋的。
考虑如何协调工作，想要在你的应用中安装一个cool-calendar-widget（npm install cool-calendar-widget）？如果在以前，你可能只有使用针对你已经使用的框架而设计的这样一个组件。假设cool-calendar-widget是React写的而你正在用Angular，这就成了一个艰难的抉择。但是假设组件的作者用的是Svelte，你能直接使用它，无论你使用了那种技术栈（Todo list这个例子就是将Svelte组件转化成web组件的方法）。
关于代码拆分，这是一个好主意（只需要先加载初始视图所需要的代码，剩下的可以后续再加载）。但是有一个问题：即使最开始只需要一个React组件而不是100个，你仍然需要引入React本身。使用Svelte，代码分割可以更加有效，因为框架嵌入在组件中并且组件很小。
最后，我做为一个开源代码维护者经常遇到难处：你的用户总是希望他们的功能被优先考虑加入，并且低估了这些功能对不需要的用户的成本。框架的作者必须在项目长期健壮和实现用户想要的需求中找寻平衡。这是非常困难的，因为很难预见，代码恶行膨胀的后果。而且需要很专业的软技能来告诉人们（也许是很热心推广你项目的人），他们的功能并不足够重要。但是像Svelte也许就有办法了。许多功能可以被完全的加入，而且不需要考虑不使用他的人。因为如果实现这些功能的代码不需要，那么编译器也不会生成它们。
Svelte还非常新，还有很多的工作需要做，构建工具集成、增加服务端渲染、热更新、更多文档和示范、入门工具等等。