Web Components itu tidak masalah

 (nolanlawson.com)
2 poin oleh GN⁺ 2024-10-01 | 1 komentar | Bagikan ke WhatsApp
  • Perdebatan tentang web components bukan soal harus memilih salah satu antara kinerja tertinggi dan standar platform, dan asumsi bahwa semuanya harus menggantikan seluruh framework JavaScript sejak awal sudah berlebihan
  • Custom Elements memiliki overhead karena menggunakan DOM sebagai antarmuka, tetapi dalam produk nyata yang dinilai bukan hanya performa, melainkan juga kemudahan pemeliharaan, keamanan, kegunaan, dan aksesibilitas
  • Biaya dukungan web components di framework bisa diserap lewat beberapa pemeriksaan sederhana, dan meski merupakan fitur standar, itu tidak berarti semua framework wajib mengadopsinya
  • Web components memiliki kelemahan pada server-side rendering (SSR), aksesibilitas, dan sebagian interoperabilitas, sehingga masih ada situasi di mana React, Solid, dan Svelte lebih cocok
  • Di lingkungan seperti Salesforce, tempat aplikasi client-rendering, marketplace komponen, dan kompatibilitas mundur jangka panjang penting, web components bisa menjadi pilihan yang realistis

Titik awal perdebatan dan posisi penulis

  • Perdebatan terbaru berlanjut dari “Web Components Are Not the Future” oleh Ryan Carniato dan “Web Components Are Not the Future — They’re the Present” oleh Cory LaViska
  • Isunya bukan menyerang kubu lawan, melainkan lebih dekat ke pertanyaan apakah para developer dengan batasan yang berbeda bisa menemukan titik temu
  • Ryan Carniato sangat dihargai lewat Solid dan pekerjaan desain framework serta performa yang terlihat di js-framework-benchmark
  • Web components juga punya wilayah penggunaan nyata yang terhubung dengan implementasi framework, pembuatan komponen, Web Components Community Group, grup Accessibility Object Model, serta pekerjaan pada shadow DOM, custom elements, dan aksesibilitas

Performa: biaya DOM itu nyata, tetapi bukan segalanya

  • Kelemahan dasar web components adalah fondasinya pada Custom Elements
    • Semua antarmuka harus melewati DOM, sehingga muncul overhead performa
    • Jika tujuannya adalah framework tercepat secara absolut, node DOM harus dikurangi semaksimal mungkin, dan menurut tolok ukur ini web components kurang diuntungkan
  • Namun performa bukan satu-satunya kriteria dalam pengembangan perangkat lunak
    • Kemudahan pemeliharaan, keamanan, kegunaan, dan aksesibilitas juga harus dipertimbangkan
    • Jika atribut aria-* tidak dirender, rendering DOM mungkin bisa sedikit lebih cepat, tetapi atribut itu bisa diperlukan untuk antarmuka yang aksesibel
    • Mikro-optimisasi seperti for loop yang lebih cepat daripada .forEach() atau var yang lebih cepat daripada const/let biasanya tidak cukup berharga untuk dikejar
  • Meminimalkan node DOM adalah gagasan inti dari virtualization
    • Meski bukan pilihan tercepat, pendekatan yang lebih sederhana kadang sudah cukup
    • components as elements juga bukan yang paling optimal, tetapi tujuan tidak harus selalu optimal di segala hal
  • Pendekatan memakai custom elements yang dibuat dengan framework berbeda secara bersamaan juga bermakna dalam praktik
    • Bisa saja perlu migrasi bertahap dari Framework A ke Framework B
    • Ada juga kasus yang mengharuskan penggabungan beberapa micro-frontend
    • Mungkin bukan antarmuka tercepat, tetapi bisa menjadi trade-off yang diperlukan
  • Dalam performa web nyata, titik perbaikan berbiaya rendah seperti layout thrashing, network waterfall, dan re-render yang tidak perlu jauh lebih umum
    • Persaingan seperti js-framework-benchmark menarik bagi penulis framework, tetapi tidak selalu menentukan dalam situasi produk pada umumnya
    • Jika setiap milidetik penting di lingkungan dengan sumber daya terbatas, membuang web components juga merupakan pilihan yang valid

Biaya dukungan framework dan kebebasan memilih

  • Penulis tidak setuju dengan klaim bahwa dukungan web components adalah biaya yang terlalu besar bagi penulis framework
    • Deteksi props dan attributes bisa ditangani dengan pemeriksaan prop in element
    • Menghasilkan output berupa web components bisa terasa menyakitkan, tetapi itu bukan pekerjaan yang wajib dilakukan semua framework
    • Vue 2 memakai web component wrapper library terpisah, dan Remount ada tanpa masukan dari tim React
  • Framework tetap bisa dibuat dengan sangat baik meski mengabaikan fitur yang ditambahkan ke web platform sejak 2011
    • jQuery v1 masih berjalan di banyak situs web
    • Karena tim performa browser mengoptimalkan pola dari developer web masa lalu, kode lama malah bisa berjalan lebih cepat di browser baru
  • Memilih untuk menerima fitur web platform modern membawa pertimbangan baru
    • Fitur seperti Symbol, Proxy, dan Promises juga masuk kategori yang sama
    • Berkat kompatibilitas mundur web, kode yang ditulis hari ini bisa tetap berjalan 10 tahun lagi
  • Framework yang tidak tertarik pada web components atau tidak ingin mendukungnya tetap sepenuhnya masuk akal
    • Seluruh UI bisa dibuat dengan web components
    • Bisa juga hanya mencampurkan sebagian HTML web components
    • Memilih untuk sama sekali tidak memakainya juga memungkinkan
    • Framework “tanpa web components” pun bisa punya penggemar

Standar adalah titik acuan, bukan kewajiban

  • Ketika suatu fitur menjadi standar, developer akan sadar akan fitur itu sebagai pembanding dasar
    • Penulis komponen harus memutuskan apakah <slot> miliknya harus berperilaku seperti <slot> bawaan
    • Mereka juga harus memilih apakah akan memakai IntersectionObserver atau <img loading="lazy">, atau membuat abstraksi sendiri
  • Standar menyediakan titik referensi bersama dan kosakata bersama
    • Ada dasar untuk membandingkan dan mengontraskan pendekatan yang berbeda
    • Namun menjadi standar tidak berarti harus selalu dipakai
  • Di web, fitur yang boleh tidak dipakai dan API lama tetap hidup berdampingan
    • API deprecated seperti document.domain, with, dan <frame> masih tetap didukung
    • Fitur dalam web platform bisa dipilih untuk dipakai atau ditinggalkan

Di mana web components cocok dan tidak cocok

  • Web components bagus untuk banyak hal, tetapi bukan alat untuk menggantikan semua framework JavaScript
  • Kelemahannya mencakup server-side rendering (SSR), aksesibilitas, dan sebagian interoperabilitas
  • Masih banyak situasi di mana framework seperti React, Solid, dan Svelte lebih menonjol
  • Pernyataan “web components bukan masa depan” bisa benar untuk developer atau proyek tertentu
  • Di akar perdebatan ini ada kenyataan bahwa orang yang berbeda membuat hal yang berbeda di bawah batasan yang berbeda pula

Kasus Salesforce dan penilaian praktis

  • Salesforce menunjukkan lingkungan yang bisa sangat cocok untuk web components
  • Jika kondisinya tidak seperti itu, mungkin tidak perlu membangun seluruh UI dengan web components, shadow DOM, dan seluruh susunan terkaitnya
  • Di web platform, game, proyek seni, dan aplikasi SaaS enterprise yang dibangun dengan berbagai fitur seperti WebGL, Wasm, dan Service Workers hidup berdampingan
  • Saat fitur baru ditambahkan ke platform, itu bukan membatasi kreativitas, melainkan menambah peluang berekspresi dengan cara yang sebelumnya tak terpikirkan
  • Bacaan lanjutan juga mencakup tulisan oleh Lea Verou dan tulisan oleh Baldur Bjarnason

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-01
Opini Hacker News

  • Saya mencoba memahami tulisan yang dirujuk, “Web Components Are Not the Future”, tetapi tidak banyak argumen yang meyakinkan
    Kondisi framework frontend saat ini berantakan, dan saya tidak ingin mempelajari sihir (useState, createSignal, dll.) yang tidak bisa dipahami sebelum membaca framework atau dokumentasi yang rumit
    Jika mulai dari Web Components, rasanya intuitif, dan kita juga mendapat kemampuan yang tidak ada di tempat lain seperti isolasi Shadow DOM
    Menurut saya, satu-satunya hal yang layak dipertahankan dari era React hanyalah JSX, dan saya membuat library yang memakai Web Components bersama JSX: https://webjsx.org

    • Kalimat “tidak ingin mempelajari framework yang rumit” mencampur beberapa gagasan sehingga sulit ditafsirkan
      Tidak jelas apakah maksudnya tidak ingin mempelajari framework itu sendiri, menginginkan sesuatu yang terasa ajaib sampai tidak perlu dipelajari, atau ingin/tidak ingin membaca dokumentasi
      Saya terutama memakai Vue, dan meski ekosistem SPA memang rumit, saya juga tidak tahu sistem lain seperti apa yang mungkin untuk mengelola aplikasi klien dengan state yang kompleks
    • Ada juga perbedaan dalam cara memandang UI
      Pola dasar jQuery berpusat pada efek samping, yaitu memilih elemen lalu mengubahnya, sedangkan React atau Vue.js memungkinkan kita membuat komponen yang UI-nya ditentukan oleh state sebagai data
      Saat data berubah, UI diperbarui dengan perubahan DOM seminimal mungkin, dan pendekatan ini membuat widget UI jauh lebih mudah dibaca dan dipelihara berdasarkan lokasinya
      Situs web dan aplikasi desktop berbasis web saat ini jauh lebih kompleks dibanding 20 tahun lalu, jadi jika yang dibuat bukan hanya UI sederhana, inovasi dari sisi manajemen state menjadi penting
    • Untuk menulis aplikasi React, kita tidak perlu tahu bagaimana useState bekerja secara internal, dan cara menerapkannya cukup intuitif
      Sebaliknya, library yang diajukan tampak menuntut model mental yang lebih kompleks sejak awal
      Memahami detail framework secara mendalam memang ideal, tetapi React berhasil karena memungkinkan orang membuat aplikasi yang cukup canggih nyaris tanpa mengetahui model internalnya
    • Angular tidak sesulit itu, dan dalam sekitar seminggu orang bisa mempelajarinya sampai mampu membuat situs yang kompleks atau mengirim PR yang layak
      Mungkin juga karena saya sudah menjadi developer sejak era beta C# dan masa awal HTML/JS/CSS, tetapi saya cepat memahaminya
      Saat mengganti portal manajemen infrastruktur inti yang tua dan rumit, kami memilih Angular; hasilnya stabil, cepat, tampak bagus, dan semua orang puas
      “Kurva belajar yang curam” tampaknya terutama datang dari developer yang masuk industri hanya dengan pengetahuan JavaScript dan sedikit React; dengan pengalaman lebih banyak, orang bisa langsung memahaminya
    • Jika seorang developer penasaran dengan internal useState, ia bisa sampai pada jawaban yang logis dan benar dalam hitungan detik
      Itu tidak rumit atau ajaib, dan implementasi minimal yang mirip hook React bisa dibuat dalam beberapa ratus baris
      Implementasi dasar useState dan runFunctionComponent lebih mudah daripada sebagian besar tugas semester 3 ilmu komputer di universitas
      Jika ini standar untuk disebut sihir, berarti sekitar kita penuh dengan Warlock level 20 yang menciptakan Eldritch Invocation baru bahkan saat sarapan

  • Saya melihat salah satu alasan orang saling tidak nyambung dalam perdebatan ini adalah karena target optimisasinya berbeda
    Jika Anda membangun produk inti di startup yang didanai VC, harus bergerak cepat dan terus dipelihara, framework mungkin cocok
    Namun di laboratorium akademis, sering kali tidak ada banyak uang untuk memelihara aplikasi yang sudah dibuat, dan aplikasi itu harus tetap berjalan setelah dana berpindah ke proyek baru
    Saya hampir selesai menulis ulang aplikasi Vue menjadi Web Components, karena dependensinya sudah membusuk sampai tidak bisa diperbarui
    Sebelumnya saya menghabiskan waktu memperbaiki neraka dependensi dan kemungkinan akan terus begitu; setelah mencoba Web Components dan langsung terasa bagus, saya beralih
    Dependensi berkurang dari sekitar 15 menjadi sekitar 1 (d3js), dan saya tidak menyesal
    Aplikasi lama https://bam.iobio.io/, aplikasi baru https://bam2.iobio.io/

    • Kadang saya sulit memahami logika ini
      Tidak ada yang memaksa framework selalu dinaikkan ke versi terbaru, jadi seharusnya bisa tetap berada di versi Vue yang digunakan
      Jika tidak ada alasan khusus, mungkin tidak masalah memakai versi yang sama sampai akhir
      Ini bukan berarti Vue sejak awal tidak diperlukan untuk use case itu atau menghapus dependensi adalah pilihan buruk, tetapi jika Vue disukai, tampaknya tidak ada paksaan untuk selalu berada di versi terbaru
    • Jika dependensi bisa dihapus hingga hanya menyisakan d3js, bukankah mungkin melakukan hal yang sama sambil tetap mempertahankan dependensi Vue
      Saya penasaran apakah alasan Vue membutuhkan dependensi tambahan ada di sisi sistem build
    • Setelah terbiasa, saya rasa pengembangan Web Components tidak akan lebih lambat daripada framework mana pun
      Jadi saya tidak begitu paham mengapa ekosistem VC tidak bisa bertahan tanpa framework
    • Sulit dipercaya bahwa semua Web Components ditulis tangan, dan juga sulit percaya bahwa tidak ada dependensi eksternal sama sekali

  • Saya suka bahwa Svelte mendukung pembuatan Web Components melalui Custom Elements API
    Karena Svelte dikompilasi menjadi JS/HTML/CSS biasa, wajar untuk membuat komponen reusable yang bekerja di framework apa pun maupun vanilla JS: https://svelte.dev/docs/custom-elements-api

  • Saya sudah mengikuti diskusi Web Components selama bertahun-tahun, tetapi sebagai full-stack developer saya masih belum begitu paham apa yang bisa dilakukannya untuk membuat hidup lebih baik
    Sebagian besar contoh ini hanya sebatas memasukkan data ke HTML sebagai template, dan itu sudah bisa dilakukan dengan handlebars
    Apakah ada sesuatu yang saya lewatkan?

    • Di “web”, ada model yang memandang HTML sebagai dokumen, dan model yang memandang HTML sebagai scene graph untuk aplikasi yang lebih kompleks
      Jika memakai HTML sebagai dokumen, Web Components bisa menambahkan fitur interaksi real-time yang lebih menarik
      Contohnya adalah emulator terminal yang terhubung ke WebSocket, date picker, elemen form kustom, peta, data table, widget tab, dan komponen kustom yang dulu disediakan jquery-ui
      Ini bisa dilakukan tanpa Web Components, tetapi jika dibuat sebagai komponen kustom, HTML menjadi jauh lebih rapi dan tetap terasa seperti dokumen
      Akan bagus jika ada pustaka Web Components yang konsisten, dan dengan HTMX serta server-sent events, chat real-time yang cukup baik juga tampaknya memungkinkan
    • Isolasi native sepenuhnya dimungkinkan
      Browser mengisolasi seluruh HTML, CSS, dan JS tanpa trik tambahan
      Menurut saya bagus bahwa kita bisa membuat Web Component, mendefinisikan API JS, HTML, dan CSS secara jelas berdasarkan variabel, lalu memasukkannya ke lingkungan apa pun tanpa rusak, atau tanpa harus membuat namespace CSS yang rumit dan labirin dependensi framework
    • Sangat bagus untuk progressive enhancement
      Misalnya, Web Component yang membungkus tabel bisa menambahkan fitur seperti filtering atau pengurutan drag-and-drop, dan meskipun JS dimatikan atau gagal dimuat, pengguna tetap menerima tabel dasar beserta kontennya
      Dulu ini jauh lebih baik daripada layar putih dari framework frontend, tetapi sekarang server-side rendering sudah tersedia luas sehingga keunggulannya berkurang
      Enkapsulasi style juga bagus, tetapi sekarang pustaka headless UI dan scoped styles di framework sudah umum, jadi terasa tidak sekrusial 10 tahun lalu
      Namun, untuk memakai slot kita harus memilih Shadow DOM, sehingga menjengkelkan ketika membuat komponen reusable sendiri karena tidak bisa menata gayanya dengan cara memasukkan satu stylesheet ke halaman
    • Alasan contoh-contohnya menghindari API dinamis mungkin karena bagian itu sangat jelek dan penuh state
      Jika sebuah demo menampilkan 200 baris manipulasi DOM manual, sulit untuk mengatakan bahwa Web Components adalah masa depan
    • Web Components memungkinkan komponen UI yang dibuat dengan framework lain dipakai di framework saya
      Itu saja, dan untuk sebagian besar tujuan lain cukup buruk
      Selain itu, kita bisa merilis komponen UI agar berjalan di semua framework tanpa harus membuat 7 versi

  • Bagian terburuk dari Web Components dan Shadow DOM adalah bahwa keduanya bisa membuat ekstensi browser tidak bekerja dengan benar atau bahkan sama sekali tidak bisa bekerja
    Vendor browser juga tidak terburu-buru memperbaiki situasi ini

    • Kemampuan untuk dikonfigurasi pada user agent adalah killer feature web

  • Salah satu “kesalahan” terbesar Web Components, menurut saya, adalah orang-orang mengaitkannya dengan Shadow DOM di kepala mereka
    Dalam pengembangan aplikasi, jika tetap menggunakan live DOM, Web Components menjadi pilihan yang sangat ringan dan mudah
    Kita bisa tetap memakai alat CSS apa pun yang diinginkan seperti bootstrap, tailwind, dan mendapatkan enkapsulasi fungsional yang sangat baik dengan biaya hampir nol, terutama jika memakai sesuatu seperti lit-html sebagai renderer
    Tim-tim umumnya merasa bekerja dengan Web Components native itu menyegarkan, dan developer yang datang dari dunia framework, setelah beradaptasi sekitar seminggu, tidak ingin kembali lagi
    Hanya dengan properti class sederhana dan pemanggilan manual fungsi render dari set(), kita bisa mendapatkan manfaat reaktivitas tanpa kerepotan framework
    Masalahnya adalah tidak banyak materi yang menunjukkan cara memulai dalam “easy mode”
    Sebagian besar materi pemula langsung mendorong orang ke teknik menyakitkan seperti Shadow DOM dan CSS parts yang lebih ditujukan untuk penulis pustaka daripada developer aplikasi
    Rasanya perlu menulis panduan seperti “The Good Parts” tentang cara membuat hidup lebih mudah dengan Web Components

    • Saya memakai Shadow DOM setiap hari, tetapi bagian yang paling sering membingungkan orang di Web Components juga biasanya ini. Mungkin karena sebenarnya tidak dibutuhkan
      Sebagai alternatif, ada “HTML web components” yang hanya memakai live DOM, mengutamakan server-side rendering, dan bagus sebagai pengganti “bumbu jQuery”: https://adactio.com/journal/20618
      Ada juga “Shadow gristle”, yang memakai Shadow DOM sesedikit mungkin dan menaruhnya di live DOM jika perlu styling atau komposisi: https://glazkov.com/2023/03/02/shadow-gristle/
    • Kalau Anda menulis tentang ini, saya ingin membacanya. Mendengarnya juga bagus
      Teknologi ini tampaknya bisa menjadi berkah sekaligus kutukan tergantung cara pemakaiannya, jadi saya sedang mengumpulkan materi dan komentar terkait
    • Di tempat kerja sebelumnya kami memakai stack yang sama, yaitu WC tanpa Shadow DOM dan hanya lit-html, dan itu sangat bagus
      Hal terbaiknya adalah tidak terjerumus ke dependency hell setiap dua minggu sekali
    • Tepat di bagian itu. Yang hilang sekarang adalah slot untuk light DOM

  • Interoperabilitas adalah keunggulan terbesar dari sudut pandang pengguna, tetapi sepertinya orang meremehkan bahwa sebagai gantinya ada biaya performa: setiap komponen yang digunakan bisa membawa runtime yang tidak perlu
    Menggunakan framework seperti Lit bersama Web Components adalah cara yang direkomendasikan, dan seiring waktu, ketika framework baru muncul dan komponen terikat pada versi lama, biaya ini akan menumpuk
    Saya tidak ingin merekomendasikan kepada siapa pun arah yang membuat satu halaman memiliki beberapa library duplikat, dan jika itu termasuk dalam praktik terbaik, dalam jangka panjang itu tidak baik
    Saya sudah beberapa tahun membaca tulisan, media sosial, dan video dari para pendukung Web Components, dan seharusnya sayalah pengguna sasarannya, tetapi di atas pajak interoperabilitas ada banyak kekurangan yang tidak ada pada framework arus utama
    Di dalam ekosistem tiap framework, interoperabilitas bekerja dengan baik, dan dinamika yang sama yang membuat developer mencari interoperabilitas juga membuat mereka berkumpul di sekitar segelintir framework arus utama
    Menurut saya Web Components tertinggal dari sisi teknologi, dan menambahkan banyak kompleksitas ke platform web demi desain awal 2010-an: https://x.com/Rich_Harris/status/1840116730716119356

    • Sudah dibahas di tulisan lain, tetapi secara garis besar, tidak semua aplikasi web sensitif terhadap performa untuk setiap kB tambahan. E-commerce memang begitu, tetapi alat produktivitas biasanya tidak
      Ada banyak framework dengan runtime kecil seperti Svelte, dan saya tidak mengatakan kita harus menaruh 100 framework dalam satu halaman, tetapi menurut saya 5–6 masih oke
      Bukan berarti itu ideal, tetapi bisa membantu untuk migrasi bertahap atau micro frontend
      Sebagai catatan, React 17 juga memperkenalkan kemampuan untuk menaruh beberapa versi React di halaman yang sama: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/, https://bundlephobia.com/package/svelte@4.2.19, https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
    • Itu memang benar, tetapi melihat sebagian besar aplikasi web yang dibuat hari ini, masalah banyak library tampak seperti galat pembulatan
      React dan react-dom digabungkan sudah lebih dari 100KB, sementara Svelte dan Lit hanya beberapa KB
      Anda bisa memasukkan cukup banyak framework sebelum mendekati bloat yang digunakan orang setiap hari tanpa pikir panjang
    • Dilihat lebih luas, Web Components perlu meyakinkan para pembuat framework
      Sinyal yang saya lihat secara konsisten sejauh ini tidak bagus, komunitas itu ada di X, dan Web Components tidak menyelesaikan masalah mereka serta tidak banyak digunakan bahkan dalam kondisi terbaik
      Saya berharap upaya meyakinkan itu berhasil, tetapi secara umum mereka cenderung mengatakan bahwa Web Components telah gagal dan secara keseluruhan buruk bagi web
    • Sejujurnya saya tidak terlalu memahami argumen ini
      Kebanyakan runtime cukup kecil, dan menjalankan dua runtime sekaligus tidak berarti overhead performanya besar
      Semua framework web modern bersifat reaktif, jadi jika tidak ada yang perlu direspons, mereka tidak melakukan apa-apa
      Jika sebagian halaman dibuat dengan React, bagian lain dengan Lit, dan bagian lainnya lagi dengan Svelte, saya tidak begitu melihat alasan mengapa pengalaman pengguna atau konsumsi baterai akan terasa lebih buruk dibanding halaman dengan satu framework
      Tweet yang dikutip membahas apakah Web Components adalah “primitive yang berguna untuk membuat framework”, dan bahkan para penggemar yang benar-benar pernah memakainya biasanya tidak akan mengatakan demikian
      Web Components adalah mekanisme distribusi, dan jika alternatifnya hanyalah membuat library yang sama 7 kali untuk React, Preact, Svelte, Solid, Vue, dan vanilla JS, itu mengerikan

  • Saya menyukai Web Components, dan optimistis bahwa ini berpotensi membantu kita keluar dari neraka frontend yang kita ciptakan sendiri saat ini
    Baru-baru ini saya memberikan presentasi singkat tentang masa depan frontend, dan tampaknya orang lain juga berharap ada jalan keluar
    Saya membuat tabel data untuk GUI DB, dan scrolling tetap sangat mulus meski memuat ratusan ribu baris
    Saya juga berencana segera merilis library Web Component; masih dini dan kasar, tetapi saya berharap lebih banyak orang melihatnya: www.astra-ui.com

    • Menurut saya satu-satunya jalan keluar dari neraka frontend saat ini adalah hadirnya client-side import: https://github.com/whatwg/html/issues/2791
    • Saya melihat dokumentasinya, dan rendering di Safari 18.0 pada iPhone 15 Pro Max sangat aneh
      Sebaiknya pertimbangkan desain responsif untuk layar kecil dengan memindahkan ulang sidebar, dan gunakan max-width pada body alih-alih width
      Tombol “explore components” di bagian bawah homepage sepertinya tidak mengarah ke mana pun
      Dikatakan “belajarlah dari implementasi komponen yang terstruktur baik dan aksesibel”, tetapi saya tidak menemukan tautan implementasi di dokumentasi
      Dikatakan “tidak ada dependensi yang perlu dikelola atau diperbarui”, tetapi bukankah astra-ui sendiri adalah dependensi, dan juga ada changelog: https://www.astra-ui.com/changes/
      Dikatakan juga “kendali penuh atas kode dan styling”, tetapi saya tidak mengerti bagaimana kendali penuh dimungkinkan sambil bergantung pada implementasi yang disediakan library
      Saya penasaran mengapa Anda memutuskan merilis library ini. Meng-open-source-kan software internal berguna ketika perusahaan punya tujuan tertentu, tetapi biasanya mudah menjadi konsumsi waktu tanpa imbalan
      Library komponen harus bertarung untuk adopsi ekosistem; jika tidak, tidak ada audiens, sehingga alasan untuk merilisnya kecil
    • Apa alasan untuk memakai ini alih-alih sesuatu seperti komponen Vue?
    • Mengapa Web Components belum benar-benar mapan atau belum digunakan lebih luas?
      Ini terlihat seperti solusi yang bagus
    • Saya menulis ulang kode iklan frontend perusahaan dengan Web Components

  • Beberapa bulan lalu, di tempat kerja baru, saya mewarisi codebase JS sekitar 250 ribu baris
    Satu class raksasa dan beberapa subclass mengerjakan semuanya, dan ada file yang sampai 30 ribu baris
    Tidak ada framework maupun reaktivitas, jadi ketika tombol diklik, semua yang ada di layar harus diperbarui secara manual lewat event listener
    Kodenya seperti ditulis oleh seseorang yang selama bertahun-tahun dikurung di sel biara hanya berbekal satu buku JavaScript dasar
    Karena harus dilakukan sedikit demi sedikit, saya mulai refactoring ke Web Components, dan itu sangat membantu; sejauh ini sudah mengurangi 50 ribu baris
    Namun tujuan sebenarnya adalah mempelajari seluruh hal yang dilakukan kode lama sebelum menulis ulang

    • Kunci memahami codebase lama dan sulit adalah melakukan refactoring sedikit demi sedikit
      Membuat ulang dengan Web Components adalah salah satu cara mencapai tujuan itu, dan bagusnya mereka tidak membuang semuanya lalu mulai dari nol
      Namun jika setelah berjalan cukup jauh lalu pindah ke proyek lain, ada risiko orang berikutnya datang dan mulai refactoring dengan gayanya sendiri, sehingga menjadi codebase sulit dengan tiga gaya berbeda
      Tetap saja, itu lebih baik daripada menulis ulang 250 ribu baris sekaligus

  • Satu hal yang saya suka dari Web Components adalah, setidaknya secara teori, ia bisa tetap berfungsi bahkan saat JS dinonaktifkan
    Saya beberapa kali melakukannya untuk progressive enhancement
    Secara umum saya setuju dengan Nolan. Web Components punya cukup banyak sisi kasar sehingga dalam kondisi saat ini sulit menguasai dunia, tetapi cukup bagus untuk use case tertentu
    Namun saya kurang paham dengan pernyataan bahwa ia tidak cocok dengan server-side rendering; saya sudah melakukannya tanpa masalah

    • Saya penasaran mengapa dikatakan begitu
      Sejauh yang saya lihat, untuk mendaftarkan template pada tag tertentu sepertinya diperlukan JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
    • Saya tidak tahu bagaimana seharusnya ini bekerja
      Di ReactJS, component atau template bisa dirender di server, dan menurut saya JSX adalah bahasa template yang cukup bagus
      Sepemahaman saya, Web Components tidak memiliki bahasa template bawaan yang bagus, jadi harus membawanya sendiri
      Saya tidak tahu ada mekanisme standar untuk mengambil potongan komponen JS yang terhubung dengan tag lalu merender HTML yang diperlukan tanpa menjalankan JS
    • Saya penulisnya. Saya membahasnya di tulisan lain, tetapi pada dasarnya keuntungan interoperabilitas yang didapat di client belum ada di server
      Jika ke depannya kita bisa merender 3 framework Web Component berbeda di server, semuanya bisa saling dikomposisikan, dan hydration berjalan rapi, barulah bisa dianggap terselesaikan: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/