JetBrains 博客发表的一篇文章探讨了在 Kotlin 环境中使用 Compose HTML 构建由服务器渲染的 Web 界面的可能性。此时，多个框架正在重新将部分界面处理转移到服务器。提出的想法是提供可复用且类型安全的 Compose 组件，而不是编写与应用程序代码分离的文本模板。文章强调，其中提出的内容是对相关想法的探索，并不代表 JetBrains 的正式承诺，也不是 API 或路线图的声明。
这一设想始于与其他生态系统中出现的路径进行比较：React 推出了服务器组件，HTMX 重新引起了人们对 hypermedia 模型的关注，而 Phoenix LiveView 则证明了无需依赖客户端框架也可以从服务器推送交互式更新。文章认为，JVM 生态系统拥有许多服务器端渲染库，但它们通常依赖模板语言，也没有提供足够接近 JavaScript 开发者所熟悉的组件概念的组件。
为什么选择 Compose HTML？
Compose Multiplatform 提供了一种只编写一次业务逻辑和用户界面，并在 Android、iOS、桌面设备和 Web 之间共享的方法。不过，Compose Multiplatform 当前的 Web 目标依赖于直接在 canvas 中进行渲染。文章指出，这会带来与搜索引擎优化、加载时间和可访问性相关的成本。
Compose HTML 比 Compose for Web 更早出现，它使用 Compose Runtime 以 Kotlin 构建单页应用，然后通过 Kotlin/JS 编译器将其转换为 JavaScript。文章提出为其添加 JVM 目标，使其能够执行服务器端渲染：这样便可以使用真实的组件和类型，直接在 Kotlin 中创建 HTML 树，而无需单独的模板语言。
消息来源展示了一个使用 Thymeleaf 编写的卡片组件与 Compose 组件之间的对比示例。在基于模板的模型中，卡片定义在独立文件中，参数以不参与类型检查的字符串形式传递。而在 Compose 中，卡片是一个 typed 函数，接收 String 类型的标题和 Int 类型的数字。因此，重命名参数会通过开发环境更新所有使用位置，或在编译过程中产生错误；传递错误类型也会由编译器报错，而不是在运行时造成意外。
服务器端渲染设想
所提出的设想需要添加诸如 renderToString 和 renderToBytes 的函数，以便在 JVM 上执行一次 composition，然后将生成的树转换为 HTML 文本或字节数据。根据示例，该过程会创建文本和容器元素等组件，等待初始组合稳定下来，随后遍历生成的树并将其转换为 HTML，而无需浏览器或 DOM。
这一模型存在明显限制。它很可能仅限于单次渲染阶段，不会在状态变化时重新组合，也不会执行副作用，因此接近 JavaScript 框架中的服务器端渲染概念。组件可以接受事件监听器，但这些监听器在服务器上将处于空闲状态，因为在服务器生成 HTML 时，绑定浏览器事件没有意义。
文章还展示了一个使用 Spring Boot 构建完整任务应用的设想：GET 路由渲染任务页面，而 POST 请求则添加新任务或更改任务状态。在这一场景中，交互将依赖发送真正的 HTTP 表单并重新加载页面，不需要客户端 JavaScript，类似于使用 Thymeleaf 的传统渲染应用，但整个界面都在 Compose 中编写。
当前形势与潜在框架
Compose HTML 目前只有 JS 目标，因此不提供服务器端渲染。不过，文章指出，围绕 Compose Web 已经形成了活跃的生态系统。Kobweb 构建于 Compose HTML 之上，并支持静态网站导出和预渲染，以帮助提升搜索引擎优化，但不提供 SSR。Kilua 则直接依赖 Compose Runtime 来执行 SSR 和 CSR，并提供与 Ktor、Spring Boot 及其他框架的集成；Summon 则提供 SSR 和 hydration 支持。
这一设想认为，为 Compose HTML 添加 SSR 能力，或许可以为 Kobweb、Kilua 和 Summon 提供共同基础，而不是依赖三条独立路径。它还可以为 Spring Boot 和 Ktor 框架提供在服务器上集成 Compose HTML 的实际理由。但这一结果并不确定，也未被宣布；文章将其描述为一种可能的方向，需要通过实验并确定所需的集成点。
初始渲染之后
探索随后转向 hydration 和状态同步问题：在服务器上渲染的组件如何继续在浏览器中执行交互？服务器与客户端是否需要就状态达成一致？文章指出，解决这些问题或许可以实现双方共享界面代码，使同一个组件分别为浏览器和服务器进行编译，并支持完全使用 Kotlin 编写的完整交互式 Web 应用。
不过，这一设想并不建议将 Compose HTML 转变为一个包含所有组件和操作的完整现成框架。正如消息来源所说明的，较为接近的目标是保持核心足够小，并将框架集成和生态系统库的构建留给社区，这类似于 React 的方式，但应用于一个多平台库。它不同于 Compose Multiplatform 的其他部分，后者为 Material3、状态管理等提供了官方库。
文章称，目前正在与 Kobweb、Kilua 和 Summon 的开发者展开交流，以收集他们的意见；Spring 团队在为 Compose HTML 添加 JVM 目标后，也表达了对试验的兴趣。因此，这一设想当前的价值在于确定 JVM Web 开发的一个潜在方向，而不是提供一个可用产品或已确认的功能。如果这一想法继续发展，主要挑战将是平衡核心的简洁性、与服务器框架的集成，以及客户端与服务器之间的交互需求和组件复用要求。