SvelteKit 到底是什麼？
我們正在重新思考如何建構 Svelte 應用程式。以下是你需要知道的
如果你上個月參加了 Svelte Summit，你可能看過我的演講「未來網路開發」，我在其中最終解決了一個關於 Svelte 最常被問到的問題：Sapper 何時會達到 1.0 版本？
答案是：永遠不會。
這有點開玩笑的意味 — 正如演講中解釋的，它實際上更像是對 Sapper 的重寫，並加上品牌重塑 — 但它引發了社群中許多新的問題，現在是時候對 Sapper 的繼任者 SvelteKit 的期望提供更清晰的說明。
什麼是 Sapper？
Sapper 是一個建立在 Svelte 之上的應用程式框架（或「元框架」）（Svelte 則是一個元件框架）。它的工作是讓建構具有所有現代最佳實務（如伺服器端渲染 (SSR) 和程式碼分割）的 Svelte 應用程式變得容易，並提供一個使開發高效且有趣的專案結構。它使用基於檔案系統的路由（由 Next 推廣並被許多其他框架採用，儘管有一些增強功能）— 你的專案檔案結構會反映應用程式本身的結構。
雖然 Svelte 首頁和文件鼓勵你 degit sveltejs/template 儲存庫以開始建構應用程式，但長期以來，Sapper 一直是我們推薦的建構應用程式方式；這篇部落格文章（在撰寫時！）就是用 Sapper 渲染的。
為什麼我們要遷移到新的東西？
首先，sveltejs/template 和 sveltejs/sapper-template 之間的區別令人困惑，特別是對 Svelte 的新手而言。有一種推薦的方式來開始使用 Svelte 建構應用程式將帶來巨大的好處：我們簡化了入門流程，減少了維護和支援負擔，並且有可能開始探索具有可預測的專案結構所釋放的新可能性。（最後一部分是故意含糊不清的，因為需要時間才能完全理解這些可能性是什麼。）
除此之外，我們早就被重寫 Sapper 的想法所吸引。部分原因是程式碼庫多年來變得有些混亂（Sapper 開始於 2017 年），但主要是因為網路最近發生了很大變化，現在是時候重新思考我們的一些基本假設了。
這個新東西有什麼不同？
其中一個基本假設是你需要使用像 webpack 或 Rollup 這樣的模組打包器來建構應用程式。這些工具會追蹤應用程式的依賴關係圖，分析並轉換程式碼（例如，將 Svelte 元件轉換為 JS 模組），以便建立可在任何地方執行的程式碼包。作為 Rollup 的原始創作者，我可以證明這是一個非常複雜的問題，而且具有棘手的邊緣案例。
幾年前你確實需要一個打包器，因為瀏覽器不原生支援 import 關鍵字，但今天情況已大不相同。現在，我們看到非打包開發工作流程的興起，它非常簡單：開發伺服器可以按需提供模組（如果需要，則轉換為 JavaScript），而不是急切地打包你的應用程式，這意味著啟動時間基本上是即時的，無論你的應用程式變得多麼龐大。
Snowpack 是這項運動的先鋒，它也是 SvelteKit 的動力來源。它非常快速，並且具有出色的開發體驗（熱模組重載、錯誤覆蓋等），而且我們一直與 Snowpack 團隊密切合作開發諸如 SSR 等功能。如果你習慣使用 Rollup 的 Sapper（由於其架構優先考慮最有效率的輸出，因此從未具有一流的 HMR 支援），那麼熱模組重載尤其具有啟示性。
這並不是說我們完全放棄了打包器。為了最佳化你的應用程式以用於生產環境，它仍然是必不可少的，而 SvelteKit 使用 Rollup 來使你的應用程式盡可能快速且精簡（其中包括將樣式提取到靜態 .css 檔案中）。
另一個基本假設是，伺服器渲染的應用程式需要一個伺服器。Sapper 有兩種模式 — sapper build 會建立一個必須在 Node 伺服器上執行的獨立應用程式，而 sapper export 會將你的應用程式烘烤為一系列適用於在 GitHub Pages 等服務上託管的靜態檔案。
靜態檔案幾乎可以放置在任何地方，但是執行 Node 伺服器（以及監視/擴展它等）則不太直接。如今，我們看到了一種轉向無伺服器平台的趨勢，在這種平台上，作為應用程式作者，你無需考慮你的程式碼在何處執行以及隨之而來的所有複雜性。你可以借助 vercel-sapper 等工具在無伺服器平台上執行 Sapper 應用程式，但這絕不是你所說的慣用方式。
SvelteKit 完全擁抱無伺服器範例，並將推出對所有主要無伺服器供應商的支援，以及一個用於針對我們不正式支援的任何平台的「轉接器」API。此外，我們將能夠進行部分預先渲染，這意味著靜態頁面可以在建構時產生，但動態頁面會按需渲染。
我什麼時候可以開始使用它？
如果你覺得自己夠勇敢，可以立即開始
npm init svelte@next這將建立一個新專案並安裝 @sveltejs/kit CLI，它提供了開發和建構應用程式的工具。
不過，我們不建議這樣做！沒有文件，我們也無法提供任何形式的支援。而且它也可能經常出錯。
當我們仍處於探索模式時，這項工作是在一個私有 monorepo 中完成的。我們的計畫是準備好公開測試版，並在我們解決了一些問題後在此處發布公告 — 儲存庫本身屆時將保持私有狀態，但我們將建立一個地方來收集來自 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 線程，提出你其他問題）。