Saat yang Tepat untuk Mengadopsi API Templating DOM

 (justinfagnani.com)
1 poin oleh GN⁺ 2025-06-28 | 1 komentar | Bagikan ke WhatsApp
  • Platform web saat ini kekurangan API templating deklaratif yang benar-benar dibutuhkan para pengembang
  • Di sebagian besar framework web modern, templating adalah teknologi inti, tetapi API DOM standar tidak memiliki cara yang aman dan efisien untuk membuat serta memperbarui template
  • Akibatnya, pengguna, pengembang, framework, bahkan platform itu sendiri sama-sama mengalami ketidaknyamanan dan penurunan performa
  • Ini adalah saat yang tepat untuk memperkenalkan API templating, karena pengalaman dari framework terbaru dan fitur JavaScript sudah cukup matang sehingga implementasi dan standardisasi menjadi lebih praktis
  • Dengan menggabungkan berbagai model seperti identitas template dan reaktivitas berbasis signal, arah untuk API templating generasi berikutnya pun diajukan

Ringkasan usulan

  • Tulisan ini menjelaskan latar belakang dan kebutuhan untuk menambahkan API templating deklaratif ke platform web
  • API DOM memang kuat, tetapi di DOM standar tidak ada API templating untuk membuat dan memperbarui banyak node secara aman dan efisien berdasarkan data
  • Framework utama seperti React, Vue, dan Angular semuanya menjadikan templating deklaratif sebagai inti, serta memberikan berbagai manfaat seperti produktivitas pengembang, keamanan, performa, analisis statis, dan server-side rendering
  • Karena tidak adanya API templating, pengguna, pengembang, framework, dan platform semuanya harus menghadapi kompleksitas yang tidak perlu, ancaman keamanan, penurunan performa, serta hambatan masuk
  • Penulis berargumen bahwa sekarang adalah waktu yang tepat untuk memperkenalkan API tersebut, dan mengusulkan standardisasi bertahap dengan memanfaatkan pengalaman dari framework yang ada serta fitur JavaScript modern

Kebutuhan akan template dan masalah saat ini

  • API DOM adalah fondasi yang mendorong kemampuan dinamis platform web
  • Namun, DOM standar tidak memiliki cara templating deklaratif untuk mendefinisikan pohon DOM secara aman dari data dan memperbaruinya secara efisien
  • Framework web modern (React, Vue, Angular, Svelte, dan lain-lain) semuanya menyediakan templating deklaratif
  • Alasan templating deklaratif populer adalah sebagai berikut
    • Memberikan kemudahan penggunaan dan keterbacaan yang lebih baik dibanding API imperatif
    • Memperkuat keamanan XSS. Data di dalam template di-escape secara otomatis
    • Performa rendering yang efisien dan cepat
    • Meningkatkan produktivitas pengembang melalui analisis statis, type checking, IntelliSense, dan sebagainya
    • Mendukung server-side rendering

Permasalahan situasi saat ini

  • Pengguna: pemuatan awal menjadi lambat karena harus mengunduh library dan mengalami jeda rendering. Ukuran kode klien membesar sehingga UX memburuk
  • Pengembang: perlu library terpisah (npm, CDN, dan sebagainya) untuk menggunakan template. Ada hambatan masuk dan ketergantungan pada muatan nonstandar
  • Framework: harus mengimplementasikan mesin templating sendiri. Ada trade-off berat antara performa, fitur, dan ukuran kode
  • Platform: dirugikan dalam persaingan dengan aplikasi native. Flutter dan SwiftUI, misalnya, menyediakan sistem template bawaan

Mengapa sekarang waktu yang tepat

  • Upaya terkait template di masa lalu (E4X, E4H, html template literal, dan sebagainya) gagal, tetapi saat itu masih lemah dalam pembaruan DOM
  • Baru-baru ini, di framework dan komunitas telah terkumpul cukup banyak best practice API templating
  • Usulan API berbasis JavaScript kini memungkinkan. Dalam standar JS saat ini, tagged template literal sudah tersedia
  • Di kalangan pengembang vanilla JS dan komunitas web component, kebutuhan akan manipulasi DOM yang nyaman juga terus meningkat
  • Usulan primitive tingkat rendah seperti DOM Parts juga berjalan paralel, tetapi API deklaratif tingkat tinggi dapat menawarkan manfaat yang lebih besar dan arah perkembangan yang lebih jelas

Analisis contoh sintaks template yang baik

  • Sistem template arus utama (React-JSX, Vue, Svelte, Angular, dan lain-lain) pada dasarnya sangat mirip karena berbasis pada sintaks markup + binding
  • Dalam template berbasis API JS, struktur umumnya adalah ekspresi template mengembalikan deskripsi DOM, lalu fungsi render terpisah menerapkannya ke DOM nyata
  • Upaya lama seperti E4X mengembalikan DOM itu sendiri sehingga model pembaruannya kurang baik

Kemungkinan API templating berbasis JavaScript

  • Melalui tagged template literal, API templating dapat dirancang tanpa memperkenalkan fitur JS baru
  • Sudah ada banyak bukti implementasi seperti JSX-to-Lit

Pembahasan integrasi JSX

  • Standardisasi JSX memerlukan definisi makna yang kompleks serta runtime semantics. JSX itu sendiri hanyalah sintaks
  • JSX nonstandar yang digunakan saat ini adalah transformasi sintaks murni, sehingga jika API templating standar diperkenalkan nanti, hal ini dapat dihubungkan ke kompilator yang mengubah JSX -> template literal
  • Jika di masa depan benar-benar ada standardisasi JSX, akan lebih mudah beralih ke struktur penerimaan tipe data yang disesuaikan dengan API templating

Hubungan dengan API templating berbasis HTML

  • Banyak pengembang dan komunitas meminta sistem templating HTML
  • Namun, sistem berbasis HTML membutuhkan perancangan sintaks dan ekspresi baru yang jauh lebih besar, seperti binding, bahasa ekspresi, dan control flow
  • Latar belakang framework modern (seperti Lit) yang berpindah dari template HTML ke API JS pun sama
  • Karena itu, kemungkinan besar API templating berbasis JS akan diperkenalkan lebih dulu, lalu diperluas secara bertahap ke API HTML di kemudian hari

Kematangan pengalaman implementasi reaktivitas (reactivity)

  • Berbagai model reaktivitas telah tervalidasi, seperti VDOM diffing (React), identitas template (Lit), dan signal (fine-grained signals, Solid/Svelte/Vue, dan lain-lain)
  • Pendekatan berbasis VDOM cenderung lambat, sedangkan kombinasi identitas template + model signal cepat, efisien, dan juga lebih mudah dijelaskan
  • Pendekatan berbasis signal memang mengharuskan semua data dibungkus sebagai signal, tetapi tetap dapat dicampur dengan data umum

Jalur perkembangan dan dampak yang diharapkan

  • API templating JS deklaratif yang diusulkan akan memberikan manfaat langsung bagi vanilla JS, web component, maupun framework baru
  • Ini juga dapat dimanfaatkan oleh framework yang ada sebagai target kompilasi, backend runtime, atau API yang didukung secara langsung
  • Mendukung baik pendekatan rerendering maupun reaktivitas berbasis signal
  • Menjadi fondasi untuk perluasan ke templating deklaratif berbasis HTML dan custom element deklaratif di masa depan
    • Cakupan API sempit dan jelas, serta mudah diintegrasikan dengan API yang sudah ada (misalnya DOM Parts)
  • Namun, meski API dan sintaks di permukaan tampak sederhana, area implementasinya luas, mencakup DOM Parts di bawahnya serta scheduler, sehingga standardisasi, pengujian, dan kolaborasi tetap diperlukan

Penutup

  • Penulis sedang mendiskusikan usulan ini di GitHub issue dan mengajak komunitas, termasuk para engineer platform, untuk berpartisipasi

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-28
Komentar Hacker News

  • Alasan saya tertawa saat mendengar kalimat “kita tahu seperti apa sintaks templating yang bagus” adalah karena menurut saya, pada praktiknya bahkan standar itu sendiri belum pernah benar-benar disepakati. Untuk templating, saya rasa pengalaman visual lebih penting daripada sudut pandang simbolik. Itulah juga alasan alat lama seperti Dreamweaver bisa begitu sukses. Banyak desainer memulai proses belajar mereka dari alat seperti Photoshop, dan itu masih dalam konteks yang sama. Saya agak menyayangkan karena upaya ini terasa seperti mencoba membuat ulang XSLT. Masalah inti templating adalah menggabungkan struktur yang tidak dirancang dengan baik menjadi hasil akhir yang tampak dirancang dengan baik. Lebih jauh lagi, ada persoalan bagaimana merepresentasikan entitas yang saling terhubung tetapi tidak berada dalam tree yang sama, seperti label dan for. Kalau saya bisa berandai-andai, saya berharap kita tidak memaksakan semuanya agar masuk secara aneh ke dalam tata letak dokumen standar. Dengan absolute positioning yang digunakan dengan baik saja, banyak masalah UI bisa diselesaikan secara efisien, jadi saya heran kenapa kita terus-menerus mencoba memaksa mesin menangani semua operasi matematis ini berulang kali

    • Saya setuju soal ini terasa seperti mencoba membuat ulang XSLT. Saya memang tidak suka XML itu sendiri, tetapi XSLT benar-benar sangat kuat. Ini juga masih didukung luas di browser. XML memang punya kelemahan yang jelas pada konfigurasi atau IPC, tetapi saya menyesalkan bahwa kombinasi bahasa markup yang hebat dengan kekuatan transformasi XSLT justru tidak benar-benar dimanfaatkan. XSLT gagal menjadi arus utama karena ia adalah DSL yang benar-benar deklaratif dan fungsional. Banyak orang berbicara positif tentang DSL, tetapi dalam praktiknya sering kali itu hanya pembungkus tipis di atas semantik prosedural dari bahasa yang sedang populer. Dengan DSL yang dirancang baik, pekerjaan kompleks bisa dibuat sederhana, dan saya rasa masalahnya adalah kurangnya kemauan untuk benar-benar mempelajarinya

    • Anda bilang inti dari sintaks templating yang baik adalah sifat visualnya, dan saya ingin tahu bagaimana Anda sampai pada kesimpulan itu. Menurut saya ini terdengar lebih seperti keluhan terhadap HTML+CSS itu sendiri, yaitu terhadap cara hasil akhirnya dibentuk. Saya juga penasaran kenapa Anda menyebut absolute positioning. Memang itu berguna di tempat yang tepat, tetapi ketika dipakai untuk seluruh layout, justru sulit dipelihara dan mudah rusak tergantung ukuran layar atau banyaknya konten. Bahkan layout koran pun pada kenyataannya melibatkan banyak unsur halus dari teks dan tipografi, jadi tidak bisa diselesaikan hanya dengan absolute positioning. Dalam pengalaman saya saat bekerja mendalam dengan CSS, sering kali lebih cepat dan lebih mudah menyelesaikan masalah dengan membangun ulang layout yang awalnya memakai absolute positioning menjadi flex atau flow. calc() dan viewport units memang bisa memberi makna tertentu, tetapi dalam praktiknya absolute positioning tidak cocok kecuali konten atau viewport-nya benar-benar tetap

    • Saya pernah melihat argumen bahwa orang berputar terlalu jauh untuk mencapai efek yang sama, padahal dengan absolute positioning yang digunakan dengan baik, implementasinya bisa jauh lebih mudah dan cepat. Namun di web ada tuntutan agar dokumen tetap terlihat baik pada semua ukuran perangkat, orientasi, dan tingkat performa. Aplikasi biasa, seperti aplikasi Windows, tidak punya masalah seperti itu, dan aplikasi mobile pun umumnya hanya perlu memikirkan ukuran layar yang sudah cukup terstandarisasi. Hanya web yang memiliki sifat harus menangani semua itu

    • Saya rasa menanggapi “sintaks templating yang bagus” dengan nada menyindir bukanlah sikap yang terlalu sopan terhadap orang yang sedang mendorong kemajuan. Dan saya rasa saat ini memang ada sintaks templating yang bagus, yaitu jsx. Saya bukan penggemar React, tetapi saya pikir jsx telah membawa revolusi dalam pengembangan web, dan sebagian besar sistem templating js pada akhirnya hampir semuanya berkumpul pada pola “template sebagai ekspresi”, “komposisi melalui nesting”, dan penanganan control flow lewat JavaScript

    • React dan Svelte hanya tampak mirip di permukaan, tetapi cara kerjanya sebenarnya cukup berbeda. Inti React adalah fungsi JavaScript yang (hampir) biasa mengembalikan markup lazy dalam bentuk JSX. Tidak ada sintaks khusus di level template untuk loop atau conditional rendering; semuanya ditangani dengan JavaScript biasa, dan itu adalah perbedaan utamanya

  • Saya terus belajar bahwa API dan ABI (application binary interface) tidak pernah benar-benar final. Kebutuhan aplikasi tidak statis; ia terus berubah seiring waktu, jadi API sempurna yang bisa dipakai selamanya itu tidak ada. Proposal ini adalah contoh yang bagus. Awalnya masalah diselesaikan oleh library di userland seperti React, lalu pada akhirnya turun menjadi standar. Polyfill juga mengikuti pola yang sama. Bahkan jika proposal seperti ini berhasil, pada akhirnya ia akan menjadi teknologi lama juga, dan orang-orang akan membuat cara baru untuk mengakalinya. DOM API, ECMA, browser lama, semuanya punya nasib yang sama. Ini membuat saya bertanya-tanya apakah entropi teknis, ekstensibilitas, dan backward compatibility itu sendiri bisa dianggap sebagai use case standar

    • Menambahkan fitur baru ke web standard pada akhirnya menciptakan beban kode pemeliharaan yang sangat besar, dan browser yang ingin patuh terhadap standar juga harus terus menambah implementasinya. Proyek seperti Servo selalu terjebak dalam situasi harus mengejar perluasan demi perluasan. Saya ingin web platform bisa memiliki semua kemampuan lingkungan native, tentu dalam batas privasi dan sandbox. Saya juga ingin pengalaman developer menjadi sangat baik. Tetapi untuk mewujudkan impian itu, kita harus mempertimbangkan harga berupa peningkatan kompleksitas. Saya ragu apakah native templating yang sedang dibahas kali ini benar-benar akan meningkatkan pengalaman developer secara jelas

    • Jika backward compatibility tetap dipertahankan dan antarmuka tidak diubah, bukankah versioning justru yang seharusnya mengambil peran itu?

    • Argumennya memang bahwa ketika sesuatu menua, orang akan terus mengakalinya atau menambalnya, tetapi di proses itu ada juga efek positif berupa naiknya level kemampuan dasar yang tersedia. Pembaruan bertahap tetap sangat berharga, meskipun kebutuhan pengguna terus menemukan celah dan use case baru

    • Saya tidak setuju dengan pernyataan bahwa “API dan ABI tidak akan pernah stabil selamanya”. Misalnya, getElementById sudah stabil selama lebih dari 25 tahun. Gagasan bahwa API yang tak berubah itu mustahil terdengar lebih seperti bentuk keputusasaan pribadi, padahal ada banyak pengecualian di dunia nyata. Permintaan memang tak ada habisnya, jadi tinggal tambahkan API baru. Tidak perlu merusak API yang sudah berjalan

    • Di web, begitu sebuah API dipublikasikan, akan selalu ada pengguna yang bergantung seumur hidup pada bentuk persisnya. Karena itu, gema dari keputusan yang dibuat 20 tahun lalu masih bisa terus terasa sampai sekarang. Contohnya bisa dilihat pada kasus "smooshgate"

  • Dengan menyinggung tren reactive programming, ada yang berargumen bahwa sistem di level userland sudah cukup banyak bereksperimen di area ini, dan sekarang saatnya mengumpulkan kelebihan dari berbagai pendekatan untuk membuat sistem standar yang sesungguhnya. Namun saya rasa eksplorasi belum selesai, karena di tempat seperti Ryan Carniato/Solid JS masih terus dijajaki kemungkinan baru dengan memanfaatkan signals. Masih banyak ruang untuk berkembang

  • Web benar-benar membutuhkan native template, reactivity, dan data binding. Pemborosan CPU dan bandwidth ketika miliaran pengguna di seluruh dunia harus mengunduh, mem-parse, dan menjalankan framework berat seperti React itu nyaris tak terbayangkan

    • Dibandingkan dengan pemborosan sumber daya luar biasa dari LLM dan operasi kriptografi, pemborosan seperti ini terasa tidak seberapa

    • Di TC39 sedang ada proposal terkait signals, dan berkat itu kita sedang bergerak selangkah lebih maju

    • Yang sebenarnya dibutuhkan untuk pengembangan mungkin cukup two-way data binding dan semacam klon jsx

    • React bukan sistem templating

  • Saat mengikuti diskusi tentang memasukkan sistem templating tingkat tinggi ke web standard, saya justru berpikir yang seharusnya disediakan lebih dulu adalah low-level API bawaan browser. Hampir mustahil membuat semua orang sepakat pada satu sistem templating standar. Sebaliknya, browser bisa menyediakan low-level API untuk menerapkan diff ke DOM. Misalnya, akan bagus jika ada method native seperti ini: element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' }). Dengan menerapkan diff seperti itu, kita bisa memperbarui elemen yang ada secara non-destruktif sambil mempertahankan focus, nilai input, status audio/video, dan sebagainya. Memang sudah ada library js seperti Idiomorph, tetapi solusi native kemungkinan besar akan jauh lebih cepat

    • Artikel tersebut menautkan proposal DOM parts. Proposal ini sangat berguna sebagai low-level API. Mungkin kurang cocok untuk framework berbasis VDOM, tetapi untuk framework lain ia bisa menyederhanakan implementasi dan membuka lebih banyak ruang optimasi. Jika nanti proposal signals juga diterapkan, kegunaannya bahkan akan tinggi tanpa framework sekalipun

  • Penulis artikel ini diperkenalkan sebagai orang dengan pengalaman tingkat tertinggi di bidang terkait. Ia berkontribusi besar pada Lit, Polymer, web components milik Google, dan berbagai spesifikasi inti DOM

    • Namun ada kritik bahwa banyak spesifikasi yang ia dorong justru menimbulkan lebih banyak masalah. Untuk solusi dangkal yang belum benar-benar matang, web akhirnya memerlukan lebih dari 20 spesifikasi, dan hal-hal yang sebenarnya sudah bisa dilakukan di userland justru distandardisasi dengan cara yang terlalu rumit. Selain itu disebutkan bahwa sejak 15 tahun lalu Safari sudah menekankan perlunya pendekatan deklaratif, tetapi diabaikan

  • Daripada pendekatan ala JSX, saya menginginkan pendekatan sintaks seperti Kotlin yang menggeneralisasi DSL dengan receiver dan builder. Pendekatan seperti ini bisa sangat berguna bukan hanya untuk template HTML sederhana, tetapi juga untuk berbagai hierarki komponen, config, dan banyak situasi lainnya. Pada akhirnya, arti nyata dari templating dan data binding hanyalah sekumpulan fungsi standar yang memanfaatkan fitur sintaks seperti itu, dan ini mirip dengan Jetpack Compose

    • Fitur yang benar-benar diperlukan sebenarnya hanya beberapa: loop, kondisional pada atribut, kondisional pada node, dan sebagainya. Bahkan dengan struktur seperti ini, pemanfaatannya juga bisa melintasi berbagai bahasa

  • Saya tidak selalu yakin bahwa templating deklaratif memang lebih baik daripada jQuery. Saya sudah memakai React hampir 10 tahun, tetapi makin kompleks SPA saya, makin saya merindukan kontrol DOM yang imperatif. Abstraksi DOM bocor, dan pada akhirnya pola sederhana seperti “last-write-wins” justru terasa lebih jelas. Templating deklaratif katanya menyelesaikan masalah ini, tetapi begitu komponen mulai berbagi mutable state, batasannya muncul terlalu cepat

    • Perasaan ini juga muncul karena developer React sering menganggap memanggil DOM API secara langsung sebagai sesuatu yang berdosa. Padahal menggunakan ref secara aktif, atau langsung mencari dan memanipulasi komponen lewat id, juga tidak masalah. Faktanya, library form yang cepat dan minim rerender memang bekerja seperti itu

    • Saya memang tidak menyukai React, tetapi saya juga merasa tidak ada hambatan untuk keluar dari DOM deklaratif dan memakai innerHTML, ref, dan sebagainya. Banyak hal memang bisa dilakukan dengan kontrol imperatif, tetapi secara praktis tidak banyak yang benar-benar mustahil dilakukan dari sisi deklaratif. attachShadow() atau showModal() pun bisa dengan mudah dibungkus secara deklaratif hanya dengan menambahkan sekitar 10 baris kode

  • Seandainya proposal Records dan Tuples sempat berkembang, JSX mungkin bisa memanfaatkan struktur itu untuk memiliki semantik baru, tetapi kenyataannya proposal tersebut bukan hanya mandek, melainkan benar-benar ditarik (lihat issue). Sebagai gantinya, kini diganti dengan proposal composites

  • Saya rasa diskusi tentang standardisasi fitur tingkat tinggi seperti ini sebaiknya dihentikan. Sebagai gantinya, lebih baik memperluas karakteristik level bawah dan fokus ke arah yang lebih bernilai untuk implementasi library di level atas. Jika sebuah proposal standar tidak punya keunggulan yang jelas dibanding library, maka tidak ada artinya. Saya rasa pembahasan standardisasi seharusnya baru dimulai jika sesuatu sudah terbukti luas dipakai sebagai library setidaknya selama 5 hingga 10 tahun