({ color: theme.colors.primary })}> ``` 只是上述结构其实在 V1 中就已经可以使用 Tailwind 绕开了， CSS-in-JS 不接的主要原因其实是一旦接上了 CSS 会变回 JS execution result，然后 style runtime、registry、SSR collection、hashing、hydration consistency、theme context、insertion、ordering、dedup 全都得请回来，普通框架可以吞下；但是 Seam 她不一样啊！我要消灭的就是这类 server / runtime work，应该是完全没必要为了生态礼貌把刚赶走的东西请回来吧（~~完全没有道理呢~~ 再说 CSS-in-JS 出现的时代解决的问题是没有 Tailwind CSS & Motion 干的事情，如果现在 TailwindCSS & Motion 已经足够解决甚至更好更优雅的解决了，那么何必要开倒车呢，就像我前面所说的「任何东西在生态起来后都会出现妥协[^28]，~~很少的出现 breaking 重构来革新~~」那么既然 Seam 还没有起来生态，那么为何不**激进到底**呢？但是这里用 "激进" 我不知道对不对，可能对的一方面是对于传统框架来说，我干丢掉 Server Side 那种重 JS Runtime (Node OR Bun), 不对也可能是比方说 CSS-in-JS 如果彻底丢掉的话，其实也没啥问题，~~我更愿意考虑它为时代的眼泪了~~。曾经最知名的 CSS-in-JS 的 lib 们 [Stitches](https://github.com/stitchesjs/stitches/discussions/1149) 2023 年 6 月官方宣布 no longer actively maintained, [styled-components](https://styled-components.com/blog/celebrating-a-decade-of-styled-components) 2025 年 3 月也进入了休眠状态，[Emotion](https://github.com/emotion-js/emotion/discussions/2827) 基本上也是这样子的。 *** 那么又不得不表扬一下 Svelte 的 ` ``` 那么最终肯定会达到 ```text ComponentIR HTML:

Hello SLOT(0)

CTR: slot(0) = props.name CSS: .user.svelte-x { ... } Client: none SSR: none ``` 但是注意以上你看到的仅仅是叶子，而且是比较理想的切片；没有子组件、没有结构分支、没有 client. 页面级 `skeleton` 是静态组件图 compose 出来的；子树一旦有 `$state` 或 `hatch`，IR 里的 Client / SSR 就不会是 `none`. 但这已经非常接近我想让 Seam 达到的理想状态，也就是一个 Svelte component 不再对应“一个需要执行的 renderer”, 而是变成一个 Svelte 5 Compiler 能拆开的资源；实现了这个对我来说就已经是非常大的 conceptual improvement. ### Ownership 另外就是 “不推 global state” 对 Seam 的意义也比 DX 更深，我相信你肯定在 Next.js 项目里面或者任何 React 全栈框架里面已经见过了下面这一坨玩意 ↓ ```typescript ``` 当然这个不是没有解决方案，这种"金字塔"式的 Provider 嵌套其实还可以写成 Compose Providers. 大概就是变成下面那个样子。具体就是把原来一堆嵌套的 Provider 丢数组，然后定义一个组合函数，最后再吃这一层即可。~~但是这个对我来说其实就是一种自欺欺人的行为~~，本质上只是"藏起来"了, 又不是真的消除了。也就是从视觉上的嵌套变成了逻辑上的嵌套而已，某种意义上的 "眼不见为净" 纯纯的自我安慰 ```typescript const AppProviders = composeProviders([ ThemeProvider, AuthProvider, QueryClientProvider, I18nProvider, RouterProvider, ]); function composeProviders(providers: React.FC<{ children: React.ReactNode }>[]) { return ({ children }: { children: React.ReactNode }) => providers.reduceRight( (acc, Provider) => {acc}, children ); } function Root() { return ( ); } ``` React 项目最后真的非常容易或者说 100% 变成这样，那么就会产生一个 Seam 很讨厌的问题，也就是「component 的输入到底是什么?」表面上可以说是 `` 好像只依赖 `product` 本身？可是实际上呢 ```text depends on: product theme locale queryClient router auth featureFlags ... ``` 于是 component dependency graph 又将会变成隐式的，对于 traditional SSR 没太大问题，大不了就是「把整棵 React tree 跑一遍」嘛，但是 Seam 最后想问的还是 ProductCard 能不能独立 [CTR](https://canmi.net/architecture/compile-time-rendering?lang=mw#maybe-ctr) 那么这个时候就会真的非常麻烦。甚至可以说要改掉整个 React 编译器的行为和用户的 DX & 习惯，那么何必呢... 用 Next.js 的人基本上已经不在乎性能[^29]了，我可以很负责的说这句话；他们更多的是再为 Vercel 配套设施买单，如果你用 Next.js 不 hosted on Vercel 那真是一点好处都不吃 😡 #### Local ownership 反观 Svelte，它会是非常容易形成局部 ownership 的； ```svelte ``` 从 Svelte / Seam Compiler 的角度来看这非常舒服毕竟「**input**: `product` + **local client state**: `quantity`」Ownership 真的非常清楚了 ```text product.name → server CTR quantity → client button onclick → client rest → static ``` 但是这只是默认，其实也不是保证; 因为 `getContext('theme')` 和 `.svelte.ts` 里的 `rune module` 仍是隐式输入，另外就是 `QueryClient` 也不会凭空消失。我觉得 Seam 的态度会和前面的 hatch 名单一样：看见就标进 IR（`server` 依赖或 `client` 所有权），分析不了就当 `opaque`，还是不要假装「Svelte 没有 Provider 这回事」比较好呢。~~但是也不一定，也许我稍微在研究一下可能是可以找到 Provider 的处理方案的~~ React 时代里 Seam 最大的问题是 IR 走了 `Component` → `execute renderer` → `get output`, 那么我最后所谓的 `seam compiler` 实际上变成了某种意义上的提前 `SSR` 或者完全可以说做是「***universal SSR orchestration layer***」 *** ### Same protocol 所以从现在开始可以说 **UI 就是 Svelte** 但 `seam` 协议本身还是协议，还是 `slot`、`injection` 为主，~~*JTD 到底合不合适还有待我进一步考虑*~~；从执行决策上来看现在就是已经是完全分层来的，已经 `residual` 化的槽，`Rust` / `Go` / `TS` server 只需要瞎填就行完全不需要理解组件代码，真正的零 JS；与此同时如果组件里还有纯派生，那么可以考虑加入一个 `generated JS` / `QuickJS runtime`，*(注意这里是在跑数据，不是在跑 UI)* 只有 `hatch` 的才会 `SSR fallback`, 那么后端在不需要真 SSR 的情况下是可以不跑 UI 代码的，自然也就不存在绑死在 `Node` OR `Bun` 上，但是呢 (Go Server 计划停止维护，~~因为个人尽力不足如果有好心人有时间的话可以捡起来长期维护，并不是架构不支持后端无关性了~~) 换句话说，我只砍掉了 UI 我谁都接这种费力不太好的事情(?) 不变的部分还是可以作为「Rendering Protocol」后端不限 JS/TS ### Runes 还有一个很重要的点就是 Svelte 5 的 runes 对 Seam 非常友好，虽然 Svelte 5 开始变得更 JS 一点 ```javascript let count = $state(0); let doubled = $derived(count * 2); ``` 但此 JS 非彼 JS[^30]，和 `useState` / `useMemo` / `useContext` / `useEffect` 的差别是：**runes** 仍是 `compiler-recognized semantics` 所以 Seam 能知道 `$state` 是 **client** 所有，`$derived` 是派生，`$effect` 是 **client runtime**; 这和 `const foo = someLibraryHook()` 不在一个量级。 *** ### Data origin 这里有一个很重要的点是「认得出来」其实不等于「能 CTR」，尤其不要看到 `$derived` 就默认它进 `skeleton`，其实上面这个 `count * 2` 就是反例之一，因为依赖是 `$state`，所以这是 client 派生产物。可以看看能 CTR 的 `$derived` 其实长这样： ```javascript let { product } = $props(); let price = $derived(formatPrice(product.price)); ``` `product` 来自 `$props`，`formatPrice` 还得纯并且可见，接到前面那张表上就是这样子的 ```text $state / $effect / onclick → client $derived deps ⊆ server data, pure, visible → CTR derive deps include $state → client impure or opaque callee → QuickJS or SSR fallback markup → follow the table above; runes are not a free CTR pass ``` *** 这样画出来看可能更好理解(?) > [diagram: 一个管道从“Svelte source”开始，流入“Svelte / Seam AST”（“visible + typed”），随后分成三条并行路径。“Structure”（“markup AST”）指向“Static HTML”，而“Values”（“data + derives”）指向“CTR slots”（“lowered data”），并且“Behavior”（“state + effects”）指向“Client JS”。 — https://canmi.net/architecture/observation-to-lowering] 反正就是 Runes 友好体现为所有权标在语法上，不是因为 `$derived` 自带 **CTR** 资格，判断的唯一标准其实还是下面路径展示的数据从哪来、纯不纯、看不看得见(x) > [diagram: 一个分支管道从“CTR candidate”和“value / derive”开始，流入“Lowering decision”，该阶段考虑“origin · purity · visibility”，并强调“never syntax alone”。随后，上分支对比一个“simple”案例，它是“pure + visible”，导致“generated JS”，而下分支是一个“complex”案例，它是“opaque / hatch”，导致“QuickJS / SSR”“fallback”。 — https://canmi.net/architecture/observation-to-lowering] 然后旁边再加上一条 `