يستكشف مقال منشور على مدونة JetBrains إمكانية استخدام Compose HTML لبناء واجهات ويب تُعرض من الخادم ضمن بيئة Kotlin، في وقت تعيد فيه أطر متعددة توجيه جزء من معالجة الواجهات إلى الخادم. الفكرة المقترحة تتمثل في توفير مكونات Compose قابلة لإعادة الاستخدام وآمنة النوع، بدلاً من كتابة قوالب نصية منفصلة عن كود التطبيق. ويشدد المقال على أن ما يطرحه يمثل استكشافاً للأفكار وليس التزاماً رسمياً من JetBrains أو إعلاناً عن واجهات برمجية أو خارطة طريق.
ينطلق الطرح من مقارنة مع مسارات ظهرت في منظومات أخرى؛ إذ أطلقت 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، فتكون البطاقة دالة typed تتلقى عنواناً من نوع 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، لا في تقديم منتج متاح أو ميزة مؤكدة. وفي حال تطور الفكرة، سيكون التحدي الأساسي هو الموازنة بين بساطة النواة، والتكامل مع أطر الخادم، ومتطلبات التفاعل وإعادة استخدام المكونات بين العميل والخادم.