JetBrains Blog'da yayımlanan bir makale, birden çok çerçevenin arayüz işleme sürecinin bir bölümünü sunucuya yönlendirdiği bir dönemde, Kotlin ortamında sunucudan oluşturulan web arayüzleri geliştirmek için Compose HTML'nin kullanılma olasılığını inceliyor. Önerilen fikir, uygulama kodundan ayrı metin şablonları yazmak yerine yeniden kullanılabilir ve tür güvenli Compose bileşenleri sunmak. Makale, ortaya koyduğu şeyin JetBrains'in resmî bir taahhüdü, API duyurusu ya da yol haritası değil, fikirlerin keşfi olduğunu vurguluyor.
Yaklaşım, diğer ekosistemlerde ortaya çıkan yollarla yapılan bir karşılaştırmayla başlıyor. React sunucu bileşenlerini kullanıma sundu, HTMX hypermedia modeline olan ilgiyi yeniden canlandırdı; Phoenix LiveView ise bir istemci çerçevesine dayanmadan sunucudan etkileşimli güncellemeler gönderilebileceğini kanıtladı. Makale, JVM ekosisteminde sunucudan oluşturma için çok sayıda kütüphane bulunduğunu, ancak bunların genellikle şablon dillerine dayandığını ve JavaScript geliştiricilerinin bildiği bileşen kavramına yeterince yakın bileşenler sunmadığını belirtiyor.
Neden Compose HTML?
Compose Multiplatform, iş mantığını ve kullanıcı arayüzlerini bir kez yazıp Android, iOS, masaüstü cihazlar ve web arasında paylaşma olanağı sunuyor. Ancak Compose Multiplatform'daki mevcut web hedefi doğrudan canvas içinde oluşturmaya dayanıyor. Makaleye göre bu durum, arama motoru görünürlüğünü iyileştirme, yükleme süreleri ve erişilebilirlikle ilgili maliyetler doğuruyor.
Compose for Web'den daha eski olan Compose HTML, Kotlin ile tek sayfalı uygulamalar oluşturmak için Compose Runtime'ı kullanıyor ve bunları Kotlin/JS derleyicisi aracılığıyla JavaScript'e çeviriyor. Makale, sunucudan oluşturma gerçekleştirebilmesi için buna bir JVM hedefi eklenmesini öneriyor. Böylece ayrı bir şablon dili olmadan, gerçek bileşenler ve türler kullanılarak doğrudan Kotlin içinde bir HTML ağacı oluşturulabilecek.
Kaynak, Thymeleaf'te yazılmış bir kart bileşeni ile Compose bileşeni arasında bir karşılaştırmalı örnek sunuyor. Şablon tabanlı modelde kart ayrı bir dosyada tanımlanıyor ve parametreler tür denetimiyle ilişkilendirilmemiş dizeler olarak aktarılıyor. Compose'ta ise kart, String türünde bir başlık ve Int türünde bir sayı alan typed bir işlev oluyor. Bu nedenle parametrenin adını değiştirmek, geliştirme ortamındaki kullanım noktalarının güncellenmesini ya da derleme sırasında hata oluşmasını sağlıyor. Benzer şekilde, yanlış türde bir değer geçirmek, çalışma sırasında ortaya çıkan bir sürpriz yerine derleyici hatasına yol açıyor.
Sunucudan oluşturma tasarımı
Önerilen tasarım, composition işlemini JVM üzerinde bir kez çalıştırmak ve ortaya çıkan ağacı HTML metnine ya da bayt verilerine dönüştürmek için renderToString ve renderToBytes gibi işlevlerin eklenmesini gerektiriyor. Verilen örneğe göre işlem; metin ve kapsayıcı öğeler gibi bileşenler oluşturuyor, ilk bileşimin kararlı hâle gelmesini bekliyor, ardından ortaya çıkan ağaçta gezinerek tarayıcı veya DOM olmadan bunu HTML'ye dönüştürüyor.
Bu modelin belirgin kısıtlamaları var. Durum değiştiğinde yeniden composition yapılmadan veya efektler yürütülmeden tek bir oluşturma aşamasıyla sınırlı kalması muhtemel; bu da onu JavaScript çerçevelerindeki sunucudan oluşturma kavramına yaklaştırıyor. Bileşenlerde olay dinleyicileri kabul edilebilir, ancak sunucuda etkisiz kalacaklar; çünkü orada HTML oluşturulurken tarayıcı olaylarını bağlamanın bir yararı yok.
Makale, Spring Boot kullanarak eksiksiz bir görev uygulaması tasarımını sunuyor. Buna göre bir GET rotası görevler sayfasını oluştururken POST istekleri yeni bir görev ekliyor veya görev durumunu değiştiriyor. Bu senaryodaki etkileşimler, istemci tarafında JavaScript olmadan, Thymeleaf kullanılarak oluşturulan geleneksel uygulamalara benzer şekilde gerçek HTTP formlarının gönderilmesine ve sayfanın yeniden yüklenmesine dayanacak. Ancak arayüzün tamamı Compose içinde yazılacak.
Mevcut durum ve olası çerçeveler
Compose HTML'nin şu anda yalnızca JS hedefi var; bu nedenle sunucudan oluşturma olanağı sunmuyor. Bununla birlikte makale, Compose for Web çevresinde aktif bir ekosistem bulunduğuna işaret ediyor. Kobweb, Compose HTML üzerine kurulmuş ve arama motoru görünürlüğünü iyileştirmeye yardımcı olmak için statik site dışa aktarmayı ve önceden oluşturmayı destekliyor, ancak SSR sunmuyor. Kilua ise SSR ve CSR gerçekleştirmek için doğrudan Compose Runtime'a dayanıyor ve Ktor ile Spring Boot'un yanı sıra diğerleriyle entegrasyonlar sunuyor. Summon da SSR ve hydration desteği sağlıyor.
Yaklaşım, Compose HTML'ye SSR yetenekleri eklenmesinin Kobweb, Kilua ve Summon'a üç ayrı yol kullanmak yerine ortak bir temel sağlayabileceğini öne sürüyor. Ayrıca Spring Boot ve Ktor çerçevelerine Compose HTML ile sunucu üzerinde bütünleşmek için pratik bir neden sunabilir. Ancak bu sonuç garanti edilmiş veya duyurulmuş değil; makale bunu, deneyler ve gerekli entegrasyon noktalarının belirlenmesini gerektiren olası bir yön olarak tanımlıyor.
İlk oluşturmanın ötesinde
Keşif daha sonra hydration ve durum senkronizasyonu sorusuna yöneliyor: Sunucuda oluşturulan bileşenler tarayıcı içinde etkileşimli çalışmalarını nasıl sürdürecek? Sunucu ve istemcinin durum üzerinde anlaşması gerekecek mi? Makale, bu sorunların çözülmesinin arayüz kodunun iki taraf arasında paylaşılmasını mümkün kılabileceğini belirtiyor. Böylece aynı bileşen hem tarayıcı hem de sunucu için derlenebilir ve tamamen Kotlin ile yazılmış, tam etkileşimli web uygulamaları desteklenebilir.
Bununla birlikte tasarım, Compose HTML'yi tüm bileşenleri ve işlemleri içeren, kullanıma hazır ve eksiksiz bir çerçeveye dönüştürmeyi önermiyor. Kaynağın açıkladığı üzere en yakın hedef, çekirdeği küçük tutmak ve çerçeve entegrasyonlarının yanı sıra ekosistem kütüphanelerinin geliştirilmesini React'in yaklaşımına benzer biçimde topluluğa bırakmak; ancak bunu çok platformlu bir kütüphane içinde yapmak. Bu yaklaşım, Compose Multiplatform'un Material3, durum yönetimi ve diğerleri için resmî kütüphaneler sunan bölümlerinden farklı.
Makaleye göre Kobweb, Kilua ve Summon geliştiricileriyle görüşmeler yapılarak fikirleri toplanıyor. Ayrıca Compose HTML'ye JVM hedefi eklenmesinin ardından Spring ekibi de denemeye ilgi gösterdi. Bu nedenle bu yaklaşımın mevcut değeri, JVM üzerinde web geliştirme için olası bir yön belirlemesinde yatıyor; mevcut bir ürün veya kesinleşmiş bir özellik sunmasında değil. Fikir gelişirse temel zorluk, çekirdeğin basitliği, sunucu çerçeveleriyle entegrasyon ve istemci ile sunucu arasında etkileşim ve bileşenlerin yeniden kullanılması gereksinimleri arasında denge kurmak olacak.