SvelteKit 进入公测阶段

时机已到。经过五个月和数百次提交后，我们终于邀请您来试用 SvelteKit 测试版。它还未完成 — 存在一些已知的 bug 和缺失的功能 — 但我们对它的发展方向非常满意，迫不及待想让您试用。

启动新项目很简单：

# 创建项目
mkdir my-app
cd my-app
npm init svelte@next

# 安装依赖
npm install

# 启动开发服务器并打开浏览器标签页
npm run dev -- --open

您可以在 svelte.dev/docs/kit 找到文档。如果您有想要迁移到 SvelteKit 的 Sapper 应用，可以在 svelte.dev/docs/kit/migrating 找到相关说明。

源代码可在 github.com/sveltejs/kit 获取。在我们完成内部整理工作之前，issue 和 pull request 暂时关闭，但我们很快就会完全开放。

等等，什么是 SvelteKit？

可以把它理解为 Svelte 版的 Next。它是一个使用 Svelte 构建应用的框架，包含服务器端渲染、路由、JS 和 CSS 代码拆分、不同无服务器平台的适配器等功能。

如果您熟悉 Sapper，SvelteKit 是 Sapper 的继任者。

从 Snowpack 到 Vite

在发布视频中，我热情洋溢地赞美了 Snowpack，所以 SvelteKit 最终使用 Vite 可能会让人感到意外。当我们开始思考 SvelteKit 应该采用什么形式时，第一次尝试 Snowpack 就让我们一见钟情。

Snowpack 创造了一个全新的开发工具类别。不同于过去几年我们使用 webpack 和 Rollup 在开发时对应用进行打包，Snowpack 是一个无打包的开发服务器，它使用浏览器原生的 import 并对 Svelte 组件等内容进行实时的一对一转换。因此，您可以获得快速启动、简单的缓存和即时的热模块重载。一旦体验过这种工作方式，其他方式都会让您感到不适。

Vite 属于与 Snowpack 同一类别。虽然 Vite 1 不适合 SvelteKit — 它以 Vue 为中心（Vite 和 Vue 都是由 Evan You 创建的）且使服务器端渲染变得困难 — 但 Vite 2 是框架无关的，并在核心设计中就考虑了 SSR。它还有强大的功能，比如 CSS 代码拆分，这些功能我们之前必须自己实现。当我们并排评估这两种技术时，我们不得不得出结论：Vite 更符合 SvelteKit 的需求，能让我们最有可能实现我们想象中的框架。

我们深深感谢 Snowpack 团队，感谢他们在早期开发阶段的密切合作，以及为未来几年的 Web 开发指明方向。这是一个很棒的工具，您绝对应该尝试一下。

极限运动般的实践检验

SvelteKit 确实还处于测试阶段，但这并不意味着它没有在生产环境中使用。

我的日常工作是在纽约时报，过去的十二个月里，我大部分时间都在开发我们的新冠病毒追踪器。它使用了一个定制版的工作流程，这个工作流程为时报的大多数图表提供支持，但它并不是为大型多页面项目设计的。去年年底，当我们决定为美国约 3,000 个县各创建一个页面时，我们很快意识到需要完全重新架构这个项目。

尽管远未准备就绪，但 SvelteKit 是唯一符合我们特殊需求的框架。（任何在新闻编辑室工作过并与其 CMS 战斗过的人都明白我在说什么。）如今它为我们的县级风险页面提供支持，我们正在将现有页面迁移到 SvelteKit 应用中。

使用未完成的软件来构建一个将被数百万人访问的应用是有风险的，总的来说我不推荐这样做。但这让我们能够更快地开发应用，也使框架本身比原本可能的要强大得多。

通往 1.0 的道路

您可以在我们的问题跟踪器上看到带有 1.0 里程碑的未解决问题列表。除了这些工作外，我们计划更新文档并添加更多适配器。

但最重要的是，我们需要您的反馈来帮助我们打造最好的应用框架。试用它，让我们知道还缺少哪些部分。

非常感谢所有不顾”此处有龙”警告和文档缺失仍然尝试 SvelteKit 的人；你们通过后台渠道提供的反馈非常宝贵。特别要感谢 GrygrFlzr，他维护了非官方文档和一个添加 Windows 支持的分支（当时我们还没有这个支持）；以及 dominikg，他在 Svite 上的工作为 SvelteKit 的 Vite 集成奠定了重要基础。现在他们都已加入团队。