В статье, опубликованной в блоге JetBrains, рассматривается возможность использования Compose HTML для создания веб-интерфейсов, отображаемых на сервере в среде Kotlin, в то время как несколько фреймворков переносят часть обработки интерфейсов на сервер. Предлагаемая идея заключается в предоставлении повторно используемых и типобезопасных компонентов Compose вместо написания текстовых шаблонов, отделённых от кода приложения. В статье подчёркивается, что изложенное представляет собой исследование идей, а не официальное обязательство JetBrains, объявление API или дорожную карту.
Предложение начинается со сравнения с направлениями, появившимися в других экосистемах: React представил серверные компоненты, HTMX вновь привлёк внимание к модели hypermedia, а Phoenix LiveView продемонстрировал возможность отправки интерактивных обновлений с сервера без зависимости от клиентского фреймворка. В статье отмечается, что экосистема JVM располагает множеством библиотек для серверного рендеринга, однако они часто используют языки шаблонов и не предлагают компонентов, достаточно близких к концепции компонентов, знакомой разработчикам JavaScript.
Почему Compose HTML?
Compose Multiplatform предоставляет способ однократно писать бизнес-логику и пользовательские интерфейсы и совместно использовать их на Android, iOS, настольных компьютерах и в вебе. Однако текущая веб-цель Compose Multiplatform основана на непосредственном рендеринге внутри canvas, что, согласно статье, создаёт затраты, связанные с оптимизацией для поисковых систем, временем загрузки и доступностью.
Compose HTML, предшествующий Compose for Web, использует Compose Runtime для создания одностраничных приложений на Kotlin с последующей компиляцией в JavaScript посредством компилятора Kotlin/JS. В статье предлагается добавить к нему цель JVM, чтобы он мог выполнять серверный рендеринг: дерево HTML создавалось бы непосредственно в Kotlin с использованием настоящих компонентов и типов, без отдельного языка шаблонов.
Источник приводит сопоставительный пример компонента карточки, написанного в Thymeleaf и в Compose. В шаблонном подходе карточка определяется в отдельном файле, а параметры передаются как строки без проверки типов. В Compose карточка является типизированной функцией, принимающей заголовок типа String и число типа Int. Поэтому изменение имени параметра приводит к обновлению мест использования через среду разработки или к ошибке во время компиляции, а передача неправильного типа вызывает ошибку компилятора, а не неожиданность во время выполнения.
Концепция серверного рендеринга
Предлагаемая концепция требует добавления таких функций, как renderToString и renderToBytes, для однократного выполнения composition на JVM с последующим преобразованием полученного дерева в HTML-текст или байтовые данные. Согласно приведённому примеру, процесс создаёт такие компоненты, как текст и контейнерные элементы, ожидает стабилизации первоначальной композиции, затем проходит по полученному дереву и преобразует его в HTML без браузера или DOM.
У этой модели есть очевидные ограничения. Вероятно, она будет ограничиваться одной фазой рендеринга без рекомпозиции при изменении состояния или выполнения эффектов, что делает её близкой к концепции серверного рендеринга во фреймворках JavaScript. Обработчики событий в компонентах также могут быть приняты, однако на сервере они будут неактивны, поскольку связывать события браузера при создании HTML на сервере бессмысленно.
В статье рассматривается концепция полноценного приложения задач на базе Spring Boot: маршрут GET отображает страницу задач, а запросы POST добавляют новую задачу или изменяют её состояние. В этом сценарии взаимодействие будет основываться на отправке настоящих HTTP-форм и перезагрузке страницы без JavaScript на стороне клиента — подобно традиционным приложениям представления на Thymeleaf, но с написанием всего интерфейса внутри Compose.
Текущее состояние и потенциальные фреймворки
В настоящее время Compose HTML имеет только цель JS и поэтому не предоставляет серверный рендеринг. Тем не менее статья указывает на наличие активной экосистемы вокруг Compose для веба. Фреймворк Kobweb построен поверх Compose HTML и поддерживает экспорт статических сайтов и предварительный рендеринг для улучшения видимости в поисковых системах, но не предоставляет SSR. Kilua напрямую использует Compose Runtime для реализации SSR и CSR и предлагает интеграции с Ktor, Spring Boot и другими платформами, тогда как Summon поддерживает SSR и hydration.
Согласно предложению, добавление возможностей SSR в Compose HTML может предоставить Kobweb, Kilua и Summon общую основу вместо трёх отдельных направлений. Это также может дать фреймворкам Spring Boot и Ktor практическую причину для интеграции с Compose HTML на сервере. Однако такой результат не гарантирован и не объявлен: статья описывает его как потенциальное направление, требующее экспериментов и определения необходимых точек интеграции.
После первоначального рендеринга
Дальнейшее исследование переходит к вопросу hydration и синхронизации состояния: как компоненты, отображённые на сервере, продолжают интерактивную работу в браузере? Должны ли сервер и клиент согласовывать состояние? В статье отмечается, что решение этих задач может позволить совместно использовать код интерфейса обеими сторонами: один и тот же компонент будет компилироваться для браузера и сервера, поддерживая полнофункциональные интерактивные веб-приложения, полностью написанные на Kotlin.
При этом концепция не предполагает превращения Compose HTML в готовый полноценный фреймворк со всеми компонентами и возможностями. Ближайшая цель, как поясняет источник, — сохранить ядро небольшим, а создание интеграций с фреймворками и библиотеками экосистемы оставить сообществу, следуя подходу, похожему на React, но в рамках мультиплатформенной библиотеки. Это отличается от других частей Compose Multiplatform, которые предоставляют официальные библиотеки для Material3, управления состоянием и прочего.
Согласно статье, ведутся обсуждения с разработчиками Kobweb, Kilua и Summon для сбора их мнений, а команда Spring проявила интерес к эксперименту после добавления цели JVM в Compose HTML. Поэтому текущая ценность этого предложения заключается в определении потенциального направления развития веб-разработки на JVM, а не в предоставлении доступного продукта или подтверждённой функции. Если идея получит развитие, основной задачей станет баланс между простотой ядра, интеграцией с серверными фреймворками и требованиями к интерактивности и повторному использованию компонентов между клиентом и сервером.