一個官網先搬了家：Flutter 棄 Medium 用 Jaspr，是一場被排好的渲染分工

2026 年 9 月 4 日，掘金作者「戀貓de小郭」（Flutter 與 Dart GDE）發文聊了一個 Flutter Web 的話題，核心事件其實發生在更早：Flutter 與 Dart 的官方網站，包括 dart.dev、flutter.dev 與 docs.flutter.dev，已經全數離開 Medium，遷回自家域名，而支撐這次搬家的，是一個名為 Jaspr 的第三方 Dart Web 框架。這件事值得從設計的角度重看一遍，因為它示範了一個技術團隊如何把「內容該長什麼樣」當成架構問題來處理。

先從一段程式碼的長相看起

Jaspr 的寫法有點復古。它讓開發者用 Dart 寫傳統 DOM，程式碼裡出現的是 div、h3、p 這些 HTML 元素，而不是 Flutter 慣用的 Widget 樹。以官方文件裡的 FeatureCard 為例，一個元件的 build 方法回傳的是 div(classes: 'feature-card', ...) 這樣的結構，外層掛 class 名稱，內層放標題與段落文字。

這個細節很重要。它意味著 Jaspr 走的是 HTML 與 CSS 的路線，寫法上模仿 Flutter 的元件化習慣，讓 Flutter 開發者不需要換一種腦袋，但輸出的東西是瀏覽器原生可讀的文件結構。搜尋引擎爬得到，Ctrl 加 F 找得到，CSS 樣式照著傳統規則走。與 Flutter Web 預設用 Canvas 或 WASM 把整個頁面畫成一張圖的做法相比，這是兩種完全不同的畫面生產方式：一種把網頁當應用程式介面來渲染，一種把網頁當文件來排版。

為什麼官網必須搬家

Flutter 官網過去把文章放在 Medium，理由並不神祕。Flutter Web 長期不支援 SEO，用自家技術架官方部落格，等於讓文件在搜尋結果裡隱形，只好借用 Medium 這個天生對搜尋引擎友善的平臺。這是一個技術限制倒逼內容託管的例子，版面選擇被迫交給別人。

Jaspr 改變了這個前提。它內建的部分渲染可以把每個頁面預先輸出成靜態 HTML，只為真正需要互動的元件附加客戶端邏輯。官方網站的大部分內容本來就是靜態文件，互動需求很少，這種「大部分是文件、小部分是程式」的頁面構成，恰好是預渲染最擅長的場景。再加上 Jaspr Content 支援 Markdown 驅動的網站架構，官方才有可能把部落格遷回自己的域名下，用 Markdown 寫作、用靜態頁面發佈、用搜尋引擎收錄。

換句話說，這次搬家的設計邏輯是：讓文件回到文件的形態。這與我們在iPhone Air 的薄與續航取捨裡看到的思路有點像，規格上的取捨最終都會沉澱成使用者可感知的體驗差異，只是 Flutter 這次的取捨發生在渲染層。

WASM 那一側：把 Canvas 顧好

與 Jaspr 的 DOM 路線平行發展的，是 Flutter Web 在 WebAssembly 上的推進。最新版本支援了 flutter build web --release --wasm --enable-wasm-deferred-loading，可以對 WASM 做拆包，首次載入的體積因此下降。搭配 dart2wasm 編譯器與多執行緒渲染的 Skwasm，實際效果反應在幾個可量測的地方：大量元件同時更新時的 diff 運算能維持 60 FPS 的幀時間；Skwasm 把光柵化工作交給專用的 Web Worker，瀏覽器主執行緒因此保持流暢；整體包體比以往更小，還能再拆。

從設計的角度看，這是一套清晰的分工：DOM 交給 Jaspr 這類傳統框架，負責文件、SEO 與可檢索性；WASM 交給 Flutter 本體，負責把 Canvas 上的應用程式介面無縫帶進瀏覽器。原文作者點出一個常被誤解的定位問題，Flutter 從來就不是要跟傳統 H5 頁面競爭，它的目標是讓 Flutter 的 Canvas 能力延伸到瀏覽器，並且深耕 WASM 場景。兩條路線各自服務不同的畫面需求，而不是互搶地盤。

遺憾的部分：WebGPU 與Ctrl加F

目前最明顯的缺口是 WebGPU。Flutter 官方對 WebGPU 支援始終沒有公開表態，社羣版本倒是有，這讓 Web 渲染的下一步少了官方背書。另一個老問題也還在：Flutter Web 並未完全解決 SEO 與頁內搜尋，這限制了它在內容型網站的應用範圍，只能被局部採用。

有趣的是，原文觀察到官方對 Web 的投入其實不亞於桌面端，甚至更上心。這個優先順序本身也是一種設計聲明：行動優先的框架，把瀏覽器視為下一個必須認真對待的畫布。

收在分工這件事上

這則話題最值得記下的，是一個框架生態如何誠實面對自己的短處。Flutter 沒有勉強用自己的 Canvas 去渲染不擅長的文件頁面，而是讓官網遷到一個社羣維護的、輸出純 DOM 的框架上，把 SEO 與可讀性還給文件，把效能留給 WASM。這種承認工具邊界、按畫面需求分工的判斷，比任何單一技術的進步都更能說明一個生態的成熟度。這與我們先前討論的遊戲科學與技術專業的命名設計有共通之處：好的設計往往始於把東西放對位置，而非把一個工具用到極限。