Explorando Compose HTML para Renderização do Lado do Servidor
Algo está acontecendo no desenvolvimento de web renderizado pelo servidor. O React lançou Componentes do Servidor. O HTMX tornou 'hipermídia' legal novamente. A Phoenix LiveView provou que um servidor pode enviar atualizações interativas da interface do usuário sem a presença de um framework cliente. Cada ecossistema parece estar redescobrindo o servidor como lugar para renderizar interfaces, exceto um: a JVM. E se o Compose, a ferramenta de interface já presente em Android, Desktop e iOS, desse uma chance à renderização do HTML pelo lado do servidor também?
A visão é simples: dar aos desenvolvedores backend uma maneira de construir interfaces renderizadas pelo servidor como componentes Compose tipo-safos e reutilizáveis (real Kotlin, com autocompletar, refatoração e verificações do compilador) em vez de modelos baseados em strings. Nenhuma linguagem de modelo separada, nenhuma base de código UI a manter ao lado do backend. Este blog serve para explorar algumas ideias sobre como alcançar essa visão e representa uma exploração em vez de um compromisso oficial.
Toda grande framework JS agora tem sua história de SSR: o React tem o Next, o Vue tem o Nuxt, o Svelte tem o SvelteKit. E não é apenas o ecossistema JS. C#, Rust e até mesmo linguagens funcionais como Elixir têm soluções inovadoras para construir aplicações fullstack sem depender de motores de modelagem. Em vez disso, eles empacotam estado e renderização em componentes reutilizáveis diretamente no código, da mesma maneira que o Compose já faz em todos os lugares.
Agora mesmo a JVM não tem um cavalo nesta corrida. Não falta bibliotecas SSR na JVM. Mas a maioria delas precisa de algum tipo de linguagem de modelo e nada próximo suficiente para ser reconhecido como componente por um desenvolvedor JS.
Mas já existe um framework que é testado em batalha e capaz de preencher essa lacuna na JVM, ele apenas nunca realmente mirou o servidor. O Compose Multiplatform permite escrever lógica de negócios e Interfaces do Usuário uma vez e compartilhá-las entre plataformas: Android, iOS, Desktop e a web. Ele só precisa dar um salto para o servidor.
O Compose Multiplatform já mira na web, mas não da maneira que você gostaria para isso: renderiza diretamente em uma tela, compartilhando código de interface entre plataformas móveis e o navegador ao custo do SEO, tempos de carregamento e acessibilidade.
Uma maneira de renderizar HTML com Compose já existe, e é mais antiga que o Compose para Web: o Compose HTML, que usa a runtime do Compose para construir SPA em Kotlin e compila isso para JS usando o compilador Kotlin/JS. Adicione um alvo JVM e poderia fazer SSR também. A renderização acontece diretamente em Kotlin: componentes reais, tipos reais, nenhuma linguagem de modelo.
Desenvolvedores JVM presos com Thymeleaf/JSP ou alcançando por um framework JS separado apenas para construir aplicações fullstack não teriam que deixar a plataforma: componentes Compose tipo-safos e reutilizáveis substituem o que a linguagem de modelo costumava lidar. A interoperabilidade Java do Kotlin significa que se encaixaria em grandes aplicativos legados Java também.
Pegue algo tão básico quanto um componente cartão reutilizável. Em Thymeleaf, isso é uma fragmento definida em seu próprio arquivo, chamada pelo nome, com parâmetros passados como strings não tipadas: