如果你没有参加Svelte峰会，你可以在Svelte Society YouTube页面上了解到。
如果你上个月参加了Svelte峰会，你可能已经看过我的演讲，《未来的网络开发》，在演讲中，我最终回答了关于Svelte最常见的问题之一：Sapper什么时候能发布1.0版？
这有点开玩笑--正如谈话中解释的那样，这实际上更像是对Sapper的重写和重新命名--但它从社区中引发了许多新问题，现在是时候让我们更清楚地了解Sapper的继任者SvelteKit会给你带来什么样的期待了。(注：Sapper是SvelteKit的继任者，SvelteKit是SvelteKit的继任者，现在是时候让大家更清楚地知道，Sapper的继任者SvelteKit会带来什么。)。
Sapper是一个建立在Svelte(一个组件框架)之上的应用程序框架(或元框架)。它的工作是使用所有现代最佳实践(如服务器端呈现(SSR)和代码拆分)轻松构建Svelte应用程序，并提供一个使开发更高效、更有趣的项目结构。它使用基于文件系统的路由(正如NeXT普及的那样，并被许多其他框架采用，尽管有一些增强)--您的项目的文件结构反映了应用程序本身的结构。
虽然Svelte主页和文档鼓励您使用sveltejs/模板库来开始构建应用程序，但Sapper长期以来一直是我们推荐的构建应用程序的方式；这篇博客帖子就是(在撰写本文时！)。使用Sapper渲染。
首先，Sveltejs/Template和Sveltejs/Sapper-Template之间的区别令人困惑，尤其是对于Svelte的新手。使用Svelte建立应用程序的单一推荐方式将带来巨大的好处：我们简化入门，减少维护和支持负担，并有可能开始探索通过拥有可预测的项目结构而释放的新可能性。(最后这一部分故意含糊其辞，因为完全理解这些可能性需要时间。)。
除此之外，我们一直被重写Sapper的想法所吸引。这部分是因为多年来代码库变得有点凌乱(Sapper成立于2017年)，但更主要的原因是最近网络发生了很大变化，是时候重新思考我们的一些基本假设了。
第一个基本假设是，你需要使用像webpack或Rollup这样的模块捆绑器来构建应用程序。这些工具跟踪应用程序的依赖关系图，在此过程中分析和转换代码(例如，将Svelte组件转换为JS模块)，以便创建可以在任何地方运行的代码包。作为Rollup的最初创建者，我可以证明这是一个极其复杂的问题。
几年前，你当然需要一个捆绑包，因为浏览器本身并不支持IMPORT关键字，但现在已经不是那么回事了。现在，我们看到了非捆绑开发工作流程的兴起，这种工作流程非常简单：开发服务器可以按需提供模块(如果需要，可以转换为JavaScript)，而不是急于捆绑你的应用程序，这意味着无论你的应用程序变得多大，启动基本上都是瞬间的。
Snowpack是这一运动的先锋，也是SvelteKit的动力。它的速度惊人地快，并且拥有出色的开发体验(热模块重载、错误覆盖等等)，我们一直在与积雪团队密切合作开发SSR等功能。如果你习惯于使用带有Rollup的Sapper(由于其架构优先考虑最高效的输出，Sapper从未获得过一流的HMR支持)，那么这种火爆的模块重载尤其具有启发性。
这并不是说我们要完全放弃捆绑销售。SvelteKit使用Rollup使你的应用尽可能快速、精简(包括将样式提取到静态.css文件中)，这对优化你的应用程序的生产仍然至关重要，而SvelteKit使用Rollup让你的应用尽可能快、尽可能地精简(包括将样式提取到静态的.css文件中)。
另一个基本假设是，服务器渲染的应用程序需要一个服务器。Sapper实际上有两种模式--Sapper Build和Sapper Export，前者创建一个必须在Node服务器上运行的独立应用程序，后者将你的应用程序烘焙成适合托管在GitHub页面等服务上的静态文件集合。
静态文件几乎可以放到任何地方，但运行Node服务器(以及监视/扩展它等)就不那么简单了。如今，我们正在见证向无服务器平台的转变，在这种情况下，作为应用程序的作者，你不需要考虑你的代码运行在哪台服务器上，以及随之而来的所有复杂性。你可以让Sapper应用程序在无服务器平台上运行，这要归功于Vercel-Sapper这样的东西，但它肯定不是你所说的惯用语言。
它仍然可以创建Node应用程序和完全预渲染(也称为导出)站点