Svelte Scraps Sapper to Launch Serverless-First SvelteKit Framework

Svelte Society

Svelte is retiring Sapper in favor of SvelteKit, replacing monolithic development bundles and dual-template friction with unbundled native modules and pluggable adapters for hybrid serverless deployments.

AI-assisted summary of Rich Harris: Futuristic Web Development — original source. Check the original for full context.

Source published: 2020-10-19

Key ideas

Rich Harris announced that Sapper 1.0 will never be released, replacing both Sapper and the basic Svelte template with a unified, officially supported application framework called SvelteKit. (0:00)
SvelteKit adopts an unbundled development server powered by Snowpack, enabling sub-second, state-preserving Hot Module Reloading by compiling files lazily and in isolation via native browser ES imports. (5:29)
Production builds run through a three-phase pipeline—Snowpack unoptimized compilation, Rollup optimization, and adapter generation—enabling seamless deployment targets from Node servers to serverless edge platforms. (12:22)
Developers can implement hybrid rendering within the same application by exporting `export const prerender = true;` on static routes while letting dynamic routes execute on demand in serverless functions. (17:11)
The Svelte project has established an official Open Collective to fund infrastructure costs and eventually compensate open-source contributors directly. (22:06)

Detailed notes

## Background This talk was published by Svelte Society on YouTube on October 19, 2020, following its presentation at Svelte Summit 2020. The session addresses how the frontend ecosystem evolved since the inception of Svelte and Sapper, exploring what a reimagined, modern workflow looks like with the introduction of SvelteKit.

## TL;DR Rich Harris announces that Sapper 1.0 will never be released, unveiling SvelteKit as the single, canonical framework for Svelte applications. SvelteKit leverages Snowpack for unbundled, instant local development and state-preserving hot module reloading, transitioning to Rollup and a pluggable adapter system for optimized production builds. The platform rethinks static exporting by invoking Svelte's server-side rendering API in-process and introduces hybrid rendering that pairs pre-rendered static routes alongside on-demand serverless functions. Harris concludes by addressing migration paths, guaranteed TypeScript support, framework extensibility, and the launch of Svelte's Open Collective.

## Atmosphere & style The presentation blends high-energy technical advocacy with disarming, self-deprecating humor and conversational transparency. Harris moves seamlessly from deadpan humor—delivering the revelation that Sapper 1.0 will never launch—into brisk, live-coding terminal demos that capture the visceral speed of unbundled development. The mood is infectious and communal, underscored by unpolished moments like forgetting to save a configuration file and Harris's visible excitement for the architectural future of Svelte.

## Bulletin - [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) Rich Harris announced that Sapper 1.0 will never be released, replacing both Sapper and the basic Svelte template with a unified, officially supported application framework called SvelteKit. - [05:29](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=329s) SvelteKit adopts an unbundled development server powered by Snowpack, enabling sub-second, state-preserving Hot Module Reloading by compiling files lazily and in isolation via native browser ES imports. - [12:22](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=742s) Production builds run through a three-phase pipeline—Snowpack unoptimized compilation, Rollup optimization, and adapter generation—enabling seamless deployment targets from Node servers to serverless edge platforms. - [17:11](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1031s) Developers can implement hybrid rendering within the same application by exporting `export const prerender = true;` on static routes while letting dynamic routes execute on demand in serverless functions. - [22:06](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1326s) The Svelte project has established an official Open Collective to fund infrastructure costs and eventually compensate open-source contributors directly.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) Sapper's legacy codebase suffered from structural maintainability issues and struggled to support modern paradigms like serverless architectures and selective pre-rendering. - [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) SvelteKit resolves developer confusion by establishing a single canonical starting point (`npm init svelte@next`) for all Svelte applications. - [02:44](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=164s) Scaffolded SvelteKit projects introduce a streamlined layout featuring `src/app.html`, file-based routing in `src/routes/`, and adapter-driven configuration via `svelte.config.js`. - [05:29](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=329s) Hot Module Reloading preserves component state during in-place markup and logic edits without triggering full page reloads. - [06:54](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=414s) Layout components (`layout.svelte`) wrap child routes via default `<slot />` projection, avoiding repetitive boilerplate and eliminating unused CSS warnings. - [06:54](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=414s) SvelteKit blends server-rendered initial HTML for fast startup and SEO with immediate client-side router takeover for instant subpage transitions. - [10:35](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=635s) Traditional bundlers (Webpack, Rollup) create development bottlenecks by traversing and concatenating whole dependency trees, whereas unbundled tools transform individual files on demand. - [12:22](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=742s) Production deployments still require coarse-grained, code-split bundles, leading SvelteKit to use Rollup during phase two of its build pipeline. - [15:08](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=908s) SvelteKit's adapter architecture allows identical application code to target Node servers (`adapter-node`), flat static files (`adapter-static`), or serverless platforms (`adapter-netlify`). - [15:08](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=908s) Static generation in SvelteKit directly invokes Svelte's SSR compiler APIs in-process, eliminating Sapper's slow approach of spinning up a local server and executing a headless crawler. - [17:11](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1031s) Hybrid rendering eliminates the binary choice between a full dynamic server and a pure static site by allowing per-route pre-rendering alongside live serverless endpoints. - [20:03](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1203s) Svelte avoids mandatory lock-in by offering a batteries-included default in SvelteKit while actively supporting custom integration tools like Routify, Elder.js, and Eleventy. - [20:03](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1203s) First-class TypeScript support is planned for SvelteKit's public release. - [22:06](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1326s) An official Open Collective was established to provide financial backing for Svelte's ongoing maintenance, infrastructure, and contributor compensation.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) Rethinking Svelte, the Sapper 1.0 Question, and SvelteKit

Rich Harris opens by admitting that he has not been this excited about Svelte since the launch of Svelte 3. While what he is presenting is still somewhat speculative—noting that the Svelte core team supports the effort, but there are no official guarantees about timelines or features—he feels compelled to share the work. His goals are to share his excitement, manage developer expectations regarding the project's roadmap, and advocate for broader architectural ideas in frontend development that he believes should enter the mainstream.

Addressing the community's persistent questions about the future of Sapper (the Svelte-based application framework providing server-side rendering, routing, and code-splitting), Harris reveals a long-awaited answer: “Sapper 1.0 is coming out... never.” Although Sapper enabled developers to build great apps, its internal architecture had become difficult to maintain over time. Implementing modern capabilities—such as targeting serverless environments or selectively pre-rendering subsets of an app into static files—proved challenging. Furthermore, newcomers were continually paralyzed by the initial choice between the standard Svelte template and Sapper. To solve this friction, the project needed to unify around a single, officially supported development path. As Harris puts it:

> “And so it'd be much better for everyone—users and also people giving support on Discord and Stack Overflow and places like that—if we could give you a single canonical answer: this is the officially supported way to build apps with Svelte.”

- Sapper was initially introduced back in 2017, and the frontend ecosystem shifted dramatically in the intervening years. - Recent maintenance and contributions from developers like Ben McCann significantly improved Sapper, but structural limitations in its codebase remained hard to overcome. - The new unified toolchain will provide a single canonical starting point for all Svelte applications.

---

[02:44](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=164s) Project Tour: Setting Up a SvelteKit App

Starting in an empty terminal directory, Harris scaffolds a brand-new project using the command `npm init svelte@next`, converts it into a Git repository, and installs its dependencies. He jokes about how rapid the initialization is compared to other frontend frameworks.

Exploring the newly created structure reveals a streamlined architecture: - `src/app.html`: A minimal HTML shell featuring injection points for Svelte to populate head tags and body markup. - `src/routes/`: The file-based routing directory, starting with an initial `index.svelte` page that imports a counter component via an alias path (`$components`). - `src/components/`: Directory housing shared UI modules like `Counter.svelte`. - `static/`: Plain static assets served untouched, including `favicon.ico` and `robots.txt`. - `package.json`: Configured with CLI scripts `svelte dev` and `svelte build`, powered by the new engine named `svelte-kit` (provisional naming). - `snowpack.config.js` and `svelte.config.js`: Rather than relying strictly on Rollup during local development, the setup is powered by Snowpack and introduces an "adapter" architecture configured in `svelte.config.js`.

---

[05:29](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=329s) Fast Development Server and Hot Module Reloading

Launching the server via `npm run dev -- --open` brings up localhost:3000 almost instantaneously. Modifying the markup within `Counter.svelte` shows sub-second updates in the browser without losing local component state. Clicking to increment the counter and subsequently modifying the font family (e.g., to "Chalkboard") or font size demonstrates that the state persists throughout code modifications.

Harris highlights that this state-preserving Hot Module Reloading (HMR) experience is largely thanks to the work of community member Rixo. Harris pushes the demo further by altering the click action directly from an increment to a decrement function on the fly, immediately allowing him to decrease the accumulated click counter without triggering a full page reset.

---

[06:54](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=414s) Routing, Layouts, and Hybrid Server/Client Navigation

Expanding beyond a single page, Harris constructs a shared navigation bar in `src/components/Nav.svelte` with links pointing to `/` (home) and an upcoming `/about` page. Adding this component to `index.svelte` immediately reveals the navigation links. Clicking the "About" link at first triggers an expected 404, which he resolves by adding a new route file at `src/routes/about/index.svelte`.

```mermaid flowchart TD accTitle: SvelteKit Layout Wrapping Model accDescr: Diagram showing how src/routes/__layout.svelte wraps individual page routes using default slot projection.

subgraph Shell["src/routes/__layout.svelte"] Nav["<Nav />"] MainOpen["<main>"] Slot["<slot /> (Page Insertion Point)"] MainClose["</main>"] Nav --> MainOpen MainOpen --> Slot Slot --> MainClose end

subgraph Pages["Route Components"] Home["src/routes/index.svelte"] About["src/routes/about/index.svelte"] end

Home -.->|"Renders inside"| Slot About -.->|"Renders inside"| Slot ```

To avoid copying boilerplate structure, markup, and styling between separate routes, Harris introduces `layout.svelte` inside the routes folder: 1. He ports global styles and container wrappers into `layout.svelte`. 2. A single `<slot />` tag is used to mark where child route content renders. 3. The individual `index.svelte` and `about/index.svelte` components are cleaned up to only contain their route-specific content, eliminating unused CSS warnings shown by the compiler.

When navigating between the home and about pages, the browser's reload icon remains stationary because the client-side router handles transitions instantly without requesting fresh full-page HTML. However, opening "View Source" shows that every page is completely rendered on the server during the initial load:

> “So you get the best of both worlds: you get a very fast startup with the static HTML, but then you get instant navigation client-side because the client-side router has kicked in.”

Harris demonstrates that compiling mistakes (such as leaving an HTML tag unclosed) immediately trigger a clean, detailed browser error overlay from Snowpack pointing out the exact problem file and line. Fixing the code causes the overlay to disappear instantly.

---

[10:35](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=635s) Why Unbundled Development Outperforms Traditional Bundlers

Harris steps back from the demo to explain why Snowpack maintains blazing speed regardless of whether a project has two pages or thousands of modules. For years, web development relied on bundlers such as Webpack, Rollup, and Parcel. Those tools operate by reading code, traversing every node in the module dependency tree, and concatenating them into bundled files to run in the browser. While essential when web browsers had no module loading capabilities, today's browsers natively support ECMAScript modules (`import`/`export`).

```mermaid flowchart LR accTitle: Traditional Bundlers vs Snowpack On-Demand Architecture accDescr: Compares full dependency tree bundling to Snowpack on-demand individual file transformation.

subgraph BundlerFlow["Traditional Bundler (Webpack / Rollup)"] direction TB B_Src["Source Modules (1000s)"] --> B_Graph["Trace Complete Graph"] B_Graph --> B_Bundle["Create Combined JS Bundle"] B_Bundle --> B_Browser["Browser Executes Entire Bundle"] end

subgraph SnowpackFlow["Snowpack Modern Architecture"] direction TB S_Req["Browser Native Import Request"] --> S_Transform["Compile Single Requested File"] S_Transform --> S_Out["Serve Individual ES Module"] end ```

Rather than building a monolithic bundle during development, modern unbundled tools like Snowpack transform files in isolation: - TypeScript is transformed directly to JavaScript. - `.svelte` components are transformed via the Svelte compiler into standard JavaScript modules without being stitched together. - The browser fetches dependent modules directly via native ES import statements. - Transformations are performed lazily and on-demand: files are only compiled when the browser actually requests them for the current view. - When an individual file is updated, only that isolated file undergoes re-transformation, avoiding the expensive cache-checking and rebundling cycles characteristic of traditional bundlers.

[12:22](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=742s) Unbundled Development and the Three-Phase Production Build

Rich Harris explains that unbundled tools like Snowpack fundamentally change the local development workflow because they avoid full-application bundling cycles. When an individual file is edited, Snowpack simply hands the new module to the browser, which fetches and swaps it in using Hot Module Replacement (HMR). Because transforming a single file in isolation is practically instantaneous, reload speeds outclass anything traditional bundlers can deliver. Rich takes a playful jab at the broader ecosystem, remarking: “I think we're going to get to a point pretty soon where projects that use bundlers during development are going to seem a little bit antiquated looking at you other frameworks.”

However, sending hundreds of separate ES modules across the network in production remains inefficient. Production deployments still require coarse-grained, code-split chunks. Before walking through this workflow in SvelteKit, Rich takes a moment to thank Fred Schott and the Snowpack team, calling Fred the genius behind the project and praising their productive collaboration in adapting Snowpack for server-side rendering frameworks.

Running `npm run build` in SvelteKit executes a distinct three-phase build pipeline:

```mermaid flowchart TD accTitle: SvelteKit Three-Phase Build Pipeline accDescr: Diagram showing the flow from source modules through Snowpack unoptimized build, Rollup optimization, to output adapters.

subgraph Phase1["Phase 1: Unoptimized Build"] A["Source Modules"] -->|"Snowpack 1:1 transforms"| B["Client Modules"] A -->|"Snowpack 1:1 transforms"| C["SSR Server Modules"] end

subgraph Phase2["Phase 2: Optimization"] B & C -->|"Bundle through Rollup"| D["Route Chunks & Shared Code"] D --> E["Manifest & CSS Assets"] end

subgraph Phase3["Phase 3: Generation"] E --> F{"Configured Adapter"} F -->|"adapter-node"| G["Node Server Build"] F -->|"adapter-static"| H["Static HTML Files"] F -->|"adapter-netlify / cloud"| I["Serverless Functions & Static CDN"] end ```

- **Phase 1 (Unoptimized Build):** Runs every module through Snowpack via direct one-to-one transformations, creating separate, unbundled client and server (SSR) versions of the application code. - **Phase 2 (Optimization):** Feeds that unbundled output into Rollup, which bundles the code into optimized chunks representing the routes, creates shared dependencies, manages CSS extraction, and generates an asset manifest. - **Phase 3 (App Generation via Adapters):** Handed off to a designated adapter defined in `svelte.config.js`.

[15:08](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=908s) Adapters and Faster Static Exporting

The target environment is governed by adapters. By default, SvelteKit uses `adapter-node`, which outputs a standalone Node server analogous to the legacy `sapper build`. However, if an application consists purely of static routes—such as a simple demo with an index route (`/`) and an about page (`/about`)—a running Node runtime is unnecessary. Rich switches the project configuration to `adapter-static`, installs the package, and reruns `npm run build` (after pausing with a laugh to actually save the edited config file so the build picks it up).

The adapter generates 200 HTTP responses for both `/` and `/about`, writing out plain HTML files (`index.html` with "hello world" and `about/index.html`). Rich contrasts this against the traditional `sapper export` process. Sapper previously had to compile a complete Node server, spin that server up locally, and run a web crawler against localhost to capture the generated pages. In contrast, SvelteKit invokes Svelte's internal SSR API directly in-process. Eliminating the server spinning and HTTP crawl makes static pre-rendering dramatically faster and capable of handling sites with massive volumes of content with minimal overhead.

- `adapter-node` mimics standard server deployments for dynamic Node hosting. - `adapter-static` produces flat files without requiring an intermediary server crawl. - Direct invocation of Svelte’s SSR compiler APIs replaces the older, sluggish headless crawling technique used by Sapper.

[17:11](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1031s) Hybrid Rendering and Serverless-First Architecture

A longstanding dilemma in Sapper was the strict divide between dynamic hosting and full static generation: developers were forced to choose between running a dynamic Node server for everything or statically exporting the whole site. The dynamic approach wasted compute re-rendering pages that never changed, while static export failed completely if the site had dynamic data or authenticated, personalized views. SvelteKit solves this by supporting hybrid applications similar to modern versions of Next.js, allowing developers to mix dynamic server-rendered routes and pre-rendered static routes within the exact same app.

To showcase this, Rich demonstrates a Svelte implementation of Hacker News running locally. Top stories, new items, and comment pages fetch live data directly from `api.hnpwa.com` and must be dynamically rendered on demand. Conversely, the site’s About page is completely static. Because computers cannot reliably infer whether a route depends on changing state, developers supply an explicit cue: exporting `export const prerender = true;` from the page component. When `npm run build` executes, the compiler identifies this flag, pre-renders `/about` into `build/prerendered/about/index.html`, and leaves the remainder dynamic. When the production app starts, requests for `/about` serve raw static assets without touching the rendering engine.

Rich emphasizes that this hybrid model is tailor-made for cloud edge platforms:

> “When we launch this thing we'll have adapters for all of the major services the whole serverless thing it's a pretty good trend and Svelte is now a serverless first framework yay so this really just scratches the surface of what we can do in this new world.”

Using an adapter like `adapter-netlify`, SvelteKit automatically splits the production artifact, routing static files directly to the CDN and packaging dynamic routes into individual serverless functions.

[20:03](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1203s) Project Scope, Framework Philosophy, and Ecosystem FAQs

Rich explores future possibilities opened up by the new project layout, such as using the exact same SvelteKit template structure to author and package standalone component libraries alongside full-fledged web applications. He then tackles anticipated community questions:

- **Migration from Sapper:** While not 100% automated, migrating will be straightforward because project layout and high-level routing concepts closely parallel Sapper. - **Workflow Mandates:** Developers are never locked into SvelteKit. Rich highlights the philosophical split in the frontend world: monolithic meta-frameworks like Angular and Ember that strive to own the entire developer workflow, versus component-only libraries like React and Vue that leave app-level tooling to ecosystem solutions like Next.js, Gatsby, or Remix. Svelte intentionally straddles both:

> “I want Svelte to be both of those you can be wildly productive with this app template in a matter of seconds but if you're a power user with specific needs that aren't met by this template for whatever reason then those needs will continue to be met by the Svelte project.”

- Custom integrations remain first-class citizens, preserving support for tools like Eleventy (11ty) plugins and dedicated Svelte-based application frameworks such as Routify and Elder.js. - **TypeScript Support:** Although not yet wired into the internal prototype repository, full first-class TypeScript support is guaranteed for the public launch. - **Contributing:** Development is currently progressing within a private repository while core architecture stabilizes. Community members are encouraged to follow discussions on the Svelte Discord (`svelte.dev/chat`) and updates via the `@sveltejs` and `@SvelteSociety` Twitter accounts.

[22:06](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1326s) Funding Svelte on Open Collective

Rich closes the presentation by revisiting a recurring question from earlier in the year regarding financial contributions. While there was previously no official mechanism to donate money to Svelte, the team has now launched an official Open Collective page (`opencollective.com/svelte`).

Rich explains that while the exact long-term distribution of funds is still being determined, donations immediately help offset the infrastructure and operational costs of maintaining an open-source project of this scale. In the future, funds may allow the project to directly compensate contributors to build specific framework features. He extends deep gratitude to community members who discovered the Open Collective page and signed up as financial backers even before an official public announcement had been made, before humorously trying to figure out how to turn off his presentation recording.

## Notable quotes > [12:22](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=742s) I think we're going to get to a point pretty soon where projects that use bundlers during development are going to seem a little bit antiquated looking at you other frameworks. — Rich Harris

> [06:54](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=414s) So you get the best of both worlds: you get a very fast startup with the static HTML, but then you get instant navigation client-side because the client-side router has kicked in. — Rich Harris

> [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) It'd be much better for everyone—users and also people giving support on Discord and Stack Overflow and places like that—if we could give you a single canonical answer: this is the officially supported way to build apps with Svelte. — Rich Harris

## Mentioned Rich Harris, Svelte, Svelte 3, Sapper, SvelteKit, Ben McCann, Rixo, Fred Schott, Snowpack, Rollup, Webpack, Parcel, Next.js, Gatsby, Remix, Angular, Ember, React, Vue, Eleventy (11ty), Routify, Elder.js, Netlify, Node.js, Open Collective, Discord, Stack Overflow, Hacker News

## Video description Edit from the future: check out our followup podcast interview on SvelteKit https://share.transistor.fm/s/859bbd95

--- This was recorded for Svelte Summit 2020: https://www.sveltesummit.com

The front end development landscape has been transformed since we started building Svelte and Sapper. What would a reimagined, truly modern workflow look like?

Open Collective: https://opencollective.com/svelte

[Source](https://www.youtube.com/watch?v=qSfdtmcZ4d0)

中文简报

Svelte 放弃 Sapper，推出 Serverless 优先的 SvelteKit 框架 Svelte 正在淘汰 Sapper 并由 SvelteKit 取代，用非打包原生模块和用于混合 Serverless 部署的可插拔适配器，替代原有的单体开发打包与双模板摩擦。 Rich Harris 宣布 Sapper 1.0 将不再发布，并公布了 SvelteKit 作为 Svelte 应用程序的唯一定范框架。SvelteKit 利用 Snowpack 实现非打包、即时的本地开发以及保留状态的热模块重载，并在生产构建中过渡到 Rollup 和可插拔适配器系统进行优化。该平台通过在进程内调用 Svelte 的服务端渲染 API 重新思考了静态导出，并引入了将预渲染静态路由与按需调用的 Serverless 函数相结合的混合渲染。Harris 最后阐述了迁移路径、确定的 TypeScript 支持、框架可扩展性以及 Svelte 的 Open Collective 的启动。 Rich Harris 宣布 Sapper 1.0 将永远不会发布，由一个名为 SvelteKit 的统一、官方支持的应用程序框架同时取代 Sapper 和基础 Svelte 模板。 (0:00) SvelteKit 采用了由 Snowpack 驱动的非打包开发服务器，通过浏览器原生 ES 导入实现文件的惰性与隔离编译，从而实现亚秒级且保留状态的热模块重载。 (5:29) 生产环境构建采用三阶段流水线——Snowpack 未优化编译、Rollup 优化以及适配器生成——实现从 Node 服务器到 Serverless 边缘平台的无缝部署目标。 (12:22) 开发者可以在同一应用中实现混合渲染，方法是在静态路由上导出 `export const prerender = true;`，同时让动态路由按需在 Serverless 函数中执行。 (17:11) Svelte 项目已建立官方 Open Collective，用以资助基础设施成本，并最终直接为开源贡献者提供报酬。 (22:06)

Reading summary

Rich Harris announced that the Svelte core team is replacing the legacy Sapper framework with SvelteKit, a unified development toolchain designed to resolve architectural maintenance challenges, accelerate local builds, and support modern serverless hosting. Retiring Sapper for a Unified Architecture (0:00) Harris confirmed that Sapper 1.0 will never be released, explaining that the 2017-era framework had accumulated architectural limitations that made it difficult to maintain and integrate with modern serverless workflows. Newcomers also faced confusion when deciding whether to start projects with basic Svelte templates or Sapper. SvelteKit was introduced to provide a single, canonical, officially supported path for Svelte application development, while retaining Sapper's high-level file-based routing and layout concepts to keep migration straightforward. Unbundled Development and Faster Local Reloads (5:29) Instead of relying exclusively on Rollup or Webpack to bundle entire module graphs during development, SvelteKit adopts modern unbundled tooling via Snowpack. Modern browsers natively support ECMAScript modules, allowing the dev server to transform files such as TypeScript and Svelte components lazily and in isolation upon browser request. This setup achieves instantaneous server start times and sub-second Hot Module Replacement (HMR) that preserves component state during code edits, avoiding the expensive cache-checking and rebundling cycles typical of traditional bundlers. Three-Phase Build Pipeline and Modular Adapters (12:22) To balance rapid local compilation with production efficiency, SvelteKit implements a three-phase build process: Snowpack performs unoptimized one-to-one transforms for client and server code, Rollup optimizes and bundles code-split chunks with CSS assets, and dedicated adapters generate the final platform output. Target environments are decoupled via packages configured in svelte.config.js, including adapter-node for standard server setups and adapter-static for flat export. Static generation in SvelteKit directly invokes Svelte's internal server-side rendering API, bypassing Sapper's slower method of running an HTTP crawler against a local server instance. Hybrid Serverless Deployment and Framework Scope (17:11) Addressing Sapper's rigid divide between dynamic hosting and full static export, SvelteKit supports hybrid applications where individual routes can be pre-rendered alongside dynamic, data-driven endpoints. Developers can explicitly export `prerender = true` on static views, which adapters like adapter-netlify can automatically direct to a CDN while routing dynamic paths into separate serverless functions. Harris emphasized that while SvelteKit offers an opinionated application framework, Svelte will continue supporting low-level tooling and third-party frameworks like Routify, Elder.js, and Eleventy. While the SvelteKit codebase remains in prototype status within a private repository and public release timelines remain unspecified, the team committed to delivering full TypeScript support at launch and has established an Open Collective page to fund ongoing open-source infrastructure and development costs.

精炼阅读摘要

Svelte 创建者 Rich Harris 宣布停止开发 Sapper 1.0，转而推出新一代应用开发框架 SvelteKit。该框架旨在终结社区在基础模板与 Sapper 之间的选择分歧，通过免打包（unbundled）开发服务器、进程内静态渲染与适配器架构，确立 Svelte 官方统一且面向无服务器（serverless）的工程标准。弃用 Sapper 与确立官方统一入口 (0:00) Harris 明确表示 Sapper 1.0 将不会发布。Sapper 自 2017 年推出以来，虽然在 Ben McCann 等社区成员的维护下持续演进，但其底层代码架构已难以满足现代前端需求，尤其是在适配无服务器运行环境和页面局部按需预渲染方面存在硬性瓶颈。技术架构之外，新用户长期在基础 Svelte 模板与 Sapper 框架之间面临选择困境，导致 Discord 和 Stack Overflow 等渠道的社区支持产生撕裂。Harris 指出，核心团队必须为 Svelte 提供唯一的官方推荐方案，通过统一的脚手架消除初期决策摩擦，并建立标准化的长期迭代基础。基于原生 ES 模块的免打包本地开发 (10:35) 传统开发服务器（如 Webpack 或 Rollup）要求遍历整棵依赖树并完成打包后才可运行，导致大型项目的重载耗时严重。SvelteKit 借助 Snowpack 采用了免打包的开发模式，利用现代浏览器原生支持 ECMAScript 模块（import/export）的特性，在本地开发阶段实现完全按需的单文件独立转译。在该模式下，TypeScript 与 `.svelte` 组件仅在浏览器实际请求当前视图时触发独立编译，无需将各模块拼接为单一产物。配合社区开发者 Rixo 实现的状态保留热模块替换（HMR），开发者修改样式或交互逻辑时，浏览器可在亚秒级完成更新且不丢失组件局部状态。Harris 认为，未来本地开发仍依赖打包器的框架将逐渐显得陈旧。三阶段构建流水线与可插拔适配器 (12:22) 针对免打包模式无法直接用于生产环境网络传输的问题，SvelteKit 设计了清晰的三阶段构建流程（npm run build）：第一阶段由 Snowpack 分别转译客户端与服务端渲染（SSR）的非打包代码；第二阶段由 Rollup 执行依赖分析与代码分割，提取 CSS 并生成资源清单（manifest）；第三阶段则交由指定的适配器生成最终部署产物。在输出阶段，适配器（Adapters）彻底解耦了构建产物与部署平台。不同于 Sapper 依靠本地启动 Node 服务并通过网络爬虫抓取页面的静态导出方案，SvelteKit 的 adapter-static 直接在进程内调用 Svelte 编译器的 SSR API，大幅提升了海量页面静态预渲染的效率；同时 adapter-node 则负责生成标准的独立 Node 服务器产物。混合渲染与无服务器优先架构 (17:11) Sapper 过去迫使开发者在全动态 Node 服务与全静态导出之间二选一，造成动态部署浪费算力去重复渲染静态内容，而纯静态方案又无法承载动态数据。SvelteKit 引入了混合渲染模型，允许在同一个应用内自由组合动态服务端渲染页面与预渲染静态页面。在 Hacker News 示例中，高频变更的动态列表正常执行服务端请求，而静态页面只需显式声明 export const prerender = true 标记，编译器便会在构建期将其提前写入静态文件。结合 adapter-netlify 等云适配器，系统可自动将预渲染静态文件分发至 CDN 边缘，并将动态路由独立打包为无服务器函数，使框架天然具备无服务器优先的特性。生态定位、迁移兼容与资金支持 (20:03) 针对生态选型，Harris 阐释了 Svelte 的折中哲学：既不完全照搬 Angular、Ember 这种全面接管工作流的重型元框架，也不像 React、Vue 那样将应用级工程完全留给第三方生态。Svelte 旨在提供高生产力官方模板的同时，保持核心解耦，继续兼容 Eleventy 插件以及 Routify、Elder.js 等第三方框架。在工程落地方面，SvelteKit 的目录与路由设计与 Sapper 高度对应，迁移路径相对明确，且正式发布时将提供一等公民级别的 TypeScript 支持。针对项目长期维护，团队正式上线了 Open Collective 官方资助页面，所筹资金初期用于覆盖基础设施与运营开销，未来计划直接资助开发者负责特定核心特性的研发。 Harris 强调，SvelteKit 代表了团队推动现代前端架构标准化的重要尝试，但在演讲发表时该项目仍处于私有仓库的内部开发阶段，具体发布时间表与功能落地仍存变数。免打包本地开发在生产端构建适配中的长期稳定性，以及社区现有 Sapper 项目的实际迁移体验，仍有待公测后进一步验证。

Detailed notes — zh

## Background 该视频由 Svelte Society 官方频道于 2020 年 10 月 19 日发布在 YouTube 上，为 Svelte Summit 2020 大会的演讲录播。视频简介指出，自团队最初构建 Svelte 与 Sapper 以来，前端开发格局已发生巨变，本场演讲旨在探讨一套重新构想的、真正现代化的全新工作流。 ## TL;DR Rich Harris 正式宣布放弃推出 Sapper 1.0，转而推出新一代官方全栈框架 SvelteKit。该框架基于现代浏览器原生 ESM 和 Snowpack 开发服务器，彻底摒弃了本地开发阶段沉重的打包器，带来极速冷启动与状态保持的 HMR 体验。在构建层面上，SvelteKit 采用“未优化直转、Rollup 优化打包、Adapter 目标适配”的三阶段架构，支持纯静态生成、Node 服务与 Serverless 混合渲染，同时兼顾极致性能与灵活部署。 ## Atmosphere & style 整个演讲充满着技术突破带来的兴奋感与极客幽默，Rich Harris 的语调亲切且充满自信，现场演示一气呵成。开场直言“Sapper 1.0 永远不会发布”制造了戏剧性反差，随后通过终端毫秒级启动与热更新展示，将氛围推向惊艳的高潮。从宏观的技术哲学剖析到落幕时手忙脚乱寻找录屏关闭按钮的滑稽碎碎念，整场分享既有洞察未来的技术远见，又流淌着开源社区独有的随性与真诚。 ## Bulletin - [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) Svelte 官方宣布废弃 Sapper 且永远不会发布 1.0 版本，转而推出新一代全栈开发框架 SvelteKit（由 svelte-kit 驱动）。 - [10:08](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=608s) SvelteKit 本地开发彻底弃用传统打包器（Bundler），采用基于现代浏览器原生 ESM 的 Snowpack 实现按需编译与毫秒级热更新（HMR）。 - [13:58](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=838s) 构建体系引入适配器（Adapter）架构，三阶段流程将模块经 Rollup 代码分割后无缝部署至 Node.js、纯静态或 Serverless 云函数。构建还支持通过简单导出 prerender 标记实现动静混合渲染。 - [20:16](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1216s) SvelteKit 承诺正式发布时原生支持 TypeScript，且官方强调 Svelte 核心层仍保持完全开放，不会强制捆绑全栈方案。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) Sapper 正式终结，SvelteKit 诞生旨在解决代码库维护困难、缺乏 Serverless 原生支持以及初学者在基础模板与 Sapper 之间选择困难的痛点。 - [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) Svelte 团队希望提供一个官方唯一推荐的标准全栈开发工作流，统一定位现代 Svelte 应用构建范式。 - [02:44](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=164s) 通过 npm init svelte@next 可实现极速脚手架初始化，默认采用 app.html 宿主模板、基于文件系统的路由以及通过别名访问组件的标准项目架构。 - [05:29](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=329s) SvelteKit 兼顾了 SSR（服务端渲染）的毫秒级首屏加载优势与客户端路由（Client-side Navigation）带来的即时跳转体验。 - [05:29](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=329s) 借助社区贡献的高质量 HMR（模块热替换），开发者在修改 UI 样式或核心响应式逻辑时能够完全保留应用运行时状态。 - [10:08](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=608s) 传统打包器（Webpack/Rollup/Parcel）在修改代码时需重复遍历依赖图并重新打包，而基于原生 ESM 的工具通过按需单文件转换实现近乎瞬时的本地响应。 - [12:22](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=742s) 虽然本地开发无需打包，但生产环境依然依赖 Rollup 将代码聚合成带代码分割的粗粒度 chunk，以规避海量细碎模块在网络请求中产生的延迟瓶颈。 - [13:58](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=838s) SvelteKit 构建划分为三个清晰阶段：Snowpack 未优化单文件直转、Rollup 优化打包与代码分割，以及针对部署目标的 Adapter 适配生成。 - [13:58](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=838s) 全新静态导出机制直接调用 Svelte SSR API 进行一次性高效渲染，摒弃了旧版 Sapper 必须启动 Node 服务并派爬虫遍历页面的繁琐做法。 - [16:54](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1014s) SvelteKit 支持混合渲染模式（Hybrid Apps），开发者仅需在对应页面声明 export const prerender = true 即可将静态页面预渲染生成为 HTML。 - [16:54](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1014s) Svelte 转型为 Serverless 优先框架，通过 Netlify 等平台适配器可自动将静态资产交由 CDN 分发，将动态逻辑打包为独立云函数运行。 - [20:16](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1216s) 针对从 Sapper 迁移的顾虑，Rich Harris 确认二者在目录设计与核心概念上高度一致，虽无法全自动化但整体迁移将相当直观。 - [20:16](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1216s) 在框架生态哲学上，Svelte 希望兼具高度开箱即用性与模块化自由度，持续全力兼容 Routify、Elder.js 以及 11ty 插件等第三方定制方案。 - [20:16](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1216s) Svelte 正式上线 Open Collective 接受社区赞助，筹集资金将用于保障开源基础设施的稳定运行并为核心特性的全职研发提供资助。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=0s) Sapper 1.0 的终结与 SvelteKit 的诞生背景 Rich Harris 开场便表达了极其强烈的情绪：“I haven't been this excited about Svelte since probably the launch of Svelte 3”。他坦言，展示的内容在当时仍带有探索和推测性质，并非官方正式声明，但整个 Svelte 核心团队知晓并支持这项工作。虽然不能对发布时间与最终形态作绝对保证，但他之所以决定公开分享，是因为这不仅关乎回应社区对项目走向的普遍疑问、管理开发者的预期，更关乎推动整个前端 Web 开发未来的新理念。话题迅速切入长久以来困扰社区的痛点——Sapper。作为基于 Svelte 的全栈应用框架，Sapper 提供了服务端渲染（SSR）、路由和代码分割等能力，社区最常问的问题就是“Sapper 1.0 什么时候发布”。对此，Rich Harris 直截了当地公布了答案：“SAPA 1.0 is coming out... never. No seriously it's not coming out. There isn't going to be a SAPA 1.0.” 尽管他对 Sapper 充满感情且社区也用它开发了许多出色应用，但在他看来，现存方案必须被彻底超越。 Sapper 项目自身积累了许多结构性问题： - **代码库维护困难**：代码底层相当棘手（gnarly），即便近期有 Ben McCann 等贡献者的积极介入，其架构仍难以扩展。 - **缺失现代云原生能力**：很难优雅地支持构建面向 Serverless 平台的应用，或针对静态文件进行子集预渲染（pre-rendering）。 - **新手心智负担过重**：初学者进入 Svelte 生态时，第一个面临的抉择就是“该用基础模板还是用 Sapper”，这种割裂极具困扰性。Rich 强调，社区与技术支持最需要的是一个官方推荐的标准答案：“this is the officially supported way to build apps with Svelte.” - **前端工具链的技术迭代**：Sapper 始于 2017 年，如今前端开发工具链已经发生了翻天覆地的变化，团队拥有了从零重新构想现代开发工作流的契机。 --- ### [02:44](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=164s) 极速初始化与全新项目架构解析 Rich Harris 开始进入终端现场演示。他在一个空白目录下运行了初始化命令： ```bash npm init svelte@next ``` 完成项目初始化、配置 Git 仓库并安装依赖的过程极为迅速。他调侃道：“I would show you how long the equivalent setup would take for other frameworks but I don't want this to be a really long video.” 随后他深入拆解了新项目的目录架构： ```mermaid flowchart TD accTitle: SvelteKit Project Structure accDescr: High-level overview of files and directories in a new SvelteKit project. subgraph Root["项目根目录"] direction TB Pkg["package.json<br/>(svelte-kit, dev/build 脚本)"] SnowpackCfg["snowpack.config.js<br/>(无打包构建工具)"] SvelteCfg["svelte.config.js<br/>(适配器 Adapter 配置)"] end subgraph StaticDir["static/ (静态资源)"] Favicon["favicon.ico"] Robots["robots.txt"] end subgraph SrcDir["src/ (源码)"] direction TB AppHTML["app.html<br/>(注入 head 与 body 插槽)"] Routes["routes/<br/>(文件路由，如 index.svelte)"] Components["components/<br/>(通过 $components 别名访问)"] end Root --> SrcDir Root --> StaticDir ``` - **`src/app.html`**：最基础的标准 HTML 页面，带有供 Svelte 注入 head 标签与 body 内容的微型插槽占位符。 - **`src/routes/`**：沿用基于文件系统的路由系统，当前仅包含单一页面 `index.svelte`。 - **别名导入机制**：代码中通过 `$components` 别名直接引用组件（例如计数器组件），避免多层相对路径。 - **`static/`**：存放无需构建处理直接原样部署的文件，如 `favicon.ico` 和 `robots.txt`。 - **`package.json`**：脚本命令 `svelte dev` 和 `svelte build` 均由一个名为 `svelte-kit` 的新包驱动。 - **工具链配置**：配置中显式出现了 `snowpack.config.js` 与 `svelte.config.js`。Rich 指出，此时本地开发阶段并没有使用传统的打包器（Bundler），而是直接基于 Snowpack，并在 Svelte 配置中引入了全新的“适配器”（Adapter）概念。 --- ### [05:29](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=329s) 毫秒级启动、状态保持 HMR 与布局系统在终端执行开发指令 `npm run dev -- --open` 后，本地开发服务器在 `localhost:3000` 上几乎在一瞬间完成启动。Rich 演示了热模块替换（HMR）的极致流畅感：在修改 Counter 组件的文案、按钮字体（如换成 Chalkboard 字体并放大）乃至修改逻辑（由递增改为递减）时，页面状态均被完整保留下来。Rich 将这套高质量的 HMR 体验归功于社区核心贡献者：“we now have really good hot module reloading courtesy of Rixo who's been working really hard on this and has done an incredible job.” 随后他演示了应用的路由扩展与组件组织： 1. **添加全局导航**：在 `src/components/` 下新建 `nav.svelte`，写入首页 `/` 与即将创建的 `/about` 页面的超链接，并在 `index.svelte` 的 main 区块中引入。 2. **创建新路由与 404**：直接点击导航中的 About 触发了 404 页面，随后他在 `src/routes/about/index.svelte` 新建页面文件，路由立即生效。 3. **抽取全局布局**：为了消除不同页面间重复写样式的麻烦，Rich 引入了继承自 Sapper 的布局机制，新建 `src/routes/$layout.svelte`（源码中为 `layout.svelte`）。在布局文件中保留外层结构与样式，并通过 `<slot></slot>` 留出页面内容插槽；移除 `index.svelte` 与各子页面中的冗余包裹和未使用 CSS 规则。在页面跳转体验上，Rich 指出浏览器顶部的刷新图标没有任何转动，这表明整个路由跳转完全是在客户端通过 JavaScript 瞬间完成的（Client-side Navigation）。与此同时，该架构完美兼顾了服务端渲染（SSR）。通过“查看网页源代码”（View Source），HTML 中直接包含服务端预渲染好的文本内容。Rich 总结这一结合的优势：“So you get the best of both worlds you get a very fast startup with the static HTML but then you get instant navigation client-side because the client-side router has kicked in.” --- ### [10:08](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=608s) 基于原生 ES 模块的 Snowpack 构建革新除了快速渲染，工具链的开发排错体验也得到了极大增强。Rich 刻意在组件中写错标签闭合语法，页面上立刻弹出了清晰的错误蒙层（Error Overlay），精准指示了出错代码的位置，保存修复后蒙层瞬时隐去。针对为什么系统能达到这种惊人速度，Rich 解释道，这绝非因为当前 Demo 规模小，而是架构底层的根本转变决定的：“the way that it's designed it will continue to be that fast even if you have a huge site with hundreds of pages and thousands of components”。他回顾了前端过去数年的打包器历史与现代浏览器的演进： ```mermaid flowchart LR accTitle: Bundler vs Native ESM Dev Server accDescr: Comparison between traditional bundler rebundling and Snowpack on-demand native ESM transformation. subgraph Bundler["传统打包器 (Webpack / Rollup / Parcel)"] direction TB B1["扫描完整依赖图谱"] --> B2["拼接/打包为 Bundle 文件"] B3["局部文件变更"] --> B4["重算依赖并重新打包 (Rebundle)"] end subgraph Modern["新一代方案 (Snowpack / 原生 ESM)"] direction TB M1["按需单文件转换<br/>(TS -> JS, Svelte -> JS)"] --> M2["浏览器根据原生 import 请求模块"] M3["局部文件变更"] --> M4["仅单独重新编译被改动的文件"] end ``` - **传统 Bundler 的瓶颈**：以往由于浏览器不支持模块化规范，Webpack、Rollup 以及 Parcel 等工具必须从入口文件开始，顺着 `import` 语句爬取整棵依赖图，最后将所有代码拼装合并成浏览器能执行的单一或多块 Bundle 脚本。一旦某一个文件被修改，即便带有极为精密的缓存机制，打包器依然必须耗费额外算力去执行“重新打包”（Rebundle）。 - **原生 ESM 带来的转变**：现代浏览器已全面原生支持 ES 模块（Native ES Modules）。Snowpack 等工具在开发时不再进行打包拼接，只做轻量的单文件转换——例如将 TypeScript 编译成 JavaScript，或者调用 Svelte 编译器将 `.svelte` 转换成 JS 模块。它将依赖模块的拉取逻辑彻底交给浏览器的原生 `import` 机制。 - **按需编译（On-demand）的威力**：服务器根本无需在启动时预先转换全部代码，唯有当浏览器实际发出资源请求时，才会即时编译对应的模块。开发者哪怕面对包含数千个组件的巨型应用，开发当前页面时也只需编译眼前用到的少数几个模块，开发服务器的响应因此得以始终维持在瞬时水准。 ### [12:22](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=742s) Snowpack 与基于原生 ESM 的极速开发体验 Rich Harris 解释了 Snowpack 等新型免打包工具在本地开发时的巨大优势。传统的打包器在修改文件后往往需要重新遍历、解析整个依赖图并重新打包，而 Snowpack 完全不需要做这些繁重的操作。当开发者修改一个文件时，Snowpack 仅需将这一处变更转换并告知浏览器：“这是新文件，请加载它。”浏览器通过原生的 ESM（ES 模块）机制拉取该模块，若配置了 HMR（Hot Module Replacement，模块热替换），就地替换掉已有模块，整个更新流程便宣告结束。由于编译单个模块通常快如闪电，本地重载与反馈速度快到“任何打包器都无法望其项背”。Rich 预测在不久的将来，开发环境依然依赖传统打包器的项目会显得有些过时，并打趣道：“looking at you other frameworks.”（正看着你们呢，其他框架们）。 ```mermaid flowchart LR accTitle: Snowpack 开发服务器与浏览器更新流程 accDescr: 展示修改单个文件后 Snowpack 仅进行单文件转换并通过原生 ESM 推送至浏览器的极简链路。 subgraph Dev["本地开发环境"] F["修改单一文件"] --> S["Snowpack 单文件转换"] end subgraph Browser["浏览器端"] S -->|"推送新模块"| B["浏览器抓取新模块"] B -->|"原生 ESM / HMR"| R["仅替换旧模块并热更新"] end ``` 然而，生产环境依然不能完全舍弃打包。Snowpack 的转换是一对一的，如果在生产线上线成百上千个细碎的小模块并在网络上穿梭，其性能表现依然不可接受；最佳实践仍然是将它们打包成少量具备粗粒度代码分割（code-split）的 chunk。在生产构建上，SvelteKit 将这一传统工作流与新架构进行了融合。在此处，Rich 特别向 Snowpack 团队以及核心作者 Fred Schott 致谢，称其为该项目背后的天才；Fred 在帮助 Svelte 团队探索如何让 Snowpack 适配服务端渲染（SSR）框架方面给予了巨大支持，双方的合作极为高效。 - “And so because transforming a single module is generally pretty fast, your reload speeds are much much quicker than any bundler could ever hope to be and so I think we're going to get to a point pretty soon where projects that use bundlers during development are going to seem a little bit antiquated looking at you other frameworks.” —— Rich Harris - 生产构建仍然需要将零散的模块聚合成若干粗粒度且带代码分割的 chunk，以避免大量小模块在网络请求中产生延迟瓶颈。 --- ### [13:58](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=838s) SvelteKit 的三阶段构建流程与 Adapter 机制 Rich Harris 现场演示了在终端执行 `npm run build` 的完整过程。整个构建分为清晰的三个阶段： ```mermaid flowchart TD accTitle: SvelteKit 三阶段构建流程 accDescr: 展示未优化构建、Rollup 优化打包以及 Adapter 适配生成的三个顺序阶段。 subgraph P1["阶段一：未优化构建 (Phase 1)"] A["全部应用源码"] -->|"Snowpack 1:1 转换"| B["未优化 Client / Server 代码"] end subgraph P2["阶段二：优化打包 (Phase 2)"] B -->|"Rollup 打包与代码分割"| C["路由 Chunks + 共享依赖 + 资源清单/CSS"] end subgraph P3["阶段三：目标适配生成 (Phase 3)"] C -->|"加载 Adapter 插件"| D{"svelte.config.js 配置"} D -->|"adapter-node"| E["Node.js SSR 服务"] D -->|"adapter-static"| F["纯静态 HTML/资源"] D -->|"adapter-netlify / 无服务器"| G["云函数 + CDN 静态文件"] end ``` 第一阶段是所谓的“未优化构建”（unoptimized build），应用中的全部模块被交由 Snowpack 进行一对一转换，输出客户端和双端 SSR 所需的原始转换文件（例如 Counter 组件的 SSR 版本）。第二阶段是“优化打包”（optimizing），通过 Rollup 处理第一阶段的产物，输出对应各个页面路由的代码分割 chunk、公共共享逻辑、CSS 资源以及应用清单（manifest）。第三阶段则是调用 `svelte.config.js` 中配置的 Adapter（适配器）生成最终的交付形态。默认情况下，项目可能配置为 `adapter-node`，其产物类似于旧版 Sapper 的 `sapper build`（需要 Node.js 服务器运行）。但对于纯展示页面，完全不需要维护一个常驻的 Node 进程。Rich 现场将配置切换为 `adapter-static`，安装对应依赖，并在保存配置文件后重新执行构建。适配器立即在构建目录中生成了对应的纯静态 HTML 文件（如 `/` 与 `/about`）。Rich 特别强调，这与过去 Sapper 的 `sapper export` 完全不同：Sapper 以前是通过本地启动一个 Node 服务然后派爬虫去抓取页面 HTML；而现在的静态生成直接调用 Svelte 底层的 SSR API 一次性高效渲染完成，不仅速度飞快，还极为轻量，足以轻松应对超大规模内容的静态站点生成。 - “One big difference between what just happened and what happens when you run Sapper export for those of you familiar with Sapper export is that rather than building a node server running the node server and then crawling the output of that node server it's just doing everything with the Svelte SSR API directly the server rendering API and what that means is very fast very efficient.” —— Rich Harris - SvelteKit 构建三阶段：Snowpack 模块直转（Phase 1） -> Rollup 优化与代码分割（Phase 2） -> Adapter 适配落地（Phase 3）。 --- ### [16:54](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1014s) 动静结合的混合渲染与 Serverless 优先体系针对现代站点的多元化需求，Rich 阐述了从 Sapper 到 SvelteKit 的范式转变。在旧的 Sapper 体系下，开发者往往被迫做出二选一的妥协：要么选择 Node 服务端渲染，导致所有页面（即使是永远不变的内容）都在运行时动态计算；要么选择全静态导出，导致任何需要实时数据或个性化呈现的功能无法工作。SvelteKit 引入了混合渲染能力（Hybrid Apps），能够让动态渲染与静态预渲染（Pre-rendering）共存于同一个应用内。 Rich 以跑在本地的 Svelte Hacker News 演示项目为例：动态列表页通过直接抓取外部接口实时渲染，而关于页面（About）则完全由静态内容构成。为了让编译器知道哪些页面适合预渲染，开发者只需在对应页面中显式导出一个声明标记： ```javascript export const prerender = true; ``` 在执行构建时，系统会精准识别出带有该标记的页面（如 `/about`），直接将其预先烧录进静态目录；当服务运行时访问该页面，直接交由静态文件服务处理，彻底免除了服务器端的运行时渲染开销。更为强大的是其面向无服务器（Serverless）架构的适配能力。以 Netlify 等平台为例，对应的 Adapter 能够在构建时自动将项目拆解为两部分：静态资源直接交付 CDN 边缘分发，需要动态渲染的页面则打包成独立的云函数（Cloud Functions）。Rich 兴奋地总结道：“整个 Serverless 是一股极具前景的技术趋势，而 Svelte 现在已经是一套无服务器优先（Serverless-first）的框架了。”此外，这种统一的架构模板未来甚至可以横跨至组件库的开发体验，彻底消除“做应用”与“做库”之间的工具链撕裂。 - “With Sapper you have to choose you either get a node server that dynamically renders everything regardless of whether you have pages that stay the same forever or you statically render everything which doesn't work if you have any pages with changing data or personalized content or anything like that but with this new system we can have hybrid apps just like recent versions of next you can have some pages that are dynamically rendered and some that are pre-rendered.” —— Rich Harris - “The whole serverless thing it's a pretty good trend and Svelte is now a serverless first framework yay.” —— Rich Harris --- ### [20:16](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1216s) 常见问题解答与生态展望：迁移、哲学定位、TypeScript 及资助在演讲的收尾环节，Rich 预判并回答了社区最为关心的几个核心问题： 1. **旧项目能否平滑迁移？** 虽然迁移不会是 100% 全自动的，但整体过程会非常直截了当。SvelteKit 的目录组织、工程理念大多沿袭自 Sapper，核心概念高度重合，迁移并不会成为开发者的梦魇。 2. **开发者必须强制使用这套全栈工作流吗？** 答案是绝对不必。Rich 分析了前端框架的两大阵营：一类是 Angular 和 Ember，强烈倾向于接管开发者的整个工程全生命周期；另一类是 React 和 Vue 这类纯组件层库，把路由、SSR 等大仓组合留给社区，因而催生了 Next.js、Gatsby、Remix 等上层体系。Rich 明确表示：“我希望 Svelte 两者兼备。”开发者既可以用 SvelteKit 在数秒内获得不可思议的生产力，但如果是资深高阶用户、有特殊集成需求，Svelte 底层永远开放且模块化，团队会持续全力支持像 11ty 插件、Routify 以及 Elder.js 等社区自主搭建的方案。 3. **是否支持 TypeScript？** Rich 斩钉截铁地确认：虽然演示时尚未全部接入，但正式发布时绝对会原生支持 TypeScript。 4. **社区如何参与和资助？** 目前相关探索代码仍处于私有仓库阶段，尚未准备好接受外部 Pull Request，但大家可以通过官方 Discord 频道、Twitter（@sveltejs、@SvelteSociety）关注第一手进展。最后，Rich 提到在当年的常见答疑中曾有人询问能否给项目捐款，当时答案是“还不行”，而现在 Svelte 已正式上线 Open Collective。这些款项将用于抵扣开源项目基础设施的日常运维成本，并为未来全职或定向资助核心特性研发奠定基础。演讲在 Rich 对已经默默支持的赞助者们的真诚致谢，以及找不到关闭录屏按钮的幽默碎碎念中画上句点。 - “I want Svelte to be both of those you can be wildly productive with this app template in a matter of seconds but if you're a power user with specific needs that aren't met by this template for whatever reason then those needs will continue to be met by the Svelte project.” —— Rich Harris - “It is critically important that people are able to build their own custom integrations plugins for things like 11ty or even Svelte-based frameworks like Routify and Elder.js and that is not going to change.” —— Rich Harris ## Notable quotes > [05:29](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=329s) So you get the best of both worlds you get a very fast startup with the static HTML but then you get instant navigation client-side because the client-side router has kicked in. — Rich Harris > [20:16](https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=1216s) It is critically important that people are able to build their own custom integrations plugins for things like 11ty or even Svelte-based frameworks like Routify and Elder.js and that is not going to change. — Rich Harris ## Mentioned Rich Harris, Svelte, SvelteKit, Sapper, Snowpack, Rollup, Webpack, Parcel, Fred Schott, Ben McCann, Rixo, Netlify, Node.js, Angular, Ember, React, Vue, Next.js, Gatsby, Remix, 11ty, Routify, Elder.js, TypeScript, Open Collective, Svelte Society ## Video description Edit from the future: check out our followup podcast interview on SvelteKit https://share.transistor.fm/s/859bbd95 --- This was recorded for Svelte Summit 2020: https://www.sveltesummit.com The front end development landscape has been transformed since we started building Svelte and Sapper. What would a reimagined, truly modern workflow look like? Open Collective: https://opencollective.com/svelte [Source](https://www.youtube.com/watch?v=qSfdtmcZ4d0)

Source quotes

[5:29] Rich Harris: So you get the best of both worlds you get a very fast startup with the static HTML but then you get instant navigation client-side because the client-side router has kicked in. [20:16] Rich Harris: It is critically important that people are able to build their own custom integrations plugins for things like 11ty or even Svelte-based frameworks like Routify and Elder.js and that is not going to change.

Source quotes

[12:22] Rich Harris: I think we're going to get to a point pretty soon where projects that use bundlers during development are going to seem a little bit antiquated looking at you other frameworks. [6:54] Rich Harris: So you get the best of both worlds: you get a very fast startup with the static HTML, but then you get instant navigation client-side because the client-side router has kicked in. [0:00] Rich Harris: It'd be much better for everyone—users and also people giving support on Discord and Stack Overflow and places like that—if we could give you a single canonical answer: this is the officially supported way to build apps with Svelte.

Original transcript

[0:00] I haven't been this excited about Svelte since probably the launch of Svelte 3 [0:03] and over the next 15 minutes or so I'm going to explain why that's the case and hopefully get you [0:07] a little bit hyped up as well. I wasn't totally sure whether or not to do this because this is [0:13] all still slightly speculative what I'm going to show you. This isn't an official announcement from [0:18] the Svelte team although they are aware of this work and they are supporting this work but we [0:22] shouldn't take that as any guarantee of anything that's going to happen and we certainly shouldn't [0:25] take it as any guarantee of when things are going to happen. But I figured it's worthwhile talking [0:30] about it for a couple of reasons. Firstly as previously mentioned I'm excited about it. [0:36] Secondly I think it's useful to manage expectations particularly when a lot of you have [0:41] the same questions about where the project is heading. And thirdly some of this stuff isn't [0:47] really about Svelte it's about the future of web development more broadly and there are some ideas [0:52] out there that I want to try and help push in to the mainstream if I can. Alright so that's the [0:58] caveats out of the way. Last time I did this I was answering some frequently asked questions about [1:04] Svelte and a lot of that video was devoted to SAPA. For those of you who aren't familiar SAPA is [1:09] the complete application framework that sits on top of Svelte. It includes server-side rendering, [1:14] routing, code splitting and so on. People often ask us when is SAPA 1.0 coming out and today [1:23] I can give the answer. SAPA 1.0 is coming out... [1:31] never. No seriously it's not coming out. There isn't going to be a SAPA 1.0. Here's the thing [1:38] I really love SAPA and I think there's a lot of really great things that you can do with it and [1:42] some of you have built some really amazing apps with it but I think we can do a little bit better. [1:48] The pace of development has been a lot better recently thanks to Ben McCann and some other [1:52] contributors but the code base is kind of gnarly and it's hard to work with. It's tricky to add [1:57] valuable features like building for serverless platforms or pre-rendering a subset of your [2:02] application as static files and if you're new to Svelte the very first choice that you have to make [2:07] is do I use the default Svelte template or do I build a SAPA app which is a really confusing thing [2:13] to have to answer right off the bat and so it'd be much better for everyone users and also people [2:18] giving support on Discord and Stack Overflow and places like that if we could give you a single [2:23] canonical answer this is the officially supported way to build apps with Svelte. [2:29] Meanwhile the front-end development landscape has changed quite substantially since we started [2:33] building SAPA back in 2017 and we have an opportunity now to really think deeply about [2:39] what a modern development workflow looks like and that is the stuff that I want to show you. [2:44] So demo time. So in here I've got an empty directory and I am going to create a new Svelte [2:51] application using npm init svelte at next because this isn't yet released. Hit enter [2:59] and it's created some project files over here so I'm just going to quickly [3:07] turn that into a git repo and install those dependencies. [3:16] I would show you how long the equivalent setup would take for other frameworks but [3:22] I don't want this to be a really long video. So let's take a look at the code base. We have [3:28] a source directory here which contains an app.html. It's just a bog standard html file [3:36] with these little insertion points for Svelte to add some head tags and some stuff for the body. [3:43] We've got a roots directory. If you're familiar with SAPA then this will all make sense. Inside [3:49] your roots directory you have files that determine the structure of your application. In this case we [3:56] have an index.svelte, just the one, just one page. It's importing a counter from this. We've got [4:04] dollar components here. May change, I don't know. But that is an alias to this components directory. [4:12] Then we've got some markup and then a bunch of styles, all very standard stuff. [4:16] And then inside the counter we're just doing the demo button clicky thing. [4:22] Static down here, we've got some files that just get uploaded as is. We've got a favicon [4:31] and a robots.txt, nothing very exciting. Package.json, this is what is being installed [4:39] to make this run. We have, let's give this a name, demo app. We have a couple of scripts here, [4:48] svelte dev and svelte build. That command is coming from this thing, svelte kit. Name might [4:55] change but we like it for now. And there's a few other things that we're going to encounter as we [5:02] go through this thing. One thing you will notice, we have a snowpack config. That's because this [5:10] project uses snowpack. It doesn't use rollup, well it does use rollup, eventually we'll get to that. [5:16] But when you're developing it doesn't use a bundler, it uses something called snowpack and [5:20] that's what I'm going to show you. We also have a svelte config file which specifies a thing called [5:24] an adapter and later on I'll explain what an adapter is. Okay so that's the structure of the [5:29] project, now let's start the development server and see what that looks like. So down here in [5:34] the terminal I'm going to type npm run dev dash dash open and you'll see it's basically instant. [5:44] So we now have the development server running on localhost 3000. And if I start making changes to [5:51] this counter component, like I'll change what's inside the button, then you'll see it hot reloads [5:59] and we get those changes almost instantly. We can change the state and [6:05] the state will be preserved as we're making changes. So I could change the font family [6:17] to chalkboard, I could make it a little bit bigger. [6:27] And it's just going to preserve the state the whole time because we now have really good hot [6:33] module reloading courtesy of Rixo who's been working really hard on this and has done an [6:37] incredible job. We can even do things like this with the clicks count is getting a little bit [6:41] high here so I'm going to change this to a decrement function and get that down a little [6:49] bit. So far our app only has one page, let's add another one. We'll begin by creating a navigation [6:54] component inside the components directory here we'll create nav dot svelte. Very simple just a [7:01] nav element with a href equals slash for the root and then another one for the about page [7:11] that we're going to create. And then on the index page we will import the nav component [7:19] and then just add it to the top of the page like so. And here we've got our home and about. [7:23] I think actually it would look better inside that main block. Here we go. But now if I go to the [7:33] about page we're going to get a 404 obviously because we haven't created that page yet. So [7:37] let's create a new root about slash index dot svelte and it's created that already about this page. [7:55] It looks a bit ugly though it doesn't have the same styles as the index page. We could just [8:00] duplicate everything from the index page but we're not going to want to do that for every new page [8:06] that we had. So we'll solve this with a layout component which if you've used sapper you'll be [8:13] familiar with. Layout dot svelte just controls it's like a wrapper around the content and all [8:23] we need to do is create a slot for the content to come through like so. But I think what I'm going [8:30] to do is I'm just going to copy everything over from the index page put it in the layout and then [8:35] up here get rid of the content and replace it with a slot like so. The counter has been grayed out [8:43] because we're not using it so I'm just going to get rid of that. Also we're getting some unused [8:48] css messages here so we can get rid of those as well. Okay now we have a layout for our about page. [8:58] On the index page we don't want the layout inside the layout so I'm going to get rid of everything [9:03] except the content. Again we can get rid of that unused component and we've got some more unused [9:15] css here so just going to get rid of that and actually this root css is unused too. [9:21] Okay so now we can go between the home page and the about page and if you look here you see this [9:27] little reload icon. If it was doing a normal or conventional full page reload then you would see [9:34] that reload icon spin but because we're doing purely client-side navigation [9:39] it's instant and you don't get that reload icon. Having said that this is all server rendered so [9:46] you can go to any of these pages and I can show you by going to view source that it does actually [9:51] have the content of the page in the HTML that gets delivered to the client when you first go there. [9:58] So you get the best of both worlds you get a very fast startup with the static HTML but then you get [10:03] instant navigation client-side because the client-side router has kicked in. [10:08] Now a cool thing about snowpack is that if I make a compile error somewhere on here like say I forget [10:14] to close my tag correctly and I save that then I get this really nice overlay. I get instantaneous [10:23] feedback that something is wrong and it shows me where the error is so that I can know how to fix [10:28] it. Fix that, save and the overlay just vanishes. So snowpack is obviously incredibly fast and you [10:35] might be thinking well it's a very small site of course it's going to be faster when you've [10:38] got two pages but the way that it's designed it will continue to be that fast even if you have [10:43] a huge site with hundreds of pages and thousands of components and it's worth taking a moment to [10:49] understand why snowpack is so fast and why this represents such what I think is an important [10:54] change in web development. So for the last few years we've been using bundlers things like webpack [10:59] and rollup and more recently parcel and the way that they work is they take your source code [11:06] and they trace the dependency graph through the modules like through the import statements that [11:10] you have in your modules and they combine them into a file that can then get loaded in the browser [11:15] and run as a script and that was necessary for a long time because browsers didn't support modules [11:20] natively but nowadays browsers do support modules. So instead of bundling your files snowpack just [11:28] transforms them so if you have typescript it'll turn it to javascript if you have a svelte file [11:33] it will run it through the svelte compiler and turn it into a javascript module but it won't [11:37] stitch them together it'll just rely on the browser's native import to fetch the rest of [11:43] the modules in your dependency graph and so because of that it doesn't even need to transform [11:47] everything immediately it just waits for the browser to actually request files and then it [11:51] transforms them on demand and so if you have thousands of modules but you're only looking [11:57] at a few of them on the page that you're currently developing then you only need to transform the [12:01] ones that you're currently interested in and then when you make a change to one of those files [12:06] previously a bundler having created the bundle in the first place it now has to rebundle it [12:12] and even if it's got really good caching it's going to have to do a bunch of extra work to [12:17] create a new bundle to represent the one file inside that bundle that has changed. [12:22] Snowpack doesn't need to do any of that it can just say here's the new file [12:28] please load this mr browser and the browser fetches the module replaces the module that [12:35] already existed if you've got hot module replacement working and that's it and so [12:41] because transforming a single module is generally pretty fast your reload speeds are much much [12:48] quicker than any bundler could ever hope to be and so I think we're going to get to a point [12:55] pretty soon where projects that use bundlers during development are going to seem a little [13:01] bit antiquated looking at you other frameworks. Now you do still need a bundler for production [13:09] Snowpack just does this one-to-one transformation and it's still not good to have hundreds of small [13:14] modules zipping across the network you want to try and turn those into a bunch of coarse grain [13:20] code split chunks which is what we've been doing for the last few years anyway and it's what happens [13:26] in Svelte now in SvelteKit and I'm going to show you what that looks like but first I just want to [13:35] take a moment to shout out to the Snowpack team in particular Fred Schott who is the genius behind [13:40] this whole project Fred's been incredibly helpful to us as we try and figure out how to make Snowpack [13:48] work for a server-side rendering framework and it's been a really productive partnership so [13:53] thank you Fred. So here's what it looks like to build one of these projects I'm going to type [13:58] npm run build and you'll see it happens in three phases. First we create what we call an unoptimized [14:08] build and this is just running all of the modules in the entire application through Snowpack and [14:16] that as explained it just one-to-one transformations and it'll spit out this unoptimized [14:22] version of client and a server version of the app with all of your modules just sitting around here [14:29] so this is the server-side rendering version of the counter component for example. [14:36] And then in phase two we optimize the output of that by running it through rollup and the end [14:43] result of that is a group of chunks representing the roots of your app plus anything that's shared [14:54] between them plus like a manifest which is going to be useful later and various other bits of [15:01] information it also has some special css handling and then finally we generate the app using what's [15:08] called an adapter and the adapter as I showed you before is specified in svelte-config.js [15:15] and it's currently set up to use something called adapter node which if you're familiar with Sapper [15:20] is basically the same as you would get from running Sapper build but for this site we don't [15:26] really need a node server because we can just create static pages for everything so I'm going [15:30] to change that to adapter static we're going to install that and then we're going to rerun [15:45] npm run build and it'll do the same thing again unoptimized build then it'll run through rollup [15:51] and then it passes it to oh hang on I actually need to save the config file otherwise this [15:55] isn't going to work and then it'll pass it to adapter static and you'll see that now we've got [16:02] 200 responses for slash and slash about the two pages in our application and if we look at the [16:08] build output we've got an index page which contains our hello world and we've got an about page which [16:18] contains about this page one big difference between what just happened and what happens when you run [16:24] Sapper export for those of you familiar with Sapper export is that rather than building a [16:28] node server running the node server and then crawling the output of that node server it's [16:34] just doing everything with the Svelte SSR API directly the server rendering API and what that [16:41] means is very fast very efficient so you will be able to statically render sites with huge amounts [16:47] of content very quickly with with this with this new setup now with Sapper you have to choose you [16:54] either get a node server that dynamically renders everything regardless of whether you have pages [17:00] that stay the same forever or you statically render everything which doesn't work if you have [17:06] any pages with changing data or personalized content or anything like that but with this new [17:11] system we can have hybrid apps just like recent versions of next you can have some pages that are [17:19] dynamically rendered and some that are pre-rendered and so I'm going to take you to the the Hacker News [17:25] Svelte implementation and show you what that looks like in practice so this is Svelte Hacker News [17:30] running on on localhost and all these pages are dynamically rendered using fresh data from [17:39] api.hnpwa.com and you know we can click around here and it's it's actually fetching data direct [17:48] from that api it's not even hitting our own server at this point but then if we go over [17:53] to the about page there's nothing dynamic on here it's just static data so what we want is to [18:00] dynamically render all of these pages but then statically pre-render the about page so that [18:07] we never need to do any computation when someone requests it we need to have some way though of [18:11] identifying which pages are suitable for pre-rendering because it's difficult to tell [18:18] automatically there needs to be some explicit signal that you the developer provide to say [18:23] this page is one that should be free rendered this one is one that should be dynamically rendered [18:28] and the way that this this works obviously this is all subject to change but currently if you have [18:34] a page that exports this pre-render equals true value then that is a signal to Svelte that this [18:44] page can be statically pre-rendered. Okay so let's build this app shut the development server npm run [18:50] build again and it does the same thing unoptimized build optimizing and this time when it generates [18:57] the app we see pre-rendering static pages and it's found the about page that we marked as pre- [19:02] renderable and if we actually look at the build output a pair build pre-rendered there's an about [19:09] page that's already been generated with the the about this site corresponding to what what we see [19:16] over here and so now if you actually run this app with node build then when we serve that page [19:24] it's not having to do any rendering it's literally just serving a static file this is a node app but [19:31] we can also have adapters for cloud function based services so for example if you want to [19:37] deploy your site to Netlify it will split out the static assets from the cloud functions that [19:43] dynamically render pages and it will deploy those together when we launch this thing we'll have [19:49] adapters for all of the major services the whole serverless thing it's a pretty good trend and [19:57] Svelte is now a serverless first framework yay so this really just scratches the surface of what we [20:03] can do in this new world one interesting thing I think we could do now is we could use this same [20:11] template for component libraries as we do for sites and apps which I think will be a really [20:16] nice development experience you probably have some questions though so will I be able to migrate my [20:22] existing sites and apps won't be completely automatic but it should be reasonably straightforward [20:27] the project structure is pretty much the same and most of the ideas from Sapper read across so I'm [20:33] not expecting that to be a massive headache do I have to use this workflow no absolutely not so [20:42] this is split in framework land between things like angular and ember which kind of really want [20:47] to own the entire experience even if it's technically possible to use the constituent parts [20:52] by themselves and then on the other side you have things like react and view which are really just [20:56] component frameworks and you're expected to build an app yourself which is why things like next and [21:01] gasp and remix exist I want Svelte to be both of those you can be wildly productive with this app [21:08] template in a matter of seconds but if you're a power user with specific needs that aren't met [21:13] by this template for whatever reason then those needs will continue to be met by the Svelte [21:18] project it is critically important that people are able to build their own custom integrations [21:24] plugins for things like 11t or even self-based frameworks like [21:29] rootify and elderjs and that is not going to change [21:34] will it work with typescript yes it will haven't set that up yet but absolutely it will [21:40] launch with typescript support how can I contribute so we're still figuring a lot of [21:47] things out right now and this work is happening in a private repo for now so we're not set up for [21:52] contributions just yet but as usual you can visit as a svelte.dev chat or pay attention to Svelte.js [22:00] or Svelte Society on twitter and you'll be kept up to date on what's going on with this okay one [22:06] more thing so when I did the FAQs earlier this year one of them was can I give you money and [22:12] at the time the answer was no but maybe soon well we do now have an open collective where you can [22:19] contribute financially to Svelte if it's been valuable to you we don't exactly know how the [22:23] funds are going to be used there are some costs associated with running a project like this and [22:27] those can now be offset and it may one day put us in a position to directly fund work on specific [22:33] features so it puts us in a really healthy position massive massive thanks to those of you who have [22:38] already become backers without us making an official announcement it is really truly appreciated [22:44] right that's enough from me uh how do I turn this thing off