Saatnya Memperkenalkan API Templating DOM

 (justinfagnani.com)
1 poin oleh GN⁺ 2025-06-28 | 1 komentar | Bagikan ke WhatsApp
  • Platform web telah menjadi runtime aplikasi dinamis, tetapi DOM standar tidak memiliki API templating deklaratif yang menangani data, event, properti, pertahanan XSS, dan pembaruan efisien secara terpadu
  • Framework modern seperti React, Vue, Angular, Lit, Svelte, dan SolidJS menjadikan sistem templating yang menggabungkan markup dan data sebagai inti, dan ini memengaruhi keterbacaan, keamanan, performa, analisis statis, serta server-side rendering
  • E4X, E4H, dan tag literal template html bawaan di masa lalu membantu pembuatan DOM, tetapi tidak menyelesaikan pembaruan DOM; kini tagged template literals dan pengalaman framework menyediakan dasar untuk standardisasi
  • API berbasis JavaScript memiliki cakupan lebih kecil dibanding standardisasi JSX atau template berbasis HTML, dan dengan menjadi target kompilasi untuk transformasi JSX, API ini dapat berlanjut ke template HTML dan custom element deklaratif di kemudian hari
  • Jalur usulan ini terkait dengan mekanisme tingkat bawah seperti DOM Parts, template identity, Signals, dan scheduler DOM, serta dapat menyediakan fondasi bersama bagi developer vanilla, pengguna Web Components, dan implementor framework

Lapisan templating deklaratif yang tidak ada di DOM standar

  • Platform web adalah runtime aplikasi paling sukses dalam sejarah, dan DOM API adalah fondasi yang mengubah penampil dokumen statis menjadi runtime yang dinamis dan ekspresif
  • Bahkan aplikasi kompleks seperti Photoshop tersedia sebagai aplikasi web, dan DOM merupakan API yang kuat sampai-sampai seluruh UI dapat dibuat dengan Web Components
  • Namun, DOM API standar saat ini tidak memiliki cara nyaman untuk menangani pekerjaan berikut sekaligus
    • Membuat potongan node DOM dari data
    • Menambahkan event listener
    • Mengatur properti elemen
    • Memastikan keamanan terhadap serangan XSS
    • Memperbarui potongan DOM tersebut secara efisien dengan data baru

Nilai template yang sudah dibuktikan oleh framework

  • Framework web modern dan library rendering menggunakan template yang menggabungkan markup dan data secara deklaratif sebagai fitur inti
    • Termasuk React, Vue, Angular, Preact, Lit, Svelte, SolidJS, Stencil, Quik, Ember, FAST, Polymer, Marko, dan lainnya
  • Template deklaratif lebih mudah ditulis dan dibaca dibanding DOM API imperatif
    • Interpolasi, event listener, dan pengaturan properti berada dekat dengan template, sehingga lokalitas perilaku lebih mudah dipertahankan
  • Sistem templating dapat melakukan escape otomatis pada nilai interpolasi, sehingga menguntungkan untuk pertahanan XSS
  • Sistem templating yang baik dapat lebih cepat daripada sebagian besar kode manual karena hanya memperbarui DOM yang perlu diubah
  • Banyak sistem templating mendukung analisis statis seperti pemeriksaan tipe dan autocomplete
  • Definisi template deklaratif dapat diinterpretasikan di luar lingkungan browser penuh, sehingga server-side rendering yang efisien menjadi memungkinkan

Biaya yang timbul karena ketiadaan template

  • Platform masih belum secara langsung memenuhi kebutuhan inti dari hampir semua aplikasi web
    • Seperti API internasionalisasi, Temporal, Scheduler, dan Sanitizer, template juga layak diperlakukan sebagai fitur platform standar
  • Pengguna terdampak oleh waktu unduh aplikasi, overhead rendering, dan aplikasi dengan keamanan lemah
    • Kode library templating dalam kasus terbaik bisa beberapa kB, dan dalam kasus terburuk bisa lebih dari 100 kB
    • Bahkan beberapa kB pun dapat menjadi porsi besar dalam anggaran rendering interaktif awal
  • Developer harus bergantung pada library, npm, dan CDN bahkan untuk pekerjaan dasar
    • Kegunaan file statis sederhana dan DevTools berkurang
    • Tidak ada pengetahuan templating dasar yang portabel antar-stack
    • API pembuatan DOM native seperti innerHTML pada dasarnya tidak aman
  • Framework dan library templating harus melakukan kompromi sulit antara kemudahan penulisan, kecepatan rendering, kecepatan pembaruan, keamanan, dan ukuran kode
  • Platform web bersaing dengan platform native seperti Flutter, SwiftUI, dan Jetpack Compose
    • Platform-platform ini menyertakan sistem mirip template secara bawaan, menggunakan instalasi aplikasi dan bahasa terkompilasi, serta kurang sensitif terhadap ukuran bundle beberapa kB

Mengapa bisa dicoba lagi sekarang

  • Di masa lalu juga pernah ada usulan platform yang mendekati template
    • E4X benar-benar pernah disertakan di Firefox dan Flash
    • E4H adalah ide yang disederhanakan oleh Ian Hixie
    • Sekitar 2012 juga ada prototipe tag literal template html bawaan
  • Upaya-upaya masa lalu membantu pembuatan DOM, tetapi sulit menjadi solusi yang memadai karena tidak menyelesaikan pembaruan
  • Saat ini, framework telah menciptakan cukup banyak kasus penggunaan, dan solusi templating di userland juga semakin mirip dari waktu ke waktu
  • Ada kebutuhan akan manipulasi DOM yang nyaman dan API reaktivitas dari developer yang tidak memakai framework serta komunitas Web Components
  • Usulan primitif pembaruan DOM tingkat rendah seperti DOM Parts sedang berjalan
    • API templating deklaratif tingkat lebih tinggi dapat mengurangi beban implementasi framework, sekaligus memvalidasi dan melengkapi usulan API tingkat rendah

Kesamaan umum dalam sintaks dan semantik

  • Sebagian besar sistem templating client-side populer berbagi struktur yang menggabungkan markup dan binding
    • Pemisah ekspresi, control flow, dan penanda tipe binding sedikit berbeda, tetapi kesamaannya lebih besar
    • Ada kemiripan juga antara Vue, Angular, dan Svelte yang berbasis HTML dengan React, Lit, dan Solid yang berbasis JavaScript
  • Dalam API berbasis JavaScript, template biasanya berupa ekspresi, komposisi dilakukan dengan menumpuk atau mereferensikan ekspresi template, dan control flow ditangani oleh JavaScript
  • Banyak sistem berbasis API JavaScript mengembalikan deskripsi DOM dari ekspresi template, lalu menerapkannya melalui pemanggilan fungsi render terpisah
    • Sebagian besar memperbarui DOM dengan pemanggilan render yang sama
    • Sebagian lainnya menghindari pendekatan ini dengan reaktivitas yang halus
  • E4X dan E4H menambahkan sintaks baru untuk memasukkan markup ke JavaScript seperti JSX, tetapi mengembalikan potongan DOM itu sendiri, bukan deskripsi DOM
    • Ini baik untuk pembuatan DOM awal, tetapi pembaruan tetap bersifat imperatif

API yang bisa diekspresikan dengan JavaScript hari ini

  • JavaScript sudah memiliki tagged template literals untuk DSL tertanam seperti HTML
  • Template dapat diekspresikan dalam DOM API tanpa menambahkan sintaks JavaScript baru
  • Library populer menunjukkan bahwa pendekatan ini bekerja dengan baik
  • Fakta bahwa usulan dapat berjalan tanpa sintaks baru penting bagi realitas standardisasi

Hubungan JSX dan API template native

  • Tagged template literals adalah fitur kuat dari ES2015, tetapi dalam sistem komponen userland, overhead sintaksnya lebih besar daripada JSX
  • JSX populer, tetapi hanya memiliki sintaks dan tidak memiliki semantik runtime
    • Untuk menstandardisasikannya, semantik harus didefinisikan, bukan sekadar menambahkan sintaks baru
    • Pendekatan yang memperlakukannya sebagai pemanggilan createElement() yang didefinisikan di sekitar harus dikesampingkan
    • Pendekatan membuat pohon objek dapat mencampur bagian statis dan dinamis, sehingga menghambat pola pembaruan yang lebih efisien
  • Jika usulan Records and Tuples berjalan, JSX mungkin bisa membuat Records yang memiliki box, tetapi usulan tersebut mandek terutama pada bagian record identity dan box
  • Untuk memverifikasi apakah sintaks dan semantik seperti JSX cocok untuk template DOM yang lengkap, diperlukan sistem template target
    • Template React tidak memiliki cara untuk secara eksplisit melakukan binding ke properti dan event elemen DOM, atau menerapkan directive pada elemen
  • JSX nonstandar saat ini adalah sintaks murni tanpa semantik runtime, sehingga compiler yang mengubah JSX menjadi tagged template literal dapat dibuat
    • Contoh seperti JSX-to-Lit sudah ada
    • API template native dapat menjadi target kompilasi yang memungkinkan developer memilih sintaks yang mereka inginkan

Mengapa melihat API JavaScript lebih dulu daripada template berbasis HTML

  • Banyak developer web menginginkan sistem template berbasis HTML yang berfitur lengkap
    • Ada permintaan dari komunitas pengguna Web Components, pengguna framework, dan developer vanilla
    • Ada juga developer yang berharap elemen <template>, declarative shadow DOM, dan Web Components menyediakan fungsi semacam ini
  • Template berbasis HTML merupakan pekerjaan yang jauh lebih besar daripada API berbasis JavaScript
    • Sintaks binding
    • Bahasa ekspresi
    • Sintaks control flow
    • Mekanisme pembaruan template
  • Juga belum ada cara native untuk memuat definisi template berbasis HTML
    • HTML Imports dari Web Components v0 telah hilang, dan HTML Modules belum ada
    • Jika template HTML harus dimasukkan ke dalam modul JavaScript, penilaiannya adalah lebih baik memakai ekspresi JavaScript dalam lexical scope yang sama dengan data
  • Polymer 3 memindahkan template HTML Polymer 2 ke JavaScript, dan ini berlanjut langsung menjadi Lit
    • Membiarkan JavaScript menangani hal-hal seperti script menghasilkan kode yang lebih sedikit dan pengalaman yang lebih baik
  • API JavaScript dapat menjadi subset sekaligus batu loncatan untuk API berbasis HTML
    • Setelah API JavaScript masuk dan tervalidasi, API HTML tinggal mendefinisikan binding, ekspresi, control flow, dan sistem modul

Pilihan model reaktivitas

  • Usulan awal template DOM tidak mencakup pembaruan, tetapi sistem userland telah cukup mengeksplorasi model reaktivitas dan pendekatan implementasi
  • Pendekatan reaktivitas utama dapat dikelompokkan menjadi tiga
    • VDOM dan diffing dari React
    • template identity dari Lit
    • Signals dan reaktivitas halus yang digunakan di Solid, Svelte, Vue, Angular, dan lainnya
  • Diffing mudah dipahami dan bekerja untuk data apa pun, tetapi lebih lambat daripada pendekatan lain
    • Perbedaan algoritme diffing dapat teramati
    • Sulit untuk menstandardisasi satu algoritme diffing dan membuat engineer platform menerima overhead-nya
  • Template identity adalah pendekatan memperbarui DOM jika DOM saat ini dirender dengan template tersebut, atau menggantinya jika tidak
    • Cepat, dan dalam banyak kasus penggunaan menghasilkan hasil yang sangat mirip dengan diffing
    • Cocok dengan tagged template literals, transformasi JSX, dan template berbasis HTML
    • Semantiknya sederhana sehingga lebih mudah dispesifikasikan
  • Signals adalah model yang layak dimasukkan dalam API DOM reaktif baru dan API templating
    • Ada usulan JavaScript Signals, tetapi belum menjadi fitur native platform dan adopsinya tidak dijamin
    • Sistem berbasis Signals bekerja paling baik ketika semua data dibungkus sebagai signal
    • Karena ada banyak data non-signal dan API platform yang tidak membuat signal, re-rendering adalah cara mudah untuk mencerminkan perubahan semacam itu
  • Template identity dan Signals dapat hidup berdampingan
    • Template yang hanya menerima signal pada binding dapat diperbarui hanya dengan signal tanpa re-rendering
    • Template yang dapat merujuk data non-signal memerlukan re-rendering
    • Biasanya re-rendering dilakukan otomatis oleh lapisan komponen atau framework, seperti properti komponen reaktif

Diskusi standardisasi dan tugas yang tersisa

  • Diskusi API templating JavaScript deklaratif native dimulai di WICG webcomponents#1069
  • API ini dapat menjadi langkah berikutnya yang logis bagi API pembuatan DOM
    • Menjadi primitif pembuatan DOM yang mudah ditulis dan aman bagi developer web vanilla
    • Langsung berguna bagi library Web Components yang sudah ada seperti Lit, FAST, dan HyperElement
    • Berguna bagi pengguna API Web Components mentah, dan menjadi batu loncatan menuju API definisi komponen reaktif yang lebih lengkap
    • Framework baru dapat dibuat di atas API ini
    • Framework yang sudah ada dapat menggunakannya sebagai target kompilasi, backend runtime, atau target dukungan langsung
    • Berguna baik untuk teknik re-rendering maupun Signals
    • Menjadi batu loncatan menuju template HTML deklaratif dan custom element deklaratif
    • Permukaan API yang perlu disepakati dan dispesifikasikan relatif kecil
    • Membantu mendefinisikan semantik template
  • Pekerjaan ini terkait dengan penyelesaian usulan DOM Parts
    • Juga berkontribusi untuk mendefinisikan DOM Parts dan membuktikan kegunaannya
  • Permukaan API dan sintaksnya tidak besar, tetapi ruang perilaku dan API DOM Parts di bawahnya besar
  • Reaktivitas halus juga memerlukan suatu bentuk scheduler DOM
  • Ada banyak hal yang harus diputuskan, disepakati, dispesifikasikan, dan diuji, sehingga kolaborasi diperlukan
  • Developer yang tertarik dapat meninggalkan komentar di webcomponents#1069 atau menghubungi melalui Bluesky

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-28
Pendapat di Hacker News

  • Pernyataan “kita tahu seperti apa sintaks yang baik untuk template” sampai membuat saya tertawa. Menurut saya kita sama sekali belum tahu. Template yang baik hampir pasti lebih dekat ke alat visual daripada sintaks simbolik; itulah sebabnya alat seperti Dreamweaver dulu berhasil, dan desainer belajar dengan alat seperti Photoshop
    Selain itu, sayang sekali ini terlihat seperti upaya membuat ulang XSLT. Pada akhirnya pasti ada orang yang ingin membuat template untuk potongan-potongan yang tidak well-formed, tetapi ketika digabung menjadi sesuatu yang well-formed. Hal yang sama berlaku untuk entitas yang saling terhubung di dalam halaman tetapi tidak berada dalam tree yang sama. Contoh mudahnya adalah label dan for dalam markup biasa
    Kalau bisa, saya berharap upaya memaksakan semua template agar sesuai dengan mesin Rube Goldberg bernama layout dokumen standar dalam markup berkurang. Orang-orang mengambil jalan yang luar biasa rumit untuk meniru sesuatu yang sebenarnya bisa bekerja cukup baik jika absolute positioning digunakan dengan hati-hati. Untuk menyesuaikannya mungkin memang perlu perhitungan, tetapi saya tidak mengerti mengapa mesin harus dipaksa terus-menerus mengulang perhitungan itu untuk data yang sama

    • Saya tidak pernah menyukai XML, tetapi menurut saya XSLT dulu, dan masih sekarang, adalah killer feature yang bisa menyelamatkan ekosistem itu. Dukungan di browser juga masih luas
      Sayang sekali XML sempat populer di tempat-tempat yang kurang tepat seperti konfigurasi dan komunikasi antarproses, tetapi justru meredup di tempat ia bisa bersinar sebagai bahasa markup dengan kemampuan transformasi hebat bernama XSLT
      Menurut saya titik runtuh XSLT adalah bahwa ia benar-benar sebuah DSL, tepatnya DSL yang deklaratif, murni, dan fungsional. Orang-orang sering memuji DSL setinggi langit, tetapi dalam praktiknya DSL sering kali hanya menjadi permainan sintaks sederhana yang gagal mengabstraksikan semantik prosedural dari bahasa host yang populer. Ketika bertemu DSL yang dirancang baik dan membuat hal sulit menjadi sepele, orang-orang tidak mau mempelajarinya
    • Saya tidak tahu bagaimana bisa sampai pada kesimpulan itu. Yang dibicarakan tampaknya bukan cara membuat template, melainkan keluhan terhadap HTML+CSS secara keseluruhan
      Saya juga heran mengapa absolute positioning dibahas. Saya sering melihat pembicaraan seperti ini di HN; tentu saja absolute positioning punya tempatnya dan dalam banyak kasus memang diperlukan
      Namun jika dipakai untuk layout halaman atau aplikasi, berdasarkan pengalaman, kebanyakan akan menjadi mimpi buruk yang runtuh hanya karena konten atau ukuran layar berubah sedikit. Bahkan layout koran cetak pun tidak bisa dilakukan seperti itu karena tipografinya saling terkait
      Ketika saya banyak menangani CSS, jika saya mengambil alih pekerjaan dari seseorang yang sudah membuat layout “hampir selesai” dengan absolute positioning, memperbaikinya memakan waktu sangat lama, dan selalu lebih cepat membuat ulang dengan cara seperti flex atau normal flow. Sebab, jika absolute positioning dipakai sebagai alat layout utama, masalahnya praktis berada pada tingkat yang tidak bisa diperbaiki
      Mungkin ada teknik yang masuk akal dengan calc() dan satuan viewport, tetapi berdasarkan pengalaman, kecuali kontennya benar-benar statis dan ukuran viewport-nya juga statis, absolute positioning tidak cocok untuk layout
    • Di web ada tuntutan bahwa dokumen harus terlihat bagus pada ukuran perangkat, rasio, orientasi, dan kemampuan apa pun. Aplikasi biasa, misalnya aplikasi Windows, tidak memiliki tuntutan seperti ini, dan aplikasi mobile punya beberapa ukuran yang terstandardisasi. Hanya web yang memiliki keduanya
    • Menurut saya React dan Svelte hanya memiliki kemiripan di permukaan. Keduanya memakai sintaks yang sangat berbasis HTML, tetapi cara kerjanya sangat berbeda
      React pada dasarnya adalah satu-satunya framework besar yang bekerja dengan cara fungsi JavaScript biasa mengembalikan representasi tertunda dari markup dalam bentuk JSX. React tidak memiliki konsep loop atau conditional rendering pada level template; itu ditangani dengan JavaScript biasa
    • Menertawakan orang yang mendorong kemajuan platform web bukanlah sikap yang terlalu baik. Kemajuan itu menguntungkan semua orang
      Dan sekarang menurut saya kita memang tahu seperti apa sintaks template yang baik. Pada dasarnya itu adalah JSX. Saya bisa mengatakan itu meskipun saya sendiri tidak terlalu menyukai React. Sulit dibantah bahwa JSX telah menyapu seluruh web, diadaptasi untuk berbagai framework, dan sistem template JavaScript telah berkonvergensi pada ciri-ciri umum: memperlakukan template sebagai ekspresi, menyusunnya lewat nesting, dan menangani control flow dengan JavaScript itu sendiri alih-alih sintaks template tertentu

  • Pelajaran dasar yang berulang kali dipelajari adalah bahwa API/ABI bukanlah keadaan final. Kebutuhan aplikasi tidak akan terpenuhi selamanya oleh satu API yang stabil, dan semua masalah masa depan juga tidak bisa dilempar menjadi masalah level aplikasi.
    Usulan ini menunjukkan dengan baik proses ketika masalah umum platform diselesaikan di lapisan yang lebih tinggi seperti React, lalu akhirnya turun ke bawah ketika diakui sebagai masalah. Polyfill juga contoh yang sama.
    Jika usulan seperti ini berhasil, ia sempat mendapat perhatian, tetapi sebagian besar masa pakainya yang berguna berubah menjadi sesuatu yang usang yang ingin diakali orang. Begitulah nasib DOM API, versi ECMA, browser lama, dan semua teknologi berguna yang tidak bisa disentuh karena sudah menjadi bagian dari sistem.
    Tidak bisakah kita memikirkan entropi, perluasan, dan kompatibilitas mundur sebagai use case utama?

    • Setiap fitur dalam standar web adalah kode tambahan yang harus dipelihara dengan cermat, dan juga kode tambahan yang harus diimplementasikan oleh siapa pun yang ingin membuat browser yang patuh standar. Saya berharap proyek seperti https://servo.org/ mendapat kesempatan untuk mengejar seiring waktu, bukan hanya terus mengejar cakupan yang terus bertambah.
      Saya ingin platform web memiliki semua kemampuan yang mungkin dimiliki platform native. Tentu dengan tetap menjaga batasan privasi dan sandboxing. Dan saya juga ingin pengalaman pengembangan para web developer menjadi hebat.
      Namun ini harus diseimbangkan dengan konsekuensi meningkatnya kompleksitas. Dalam kasus ini, saya tidak yakin template native benar-benar meningkatkan pengalaman pengembangan. Manfaatnya tidak tampak melebihi biayanya.
    • getElementById rasanya sudah stabil sekitar 25 tahun. Pernyataan “tidak ada yang namanya API stabil” adalah ucapan orang-orang yang tidak mampu atau tidak mau membuat antarmuka yang tahan lama. Itu bukan hukum alam semesta, lebih mirip kepasrahan pribadi. Ada sangat banyak contoh tandingan.
      Kebutuhan aplikasi itu tak terbatas, seperti kebutuhan lainnya. Kebutuhan itu dipenuhi bukan dengan merusak API yang sudah berfungsi, melainkan dengan menambahkan API baru.
    • Di web, API/ABI memang merupakan keadaan final. Begitu dipublikasikan ke web, seseorang akan bergantung pada bentuk persisnya untuk selamanya.
      Karena itu ada API yang sampai sekarang masih terseret kasus seperti smooshgate akibat keputusan 20 tahun lalu: https://developer.chrome.com/blog/smooshgate
    • Dalam proses itu, kapabilitas dasar naik satu tingkat lagi. Hanya karena kebutuhan di userland akan selalu menemukan celah, use case, dan blind spot baru, bukan berarti pembaruan bertahap menjadi tidak bernilai.
    • Karena itulah ada versi, menjaga kompatibilitas mundur dengan versi lama, dan tidak mengubah antarmuka yang “usang”, bukan?

  • Web benar-benar membutuhkan template native, reaktivitas, dan data binding. Sulit membayangkan berapa banyak CPU dan bandwidth yang terbuang karena miliaran pengguna harus mengunduh, mem-parse, dan menjalankan sesuatu seperti React.

    • Sekarang ada LLM dan kripto, jadi pemborosan seperti itu tampak sangat kecil.
    • Sebagian dari itu sedang mengalami kemajuan lewat proposal Signals TC39.
    • Data binding dua arah dan semacam kloningan JSX sebenarnya sudah cukup bagi kebanyakan orang.
    • React sulit disebut template, bukan?

  • Bagian Signals mengatakan banyak hal, dan menunjukkan dengan baik bahwa idenya bagus tetapi secara praktis sulit.
    Saya paham mengapa penulis menyukai Signals. Setiap proyek yang cukup besar punya pohon komputasi DAG yang setengah jadi, dan masuk akal jika bahasa menstandarkan salah satunya.
    Namun abstraksi seperti ini memiliki biaya kognitif dan biaya implementasi yang besar.
    Seperti kebanyakan rekayasa, masalahnya adalah kompromi. Model React memperbarui state global dan merender ulang semuanya, jadi lambat tetapi mudah dipahami. Model Signals cepat, tetapi membutuhkan terlalu banyak usaha.
    Kebanyakan aplikasi tidak perlu secepat kilat, dan orang akan memilih React yang lebih sederhana.
    Namun bukankah Signals tidak terlalu terkait dengan template? Kalau begitu mengapa harus memilih? Bukankah template dan Signals bisa dimiliki secara terpisah?
    Saat memikirkan template, kita jadi perlu cara untuk memberi tahu DOM di mana menyisipkan node template, dan bagaimana memperbaruinya ketika berubah. Di titik inilah proposal-proposal seperti ini gagal.
    API di sini harus memilih salah satu pihak. Secara teknis mungkin bisa mengizinkan keduanya, tetapi itu mengerikan. Para developer tidak akan pernah sepakat mana yang seharusnya dipakai.
    Masalah besar UI selalu bukan bagaimana mendefinisikannya, melainkan bagaimana memperbaruinya. Microsoft mencoba mendefinisikan banyak model seperti MVC, MVP, MVVM, dan gagal; semuanya menyakitkan. Lalu imgui berkata, “bagaimana jika UI sama sekali tidak punya state?”, dan itu cukup bagus, tetapi membebani CPU.
    Mungkin salah satu alasan terbesar keberhasilan aplikasi web adalah karena DOM tidak memaksakan cara mengikat data ke view. Karena itu mungkin kita sulit lepas dari neraka framework.

    • Sekarang ada beberapa framework yang melakukan diffing granular dengan baik tanpa bergantung pada Signals, proxy, atau primitif reaktif lain. Pada dasarnya model React yang mengalir dari atas ke bawah, tetapi jauh lebih cepat, dan tanpa konsep aneh seperti hooks atau array dependency manual yang boros.
      Yang saya sukai secara pribadi adalah ivi-js: https://github.com/localvoid/ivi
      Ia hanya 8% lebih lambat daripada vanilla JavaScript tercepat, paling jelek, imperatif, dan tak mungkin dipelihara yang pada akhirnya bisa dicapai jika tujuannya semata-mata memenangkan benchmark.
      https://krausest.github.io/js-framework-benchmark/2025/table...
    • Microsoft memang menggunakan model-model itu pada berbagai periode, tetapi yang mereka definisikan sendiri hanya MVVM. MVC berasal dari Xerox PARC, MVP dari Taligent.
    • Dari sudut pandang developer pun, saya bersedia memilih opsi yang lebih mudah bagi hardware, bandwidth, dan bumi, meskipun sedikit lebih berat bagi pikiran developer.
      Dibanding mengatakan kebanyakan aplikasi tidak perlu secepat kilat, saya lebih ingin orang mengakui bahwa aplikasi harus ringan.
      Saya setuju orang memilih React karena lebih sederhana, tetapi justru karena alasan itulah saya tidak menyukai React.

  • Alih-alih mengadopsi JSX, saya berharap arahnya lebih dekat dengan cara Kotlin menyediakan sintaks yang digeneralisasi untuk DSL lewat receiver dan builder, dan sintaks itu juga cocok untuk mengekspresikan hierarki komponen
    Ini akan berguna secara luas bukan hanya untuk template HTML, tetapi juga untuk mengekspresikan konfigurasi dan berbagai jenis struktur
    Semantik aktual dari template dan data binding cukup diletakkan sebagai sekumpulan fungsi standar yang memakai fitur sintaks semacam itu, seperti yang terlihat di Jetpack Compose

    • Tidak perlu banyak. Cukup perulangan, kondisional untuk atribut, dan kondisional untuk node. Sebenarnya, sejauh itu bahkan bisa menjadi fitur umum lintas bahasa

  • Penting juga bahwa tulisan ini ditulis oleh salah satu orang yang paling berpengalaman di bidang ini. Ia adalah salah satu penulis utama Lit / Polymer, bekerja pada Web Components di Google, dan berkontribusi pada spesifikasi DOM inti yang menjadi bagian dari platform web

    • Justru menurut saya ia adalah salah satu orang yang, dengan mendorong maju spesifikasi setengah matang secara nekat, menciptakan jauh lebih banyak masalah daripada yang diselesaikan. Ia mendorong “solusi” yang menuntut lebih dari 20 spesifikasi web baru hanya untuk nyaris meniru hal-hal yang sudah dilakukan userland, dan mengabaikan atau melakukan gaslighting terhadap orang-orang yang tidak 100% setuju
      Safari sudah berargumen sejak 15 tahun lalu bahwa seharusnya ada cara deklaratif untuk ini

  • Saya penasaran apakah ada orang lain yang merasa template deklaratif sebenarnya lebih buruk daripada jQuery. Saya sudah memakai React hampir 10 tahun, tetapi semakin kompleks sebuah SPA, semakin saya ingin mengendalikan DOM secara langsung dan imperatif
    Alasannya, DOM adalah abstraksi yang bocor, dan pada level tertentu terasa lebih baik jika penulisan terakhir yang menang
    Saya tahu template deklaratif mencoba menangani itu, tetapi begitu kita mulai berbagi state yang dapat berubah antar-komponen, pendekatan ini runtuh dengan sangat cepat

    • Orang-orang React cenderung menganggap pemanggilan DOM API secara langsung sebagai dosa besar. Kadang-kadang tidak apa-apa mengambil ref, dan berani saya katakan, mencari komponen dengan id lalu menanganinya langsung. Nyatanya pustaka-pustaka yang “cepat” dan minim re-render, misalnya pustaka form, melakukan hal seperti itu
    • Saya tidak menyukai React, tetapi saya tidak setuju dengan perasaan ini. Pertama, kita sudah bisa keluar dari DOM deklaratif dan melakukan apa saja dengan innerHTML dan ref
      Kedua, saya tidak tahu pekerjaan apa yang bisa dilakukan dengan lebih tidak merepotkan jika DOM dikendalikan secara imperatif dibanding deklaratif. Yang terpikir hanya metode tertentu seperti attachShadow(), showModal(), dan itu pun bisa dibuat deklaratif dengan membungkusnya dalam komponen 10 baris
    • Sepenuhnya setuju. Saya belum pernah melihat satu pun contoh yang meyakinkan bahwa sesuatu seperti React sedikit saja lebih baik daripada memakai HTML terpisah dan jQuery

  • Setahu saya Ryan Carniato dan Solid JS masih mengeksplorasi apa yang mungkin dilakukan dengan Signals. Saya tidak menganggap eksplorasi userland di area ini sudah sepenuhnya selesai, dan inovasi tambahan masih mungkin terjadi

    • Di luar gelembung pengembangan web pun ada banyak riset menarik di ranah masalah komputasi inkremental, dan komputasi yang menyesuaikan diri, alias Signals, bahkan bukan sumbu yang terlalu menarik

  • Saya suka arahnya, tetapi sebelum itu menurut saya beberapa API level lebih rendah perlu masuk ke browser lebih dulu
    Hampir mustahil semua orang akan sepakat pada satu sistem template standar. Sebagai gantinya, yang bisa dilakukan browser adalah menyediakan API level rendah untuk menerapkan diff ke DOM secara native dan berkinerja baik
    Akan sangat bagus jika browser memiliki hal seperti ini secara native
    element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })
    Dengan cara ini, diff dapat diterapkan dengan cara yang minim gangguan, seperti mempertahankan fokus elemen, nilai input, status pemutar audio/video, dan mengubah atribut. Pustaka JavaScript seperti Idiomorph melakukan hal semacam ini, tetapi solusi native kemungkinan bisa jauh lebih cepat

    • Di tulisan itu ada tautan ke proposal DOM part yang bisa menjadi API level rendah yang berguna. Ini mungkin tidak cocok untuk framework berbasis VDOM, tetapi pada framework lain dapat menyederhanakan cara kerja dan meningkatkan ruang untuk optimasi
      Ini juga akan berguna untuk proyek tanpa framework, dan akan semakin berguna khususnya jika proposal Signals ikut diadopsi

  • Proposal Records and Tuples bukan sekadar mandek, melainkan sudah ditarik. https://github.com/tc39/proposal-record-tuple/issues/394
    Posisinya digantikan oleh https://github.com/tc39/proposal-composites