探索Compose HTML用于服务器端渲染
内容提要
本文探讨了将Compose HTML用于服务器端渲染（SSR）的构想，旨在为JVM开发者提供类型安全、可复用的UI组件，替代传统模板引擎。通过添加JVM目标，Compose HTML可实现SSR，支持Spring Boot和Ktor等框架集成。文章展示了示例代码，并讨论了与Kobweb、Kilua等框架的协作，强调社区驱动发展，但明确表示这是探索而非官方承诺。
延伸解读
JVM生态的SSR空白
文章指出，尽管React、Vue、Svelte等前端框架以及C#、Rust、Elixir等语言都有成熟的SSR方案，但JVM生态却缺乏类似组件化的SSR方案。现有的JVM SSR库大多依赖模板引擎，缺少类型安全的组件模型。Compose HTML若支持SSR，将填补这一空白，为JVM开发者提供类似React的组件化开发体验。
类型安全与模板引擎的对比
文章通过对比Thymeleaf片段和Compose组件，展示了类型安全带来的优势。在Thymeleaf中，参数以字符串传递，重命名参数可能导致运行时错误；而在Compose中，参数类型在编译时检查，重命名或类型错误会立即暴露。这能显著减少运行时错误，提高代码可维护性。
现有框架的协作与局限
文章提到Kobweb、Kilua和Summon等框架已基于Compose进行Web开发，但各有局限：Kobweb仅支持静态导出，Kilua和Summon虽支持SSR但未基于Compose HTML。若Compose HTML增加JVM目标，这些框架可共享基础，减少重复工作，并促进与Spring Boot、Ktor等后端框架的集成。
探索性质与未来方向
文章强调这仅是探索，而非官方承诺。实现SSR需添加JVM目标，并面临单次渲染、无状态同步等限制。未来可能的方向包括与Spring、Ktor的集成，以及解决水合和状态同步问题。社区反馈和框架维护者的合作将决定其发展路径。
Q&A
Compose HTML用于服务器端渲染的构想是什么？
该构想是让JVM开发者能够使用类型安全、可复用的Compose组件来构建服务器端渲染的UI，替代传统的模板引擎（如Thymeleaf、JSP），从而无需维护单独的模板语言或UI代码库。
为什么JVM生态在服务器端渲染方面落后于其他生态？
因为JVM上的SSR库大多依赖模板语言，缺乏类似React、Vue等框架中的组件化能力，而其他生态如JS、C#、Rust、Elixir等已有创新的全栈解决方案。
Compose HTML目前如何工作？它有哪些局限性？
Compose HTML使用Compose运行时构建SPA，并通过Kotlin/JS编译器编译为JS，但仅支持JS目标，无法用于SSR。此外，Compose Multiplatform的Web目标直接渲染到canvas，不利于SEO、加载时间和可访问性。
在服务器端渲染中，Compose组件相比Thymeleaf模板有哪些优势？
Compose组件是类型安全的Kotlin函数，具有自动补全、重构和编译检查，参数类型错误会在编译时发现；而Thymeleaf模板使用字符串参数，重命名参数可能导致运行时错误。
如何为Compose HTML添加JVM目标以实现SSR？
需要添加JVM目标，并提供renderToString和renderToBytes函数，这些函数在JVM上运行一次组合，序列化生成的树为HTML字符串，无需浏览器或DOM。
Compose HTML的SSR有哪些限制？
可能只支持单次渲染，没有状态变化的重组或效果，事件监听器会被接受但不会在服务器端绑定。
Kobweb、Kilua和Summon这些框架与Compose HTML的SSR有什么关系？
这些框架已经基于Compose构建Web应用，但各有不同的实现方式。为Compose HTML添加SSR能力可以为它们提供共享的基础，促进协作和集成。
Compose HTML的SSR未来可能如何与Spring Boot或Ktor集成？
文章展示了假设性的集成示例：Spring可能通过@ComposePage注解将Composable函数映射为路由，Ktor可能提供composable(path)包装器，内部调用renderToString并返回HTML。
Compose HTML的SSR是否会成为官方承诺的功能？
不会，文章明确表示这只是一个探索，而非官方承诺。
