SvelteKit 究竟是怎么回事？

如果你上个月参加了Svelte 峰会，你可能已经看到了我的演讲“未来主义 Web 开发”，其中我最终解决了关于 Svelte 最常被问到的问题之一：Sapper 什么时候会达到 1.0 版本？

答案：永远不会。

这有点儿俏皮话——正如演讲中解释的那样，它更像是对 Sapper 的重写，并伴随品牌重塑——但这引发了社区许多新的问题，现在是时候让我们更清楚地说明你对 Sapper 的继任者 SvelteKit 可以有什么期待了。

什么是 Sapper？

Sapper是一个构建在 Svelte 之上的应用框架（或“元框架”）（Svelte 是一个组件框架）。它的作用是简化构建 Svelte 应用的过程，并使用所有现代最佳实践，例如服务器端渲染 (SSR) 和代码拆分，并提供一个项目结构，使开发既高效又有趣。它使用基于文件系统的路由（如 Next 推广并被许多其他框架采用，尽管有一些增强功能）——项目的文件夹结构反映了应用本身的结构。

虽然 Svelte 的主页和文档鼓励你使用degit 获取sveltejs/template 仓库来开始构建应用，但 Sapper 长期以来一直是我们构建应用的推荐方式；这篇博文本身（在撰写本文时！）就是使用 Sapper 渲染的。

为什么我们要迁移到新的东西？

首先，sveltejs/template 和sveltejs/sapper-template 之间的区别令人困惑，特别是对于 Svelte 的新手来说。拥有一个构建 Svelte 应用的单一推荐方式将带来巨大的好处：我们简化了入门流程，减少了维护和支持负担，并且可以潜在地开始探索由可预测的项目结构带来的新可能性。（这最后一点故意含糊不清，因为完全理解这些可能性需要时间。）

除此之外，我们也一直想重写 Sapper。这部分是因为代码库多年来变得有点杂乱（Sapper 于 2017 年启动），但主要是因为 Web 最近发生了很大变化，是时候重新思考我们的一些基本假设了。

这个新事物有什么不同？

这些基本假设中的第一个是，你需要使用像webpack 或Rollup 这样的模块打包器来构建应用。这些工具跟踪应用的依赖关系图，在此过程中分析和转换代码（例如，将 Svelte 组件转换为 JS 模块），以创建可以在任何地方运行的代码包。

几年前你确实需要一个打包器，因为浏览器不支持import 关键字，但现在情况已经大不相同了。现在，我们看到了无打包开发工作流的兴起，它非常简单：与其急切地打包你的应用，开发服务器可以按需提供模块（必要时转换为 JavaScript），这意味着无论你的应用有多大，启动速度都几乎是即时的。

Snowpack处于这场运动的前沿，它也是 SvelteKit 的动力。它速度惊人，并提供出色的开发体验（热模块替换、错误覆盖等），并且我们一直在与 Snowpack 团队紧密合作，开发 SSR 等功能。如果你习惯于使用带有 Rollup 的 Sapper（由于其架构优先考虑最高效的输出，因此从未有过一流的 HMR 支持），那么热模块替换尤其具有启发意义。

这并不是说我们完全放弃了打包器。优化应用以用于生产仍然至关重要，SvelteKit 使用 Rollup 使你的应用尽可能快且精简（包括将样式提取到静态.css 文件中）。

另一个基本假设是，服务器渲染的应用需要一个服务器。Sapper 有效地具有两种模式——sapper build，它创建了一个必须在 Node 服务器上运行的独立应用，以及sapper export，它将你的应用烘焙成一系列静态文件，适合在 GitHub Pages 等服务上托管。

静态文件几乎可以放在任何地方，但运行 Node 服务器（并对其进行监控/扩展等）则不那么简单。如今，我们正在见证向无服务器平台的转变，在这些平台中，你作为应用作者无需考虑代码正在运行的服务器，以及所有相关复杂性。你可以让 Sapper 应用在无服务器平台上运行，这要感谢诸如vercel-sapper 之类的东西，但这绝对不是你所谓的惯用方式。

SvelteKit 完全拥抱无服务器范式，并将推出对所有主要无服务器提供商的支持，并提供一个“适配器”API，用于定位我们没有正式支持的任何平台。此外，我们将能够进行部分预渲染，这意味着可以在构建时生成静态页面，但动态页面则按需渲染。

我什么时候可以开始使用它？

如果你感觉勇敢，你现在就可以开始了

npm init svelte@next

这将搭建一个新项目并安装@sveltejs/kit CLI，它提供了开发和构建应用的工具。

但是我们不建议这样做！没有文档，我们也无法提供任何形式的支持。它也可能经常出现故障。

这项工作正在一个私有单体仓库中进行，因为我们仍在探索阶段。我们的计划是准备好一个公开测试版，并在解决了一些问题后在这里宣布——该仓库本身届时将保持私有，但我们将创建一个地方来收集来自“YOLO”人群的反馈。之后，我们将努力发布 1.0 版本，这将涉及公开该仓库。

我不会对时间做出任何明确的承诺，因为我不喜欢违背承诺。但我认为我们说的是几周而不是几个月。

如果我不想使用 SvelteKit 呢？

你不需要——始终可以使用 Svelte 作为独立包或通过像rollup-plugin-svelte 这样的打包器集成。我们认为，能够根据你的工作流程（无论多么深奥）灵活使用 Svelte 以及使用像Elder.js、Routify、Plenti、Crown、JungleJS 等第三方应用框架至关重要。

TypeScript？

别担心，我们不会在没有完整 TypeScript 支持的情况下发布。

如何迁移我现有的 Sapper 应用？

在大多数情况下，迁移 Sapper 代码库应该相对简单。

有一些不可避免的更改（能够在无服务器平台上运行意味着我们需要用更可移植的等效项替换自定义server.js 文件和(req, res) => {...} 函数），并且我们正在利用这次机会修复一些设计缺陷，但总的来说，SvelteKit 应用对 Sapper 用户来说会非常熟悉。

详细的迁移指南将随 1.0 版本发布。

我如何贡献？

密切关注有关何时发布公开测试版和公开仓库的公告。（此外，博文待办事项，但我如果忽略了我们现在有一个OpenCollective，你可以在其中为该项目提供经济上的支持（如果它对你有所帮助），那将是我的失职。非常感谢那些已经这样做的人。）

在哪里可以了解更多信息？

在 Twitter 上关注@sveltejs 和@SvelteSociety，并访问svelte.dev/chat。你还应该订阅Svelte Radio，Kevin 和他的联合主持人将在即将播出的一集中询问我有关此项目的问题（以及在现在和我们录制它下周之间，回复此 Twitter 线程，提出你其他的问题）。