Web Component HTML

 (blog.jim-nielsen.com)
2 poin oleh GN⁺ 2023-11-14 | 1 komentar | Bagikan ke WhatsApp
  • Web component terlihat seperti versi browser dari komponen React, tetapi sebenarnya lebih dekat ke model yang menempatkan HTML yang sudah ada sebagai pusat lalu menambahkan fungsionalitas di atasnya
  • Perbedaan utamanya ada pada rendering sebelum JavaScript dijalankan: alih-alih mengirim data ke elemen kustom yang kosong, lebih alami untuk membungkus HTML yang bermakna dengan elemen kustom
  • HTML web component memperluas markup yang sudah ada, sedangkan elemen kosong yang sepenuhnya menyerahkan isi dan fungsinya kepada JavaScript lebih dekat ke JavaScript web component
  • Jika cara membuat komponen ala React terbiasa dengan penggantian (replacement), web component menuntut cara berpikir augmentasi (augmentation), yaitu menambahkan fungsionalitas sambil mempertahankan konten
  • Di platform web, seperti pada HTML5, fetch, dan arus terkait TypeScript, ide-ide bagus cenderung bertahan lama dengan cara memperkuat teknologi yang sudah ada alih-alih menyingkirkannya

Web component dan komponen React punya karakter yang berbeda

  • Nama “Web components” bisa terdengar seperti padanan komponen React di platform web
    • JSX di React memakai bentuk <MyComponent>, dan web component bisa memakai bentuk <my-component>
    • Namun, jika membuat web component seperti membuat komponen React, kita bisa mudah frustrasi
  • Kedua teknologi ini berbeda dalam fitur yang diprioritaskan dalam desain dan cara pemakaiannya
    • Jika salah satunya dipakai seperti yang lain, itu akan berbenturan dengan arah alami masing-masing teknologi

HTML web component lebih cocok untuk augmentasi daripada penggantian

  • Komponen React pada umumnya bisa berbentuk komponen kosong yang menerima data lewat properti, lalu JavaScript merender seluruh isinya
<UserAvatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
/>
  • Web component juga, dari tampilan luarnya saja, bisa ditulis dengan cara yang sama
<user-avatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
></user-avatar>
  • Namun, kekuatan khas web component adalah kemampuannya untuk dirender sebelum JavaScript
    • Komponen React tidak bisa bekerja dengan cara ini
  • Karena itu, dibanding “shell component” yang kosong, lebih cocok menyusun konten inti dengan HTML lalu membungkusnya dengan elemen kustom untuk menambahkan fungsi
<user-avatar>
  <img src="https://example.com/path/to/img.jpg"; alt="..." />
</user-avatar>
  • Pembedaan Jeremy dalam “HTML web components” berfokus pada apakah elemen kustom memperluas markup yang sudah ada
    • Jika elemen kustom kosong, itu bukan HTML web component
    • Jika ia membungkus dan memperluas markup yang sudah ada, itu lebih dekat ke HTML web component
  • “JavaScript web component” adalah bentuk di mana isi dan fungsi elemen kosong sepenuhnya bergantung pada JavaScript
<user-avatar
  src="https://example.com/path/to/img.jpg";
  alt="..."
></user-avatar>
  • Dalam bentuk ini, tanpa JavaScript, elemen tersebut tidak punya makna bagi pengguna akhir
  • Sebaliknya, HTML web component tetap menyisakan makna dan konten bahkan tanpa JavaScript, dan jika JavaScript ada, fungsionalitas ditambahkan di atasnya
<user-avatar>
  <img src="https://example.com/path/to/img.jpg"; alt="..." />
</user-avatar>

Di web, pendekatan augmentasi bertahan lebih lama

  • Alasan pendekatan augmentatif cocok di web adalah karena karakter web mendorong peningkatan progresif yang tangguh, dan cocok untuk berulang kali mengubah sesuatu sebesar web
  • Ide-ide bagus dari framework dan library di sekitar web, meskipun akhirnya diserap ke dalam platform, sering masuk dengan cara memperkuat teknologi yang sudah ada alih-alih menggantikannya sepenuhnya
    • XHTML mencoba menggantikan HTML4, tetapi HTML5 mencoba memperkuat HTML4, dan HTML5 yang menang
    • Library networking mencoba menggantikan XMLHttpRequest, dan ide-ide bagusnya pada akhirnya dipindahkan ke standar fetch
    • fetch kini juga ada di berbagai lingkungan di luar browser
    • Ide-ide bagus dari Sass dan jQuery juga dipindahkan ke browser
    • Ide-ide bagus dari TypeScript juga masuk ke browser dengan cara memperkuat teknologi yang sudah ada, bukan menggantikannya
  • Web component juga bisa dilihat sebagai aliran di mana model komponen React berpindah ke browser, tetapi ia lebih dekat ke sisi memperkuat daripada menggantikan cara kerja web yang sudah ada
  • Jika menginginkan pendekatan teknologi yang bertahan lama, memilih augmentasi dan peningkatan lebih selaras dengan arah web daripada penggantian

Bacaan terkait

1 komentar

 
GN⁺ 2023-11-14
Opini Hacker News

  • Saya berharap tulisan ini menjelaskan apa sebenarnya yang dilakukan atau disediakan oleh user-avatar, tetapi sampai akhir tidak muncul
    Kalau isinya hanya style, saya tidak paham kenapa tidak cukup memakai class CSS saja, dan rasanya jauh lebih natural jika user-avatar menerima atribut src daripada setiap kali harus memasukkan tag img di dalamnya
    Vue/React/Angular menurut saya bukan berusaha “menggantikan” HTML, melainkan lebih seperti dibangun di atas HTML/CSS/JS; kalau pendekatannya merender semuanya dengan canvas, argumen itu mungkin akan terasa lebih meyakinkan
    Saat Web Components pertama kali diumumkan saya sempat berharap banyak, tetapi fitur bawaan-nya terlalu minim, dan kesannya tidak banyak membantu secara nyata untuk membuat aplikasi web seperti framework
    Alternatif untuk framework besar, khususnya yang seperti htmlx, terlihat seperti keluarga jQuery dengan sedikit syntax sugar, sehingga terasa seperti kemunduran besar untuk membangun aplikasi web

    • Saya setuju bahwa “alternatif framework besar terasa seperti syntax sugar untuk jQuery”, tetapi masih agak tidak jelas kenapa itu sepenuhnya pilihan yang salah untuk membangun aplikasi web
      Kalau yang dimaksud ‘aplikasi web’ adalah sesuatu seperti Google Sheets, saya setuju, tetapi arus anti-React ini tampaknya lebih mengkritik kebiasaan memasang framework seolah-olah itu default lalu membangun dari awal, dibanding kasus semacam itu
      Dalam praktiknya, ada banyak situs web yang hanya butuh “interaksi tipis di atasnya”
    • Menurut saya tulisan Eric Meyer jauh lebih baik menunjukkan maksudnya: https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the...
      Manfaat utamanya adalah progressive enhancement: karena tag img punya perilaku default, kita bisa mengandalkan rendering dasar lalu hanya “memperkuat” bagian yang perlu dengan web component
    • Karena kurang contoh konkret, tulisan ini terasa agak seperti ide yang muncul saat mandi
    • Contoh yang lebih konkret menunjukkan inti tulisan itu ada di sini: https://www.zachleat.com/web/details-utils
      Komponen details-utils memperkuat perilaku komponen HTML bawaan detail
      Kalau karena alasan apa pun JavaScript dimatikan, komponen detail tetap bekerja seperti semula; ketika JavaScript aktif atau selesai diunduh, ia mendapat perilaku yang ditingkatkan seperti menutup saat klik di luar
      Dalam pendekatan ini, bagian yang bisa digunakan ulang adalah penguatan perilaku semacam itu
      Setelah melihat web component dari pembuat 11ty ini, saya memahami inti tulisannya, dan bagian yang dulu saya rasakan saat pertama melihat Web Components—“pada akhirnya tetap butuh JavaScript, dan kalau tidak ada JavaScript ya tidak jalan”—juga muncul sebagai poin yang sama dalam tulisan Rich Harris: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
    • Entah apakah Anda pernah memakai htmx, tetapi kritik itu tampaknya meleset karena htmx menangani masalah yang berbeda dari pengalaman pengguna JavaScript sisi klien yang dulu dipecahkan jQuery
      htmx terutama memperluas paradigma HTML yang dirender server dari refresh seluruh halaman menjadi pembaruan sebagian halaman, sambil menghindari penulisan JavaScript

  • Untuk melihat lebih jauh ide “HTML Web Components”, tulisan-tulisan ini juga layak dibaca
    https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - “So there you have it: a few thousand words on my journey through coming to understand and work with these fully-Light-DOM web components, otherwise known as custom elements. Now all they need is a catchy name, so we can draw more people to the Light Side of the Web.”
    https://adactio.com/journal/20618 mengusulkan nama yang terdengar masuk akal

    • Saya tidak terlalu paham intinya
      Karena repot dipakai, pada akhirnya kita butuh framework ringan di atas framework bawaan seperti Lit, padahal Lit lebih besar daripada Preact
      Selain itu, ia tidak menyelesaikan masalah nyata seperti manajemen state dan routing, jadi kemungkinan besar kita tetap harus menarik hal-hal lain
      Mungkin kita bisa mendapatkan komponen yang dapat digunakan ulang, tetapi kalau membayangkan menggunakan web component yang secara internal memakai Vue di tempat yang memakai React, rasanya kurang masuk akal
    • Saya sangat senang ada arus yang mendorong web component tanpa Shadow DOM
      Keindahan dan keanggunan web berasal dari struktur deklaratifnya, yang membuatnya bisa diamati dan dimodifikasi
      Shadow DOM terasa seperti dorongan korporat untuk membangun penghalang enkapsulasi dan kepastian yang lebih tinggi, dan secara pribadi itu bukan tujuan yang saya bagi
      Tulisan ini menunjukkan bagaimana pekerjaan dengan Light DOM dapat dikomposisikan
      Saya selalu berpikir web component atau custom element seharusnya bisa memodifikasi DOM internalnya sendiri, memindahkan anak-anaknya, dan membuat konten baru
      Misalnya, halaman atau framework bisa memasukkan ikon, lalu elemen avatar pengguna bisa menyisipkan nama atau elemen dekoratif
      Namun satu kekhawatiran saya tentang Light DOM/HTML Web Components adalah Shadow DOM memberi beberapa keuntungan performa
      Sebagai developer, saya bisa membayangkan bahwa ia dapat mengurangi jumlah elemen yang harus ditelusuri selector CSS, dan saya berharap keuntungan itu juga bisa dimanfaatkan dengan cara tertentu
      Saya sangat senang dengan pendekatan yang melihat custom element dan Web Components secara lebih ringan, dan terima kasih untuk tautannya
    • Mungkin nama yang terdengar masuk akal itu bisa dipersingkat lagi menjadi HTML components

  • Ungkapan “bisa dirender sebelum JavaScript. Komponen React tidak akan pernah bisa begitu” sulit dinyatakan secara mutlak; dengan server-side rendering, ia bisa dirender sebelum JavaScript sisi klien
    Menurut saya contohnya terlalu sederhana untuk menunjukkan klaim penulis
    Web component yang menangani perubahan state akan menjadi pembanding yang lebih baik, dan argumennya juga mungkin akan lebih kuat

    • Poin yang bagus, dan sebaliknya, web component juga harus didaftarkan dengan JavaScript sebelum halaman dimuat, jadi bisa dibilang tidak bisa begitu
      Ada solusi hydration, tetapi biasanya lebih buruk, memiliki kompromi yang mengejutkan, dan sering merusak composability
    • Masalah terbesar pada Web Components adalah tidak ramah server-side rendering
    • Saya tidak tahu bagaimana “HTML Web Component” akan menangani perubahan state
      Kalau hanya melihat contoh yang membungkus tag img, manfaatnya tidak terlalu terasa; memang bisa mengelompokkan dan memakai ulang elemen umum, tetapi untuk interaksi tetap membutuhkan JavaScript
      Teks alternatif gambar pada contoh juga sekarang biasanya dinamis karena lokalisasi, jadi tanpa JavaScript kontennya bisa hilang

  • Sepertinya saya akhirnya mulai memahami Web Components: https://github.com/kennyfrc/cami.js
    “No Build Steps, No Client-Side Router, No JSX, No Shadow DOM. We want you to build an MPA, with mainly HTML/CSS, and return HTML responses instead of JSON. Then add interactivity as needed.”
    “Declarative templates with lit-html. Supports event handling, attribute binding, composability, caching, and expressions.”

    • Keindahan Web Components adalah Anda bisa mencari atau membuat base class yang berperilaku sesuai kebutuhan
      Secara pribadi, saya suka class bergaya komponen class React yang memiliki state machine bawaan yang terinspirasi dari XState
      https://github.com/codewithkyle/supercomponent/blob/master/s...
    • Saya penasaran apakah Anda pernah mencoba HTMX
      Arahannya terlihat cukup mirip, dan komunitas HTMX mungkin lebih besar
      Kalau sudah pernah mencoba, saya ingin tahu bagian mana yang terasa kurang
    • Ini sama saja mengganti JSX dengan DSL kustom nonstandar lalu menyebutnya kemenangan

  • “web components” bukan satu benda, dan bukan juga membuat “a web component”
    “Web Components” adalah nama untuk Web Components API yang menggabungkan tiga hal
    Yang sebenarnya Anda buat adalah custom element, dan di situ Anda bisa memakai Shadow DOM atau HTML template
    Dari tiga hal itu, yang paling penting adalah custom element
    Konsep intinya adalah “membuat lebih banyak elemen HTML”, jadi atribut dan JavaScript API apa yang didukung sepenuhnya Anda tentukan sendiri
    Cara menaruhnya di halaman, berinteraksi dengannya, dan mendengarkan event-nya juga sama persis seperti elemen HTML lainnya
    Kalau Anda tahu cara menulis halaman web dengan “cara lama”, Anda sebenarnya sudah tahu cara menggunakan custom element; yang perlu dipelajari hanya cara mendeklarasikannya

  • Belakangan ini saya mulai mencoba Web Components tanpa lingkungan build
    Tidak ada npm, bun, webpack, atau semacamnya, tidak ada dependensi, dan ditulis dengan TypeScript
    IntelliJ mengompilasinya otomatis ke JavaScript, dan browser view menyuntikkan handler pendeteksi perubahan kecil untuk pembaruan real-time selama pengembangan
    Sejauh ini tidak ada masalah
    Yang tampaknya menghambat Web Components adalah HTML Modules
    Akan bagus jika untuk mengimpor web component kita bisa menautkan ke file .html, bukan file .js, tetapi saat ini kalau ingin memakai template atau sesuatu yang sedikit lebih kompleks, kita harus melakukan injeksi jelek seperti .innerHtml = \...``
    Saya sempat mengira ini akan jadi masalah, tetapi IDE ternyata mem-parsing template string dengan cukup baik

    • HTML Modules sudah dibatalkan dan dihapus, lalu diganti dengan impor khusus JavaScript
      Dan itu juga bukan satu-satunya alasan yang menghambat Web Components

  • Saya kurang bisa menerima klaim bahwa “React adalah pengganti, bukan penguatan”
    Pada akhirnya React juga merender elemen HTML dan memasang handler event JavaScript
    Membungkus img sebagai komponen React bukan berarti mengambil alih fungsi img, melainkan menambahkan sesuatu di atasnya, yaitu penguatan
    Mungkin penulis pernah bekerja di codebase React yang berbeda, tetapi berdasarkan pengalaman saya, kalau tidak ada alasan khusus kami tetap memakai fitur bawaan browser apa adanya
    Mungkin saja saya hanya beruntung

    • Tentu saja arsitektur web apa pun pada akhirnya merender elemen HTML, tetapi bukan itu intinya
      Intinya adalah pendekatan “HTML Web Component” ini, berbeda dari React, tidak bergantung pada JavaScript untuk memulai rendering
    • Menurut saya perbedaan utama yang disampaikan tulisan itu kira-kira seperti ini
      Dari sudut pandang rendering browser, React adalah “halaman dimuat → komponen dimuat”, sedangkan Web Component lebih dekat ke “halaman dimuat → rendering dasar → komponen dimuat”
      Orang yang mematikan JavaScript masih bisa melihat sesuatu pada web component, tetapi bisa saja tidak melihat apa pun di React; dan jika JavaScript tersedia, status render dapat ditingkatkan lebih jauh
    • Dalam beberapa kasus, React juga membuat akses ke fitur bawaan menjadi lebih sulit
      Misalnya, jika onchange dipasang pada sebuah elemen, React memberikan sesuatu yang lebih mirip event input, bukan event change
      Sebenarnya bukan keduanya, melainkan synthetic event yang lebih dekat ke input daripada change
      Jika benar-benar menginginkan change, harus memakai referensi elemen dan memasang handler secara langsung di dalam effect
    • Tergantung arsitektur aplikasinya
      Jika React mengembalikan HTML dari server, membungkus img sebagai komponen React memang berarti memperkuat elemen yang sudah ada
      Namun jika semuanya dirender di sisi klien, img itu pada akhirnya tidak bisa dipisahkan dari komponen React
    • Saat membaca bagian itu, saya terpikir arah sebaliknya, yaitu kasus memasukkan React ke dalam HTML lain
      Berdasarkan pengalaman, React sangat bagus ketika diberi tanggung jawab atas seluruh struktur halaman dari atas ke bawah, tetapi bisa menjadi sulit ketika disisipkan ke dalam struktur yang sudah ada sambil melakukan hal seperti server-side rendering

  • Jika mencari pendekatan yang tahan lama, kesimpulan bahwa kita sebaiknya memilih penguatan dan peningkatan daripada penggantian juga sesuai dengan pengalaman saya
    Berkat filosofi ini, proyek-proyek web saya bisa bertahan lama dengan pemeliharaan dan dependensi yang minimal

  • Web component seharusnya melakukan satu hal, sedangkan framework JavaScript lebih mendekati sebuah ekosistem utuh
    Saya pernah membuat web component pemutar video yang bisa menerima beberapa jenis input, dan input paling kompleksnya adalah file torrent
    Dengan StencilJS [0], komponen itu juga bisa di-port ke Vue/React, tetapi tanpa itu pun sudah cukup dapat digunakan
    Cukup masukkan tag tersebut bersama class yang diekspor dari awesomePlayer.js, dan Anda mendapatkan pemutar video HTML5 siap salin-tempel yang dapat memutar torrent
    Jika memungkinkan, saya juga sangat menyarankan meniru elemen HTML yang sudah ada
    Misalnya, penggunaan src dilakukan karena video juga begitu, sehingga pihak yang memakai dapat berinteraksi tanpa harus membongkar dokumentasi
    [0] https://stenciljs.com/

  • Saya sulit setuju bahwa komponen framework frontend sepenuhnya bersifat pengganti dan tidak dapat dikomposisikan
    Dari luar mungkin terlihat begitu, tetapi di komponen saya, saya banyak memakai slot, dan implementasinya juga mudah serta bekerja secara alami
    Sebaliknya, Web Components biasanya didemonstrasikan dengan cara menyisipkan kode dalam jumlah sangat besar untuk membuat sesuatu seperti editor
    Menggunakan slot di Web Components terasa menyakitkan, harus banyak menempelkan node secara manual, memperlakukan template sebagai string, dan untuk melakukan hal yang sedikit rumit bahkan harus mendengarkan event slotchange
    Pada dasarnya itu berarti memakai DOM API, dan kalau API itu tidak buruk, kita mungkin tidak akan pernah beralih ke framework frontend seperti React
    Saya juga tidak setuju dengan klaim sampingan bahwa XHTML gagal karena tidak memperkuat HTML
    Menurut saya, XHTML gagal karena aplikasi harus sepenuhnya valid dan validasi itu diserahkan kepada klien/browser
    Jika memakai XHTML sungguhan, satu kesalahan kecil dalam markup saja bisa merusak halaman; karena itu semua orang memang memvalidasi XHTML demi kesiapan masa depan, tetapi tidak ada perusahaan yang mau mengambil risiko bisnisnya ikut rusak hanya karena satu tag p tidak ditutup dengan benar