Web Components Akan Bertahan Lebih Lama daripada Framework JavaScript Anda

 (jakelazaroff.com)
1 poin oleh GN⁺ 2023-10-27 | 1 komentar | Bagikan ke WhatsApp
  • Untuk memperlakukan demo interaktif dari tutorial CRDT sebagai konten yang tahan lama, Web Components yang bisa dimasukkan langsung ke dalam HTML lebih cocok daripada framework tertentu
  • Komponen MDX Astro memberi kemudahan seperti build, cakupan CSS, dan TypeScript, tetapi jika dipindahkan ke luar Astro, biaya penulisan ulang bisa muncul
  • Web Components memungkinkan tag kustom seperti <pixelart-demo></pixelart-demo> dimasukkan ke Markdown, lalu dengan memuat skrip saja, reuse berbasis tag dapat dilakukan di mana saja pada halaman
  • Framework dan TypeScript juga merupakan dependensi, sehingga perubahan versi, API, dan kompatibilitas akan terakumulasi; kode yang lama dibiarkan akan makin sulit dipulihkan semakin banyak dependensinya
  • Web platform cukup stabil sampai situs lama tetap berjalan di browser modern, sehingga untuk karya yang ingin dapat diakses 5, 10, atau 20 tahun ke depan, pendekatan berbasis standar lebih menguntungkan

Melestarikan demo interaktif seperti konten

  • Seri blog CRDT membutuhkan demo interaktif untuk memperlihatkan konsep, dan editor pixel art kolaboratif digunakan sebagai contoh
  • Kriteria pemilihan teknologi adalah bahwa meski demo dibuat dengan HTML, CSS, dan JS, ia lebih dekat dengan konten yang disertakan di dalam artikel blog
    • Lebih mirip objek yang disisipkan ke dalam artikel, seperti gambar atau video
    • Harus bisa dipindahkan ke mana pun yang dapat merender HTML
  • Situs ini dibuat dengan Astro per 2023, tetapi sebelumnya pernah melewati generator situs statis buatan sendiri, Hugo, CMS kustom PHP, Tumblr, Movable Type, WordPress, dan lainnya
  • Sekalipun saat ini menyukai Astro, sulit untuk berasumsi bahwa situs web akan selamanya berjalan di atas Astro

Cara Markdown menurunkan biaya migrasi

  • Alasan migrasi terbaru terasa mudah adalah karena konten dipertahankan sebagai file teks biasa Markdown
  • Pekerjaan yang biasanya diperlukan saat memindahkan sistem menjadi berkurang
    • Mengekspor dari satu sistem dan mengimpor ke sistem lain
    • Memperbaiki masalah kompatibilitas
    • Menghapus elemen yang tidak ditemukan cara memindahkannya
  • Jika file Markdown dimasukkan ke situs web baru, sebagian besar akan langsung berfungsi apa adanya
  • Markdown memungkinkan HTML ditulis langsung, sehingga diagram interaktif yang kompleks pun, jika bisa diekspresikan sebagai tag HTML biasa, dapat dipindahkan seperti konten lainnya

Kemudahan Astro MDX dan batas portabilitasnya

  • Integrasi MDX Astro memungkinkan komponen Astro dirender di dalam Markdown
  • Komponen Astro memanfaatkan berbagai kemudahan dari sistem build
    • Menulis HTML, CSS, dan JS dalam satu file
    • Menangani cakupan selector CSS
    • Mengompilasi TypeScript
    • Merender markup bersyarat
    • Berbagai optimisasi lainnya
  • Masalahnya, semua kemudahan ini hanya bekerja secara stabil di dalam Astro
  • Jika dipindahkan ke generator situs lain, komponen mungkin harus ditulis ulang
    • HTML, CSS, dan JS mungkin harus dipisahkan
    • Konfigurasi sistem build baru mungkin diperlukan
    • Cara baru untuk melakukan cakupan style mungkin harus dicari
  • Karena itu, meski fitur khusus Astro nyaman, fitur tersebut menjadi pilihan yang kurang cocok untuk demo yang perlu dilestarikan jangka panjang

Bagian yang diselesaikan oleh Web Components

  • Web Components adalah kumpulan teknologi standar web untuk membuat elemen HTML yang dapat digunakan ulang
  • Cara pakainya adalah menulis class elemen kustom, mendaftarkan nama tag, lalu menggunakan tag tersebut di markup
  • Demo pixel art disertakan di dalam Markdown hanya dengan HTML berikut
<pixelart-demo></pixelart-demo>
  • Tidak diperlukan konfigurasi khusus terpisah atau prosedur menaruh elemen tertentu terlebih dahulu lalu memanggil fungsi
  • File JS tetap harus dipertahankan dan ditautkan dengan tag <script>, tetapi kebutuhan untuk merujuk media dari dalam konten teks sama seperti media lainnya
  • Setelah skrip dimuat, nama tag didaftarkan, dan meski markup sudah ada sebelum JavaScript berjalan, tag tersebut berfungsi di mana saja pada halaman

Konfigurasi satu file dan Shadow DOM

  • Web Components dapat mengenkapsulasi HTML, CSS, dan JS dalam satu file, tanpa memerlukan sistem build terpisah
  • Jika kode komponen terkumpul di satu tempat, beban mental berkurang; komponen satu file juga punya kelebihan dari sisi pengalaman pengembangan
  • Contoh komponen <pixelart-demo> mewarisi HTMLElement, memasang Shadow DOM dengan attachShadow({ mode: "closed" }), lalu merender markup dan style internal
  • import PixelEditor from "./PixelEditor.js"; di bagian atas file adalah ES module import, sehingga tidak bergantung pada sistem build terpisah
  • Jika file terkait dipertahankan bersama, browser akan menangani modulnya
  • Shadow DOM mengisolasi komponen dari halaman di sekitarnya
    • Bisa terasa canggung saat perlu berbagi style dengan seluruh aplikasi
    • Cocok untuk kasus yang harus benar-benar terisolasi
    • Dapat mempertahankan tampilan dan perilaku yang sama di mana pun digunakan, seperti gambar atau video

Menerima konfigurasi eksternal lewat atribut

  • Web Components dapat mengekspos atribut (attribute) yang dapat dikonfigurasi dari luar
  • Atribut dapat digunakan seperti atribut native
  • Variabel CSS adalah salah satu dari sedikit nilai yang dapat masuk ke dalam Shadow DOM, sehingga contoh range slider mengatur warna aksen seperti berikut
<range-slider style="--accent: #0085F2"></range-slider>
  • Demo pixel art mengubah resolusi menjadi 20 lewat atribut dan menampilkan informasi debug tiap piksel
<pixelart-demo debug resolution="20"></pixelart-demo>
  • Pemanggilan getAttribute dan hasAttribute pada class komponen digunakan untuk membaca nilai atribut semacam ini
  • Ini berguna untuk menggunakan ulang komponen yang sama di berbagai tahap tutorial sambil menyalakan fitur tertentu sesuai tahap progres

Framework dan TypeScript juga dependensi

  • Ada alat seperti Lit, Stencil, dan Svelte yang dikompilasi menjadi Web Components, tetapi framework pada akhirnya tetap merupakan dependensi
  • Trade-off yang paling dikhawatirkan di sini adalah biaya pemeliharaan jangka panjang
  • TypeScript juga bukan bagian native dari web, sehingga termasuk dependensi
  • Dalam 15 versi TypeScript terbaru terdapat breaking change, dan meski banyak dari perubahan itu adalah fitur baru yang berguna, perubahan kode tetap diperlukan
  • Menggunakan dependensi membawa biaya rilis versi baru, perubahan API, dan pemeriksaan kompatibilitas
  • Karena kode ini tidak direncanakan untuk terus disentuh, situasinya adalah tidak ingin harus menangani pembaruan bertahun-tahun sekaligus ketika suatu hari nanti wajib diperbaiki

Pengalaman memulihkan situs web lama dan stabilitas web platform

  • Saat membuat museum online, kode lama yang tersimpan di laptop yang tidak dinyalakan selama 10 tahun dipulihkan, dan semakin banyak dependensi sebuah situs web, semakin sulit menghidupkannya kembali
  • Selama sekitar 20 tahun membuat web, terlihat kelahiran, pertumbuhan, dan kemunduran jQuery, serta lahirnya Node.js dan fork io.js beserta penggabungannya kembali
  • Backbone dengan cepat digantikan AngularJS, AngularJS digantikan React, dan React pun selama kira-kira setengah periode itu telah melewati berbagai cara penulisan komponen
  • Sementara ekosistem berubah, web platform sendiri diubah dengan hati-hati agar tidak merusak situs web yang sudah ada, sehingga tetap cukup stabil
  • Situs-situs lama juga masih berjalan di browser modern
  • Jika menginginkan karya yang tetap dapat diakses 5, 10, atau 20 tahun lagi, lebih cocok mengurangi dependensi yang tidak bisa dikendalikan dan berpegang pada standar web yang kemungkinan besar tidak akan rusak
  • Meski memiliki kekurangan, web menjadi platform komputasi yang tangguh, portabel, dan berorientasi masa depan ketika dibuat dengan mempertimbangkan sifat-sifatnya tanpa lapisan perantara

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-27
Pendapat Hacker News

  • htmx bukan framework, melainkan library, dan karena disebutkan dalam tulisan itu, saya ingin menanggapi beberapa hal
    Pertama, tulisan itu tidak membahas masalah sinkronisasi state antara server dan klien, sedangkan htmx justru berfokus pada masalah tersebut melalui pertukaran hypermedia. Jadi dari sudut pandang ini, htmx dan Web Components adalah dua hal yang saling ortogonal
    Karena dependensi membawa biaya berupa versi baru, perubahan API, dan pemeliharaan kompatibilitas, htmx tidak memiliki dependensi dan sangat berfokus pada kompatibilitas mundur. Misalnya, htmx kompatibel dengan IE11, dan intercooler.js, yang bisa dibilang htmx 1.0, dirilis pada 2013 dengan satu dependensi jQuery tetapi masih didukung hingga sekarang
    Banyak library JavaScript memiliki budaya penulisan ulang API dan upgrade yang sulit, tetapi htmx secara eksplisit tidak demikian, dan tidak seharusnya digeneralisasi seperti itu. Satu-satunya breaking change di htmx 2.0 mungkin hanya penghentian dukungan IE
    Apakah Web Components akan bertahan lebih lama daripada htmx? Karena merupakan bagian dari browser, kemungkinan besar ya. Namun sejauh mungkin, htmx akan tetap sangat stabil dan minim perubahan ke depannya. Pada dasarnya API-nya sudah mengarah ke arah yang benar, dan menurut saya tidak perlu menulis ulang semuanya hanya demi kemurnian atau gaya
    Yang terpenting, htmx menjawab pertanyaan yang berbeda dari Web Components, yaitu bagaimana menyinkronkan server dan state

    • Di perusahaan, sudah sekitar setahun sejak kami mengganti React dengan Htmx, dan Web Components sangat berguna untuk menggunakan kembali komponen React yang ingin kami pertahankan seolah-olah itu widget browser native
      Dengan WebComponent, kita bisa mengaitkan diri ke lifecycle elemen DOM yang dimodifikasi dari luar, seperti morphdom milik Htmx. Ketika atribut berubah, kita perlu memberi tahu komponen React, dan ketika node dihapus dari DOM, kita perlu memberi tahu React agar menjalankan prosedur cleanup. Tanpa WebComponents, menurut saya sulit melakukan ini dengan rapi dan efisien
      Hasilnya, kami bisa tetap berada pada pendekatan Htmx: semua state logika bisnis ada di server, dan hanya sebagian kecil yang konservatif disimpan di klien, seperti elemen yang sedang fokus atau teks yang sedang diketik. Semakin kami bergerak ke arah ini, bug dan race condition berkurang, pengalaman pengguna menjadi jauh lebih baik, sehingga layak untuk diupayakan
    • Saya penulisnya, dan karena tampaknya kalimat itu ditafsirkan berbeda dari maksud saya, saya akan menghapusnya. Di Twitter juga saya menulis bahwa Web Components secara alami cocok dengan scripting yang ramah hypermedia seperti yang Anda jelaskan dalam tulisan Anda, dan saya cukup menyukai tulisan itu
      https://x.com/jlazaroff/status/1717176726248108469
      https://htmx.org/essays/hypermedia-friendly-scripting/
    • Saya berharap htmx dalam jangka panjang menjadi standar HTML itu sendiri, bukan sekadar library JavaScript sederhana
      Batasan bahwa hanya form yang bisa melakukan POST, dan satu-satunya cara menangani respons adalah menulis ulang seluruh halaman, terasa arbitrer dan terlalu membatasi. Jika htmx menjadi sesuatu seperti HTML6, ia akan bertahan lebih lama daripada semua framework JavaScript
    • Senang sekali mendengar bahwa htmx akan sangat stabil dan minim perubahan ke depannya
      Sebagai engineer yang terutama fokus pada backend, sebagian besar library JS yang saya ambil dan gunakan kemudian menjadi beban pemeliharaan besar, dan perubahan API utama juga sering terjadi. Saya berniat mencoba htmx untuk proyek pribadi
    • Saya sempat ingin menulis ulang SPA proyek sampingan saya dengan htmx. Saya tidak terlalu tertarik pada Web Components, tetapi menggunakannya bersama htmx adalah gagasan yang menarik
      Template untuk menghasilkan potongan HTML di sisi server juga sepertinya akan menjadi lebih sederhana
      Konsep htmx sendiri benar-benar meyakinkan, tetapi saya berharap komunitasnya lebih besar. Memang ini masalah ayam dan telur, tetapi dibandingkan framework web lain, materi seperti artikel blog atau video tidak banyak. Misalnya, bahkan hal mendasar seperti mengintegrasikan autentikasi Auth0 ke aplikasi htmx sulit ditemukan

  • Seluruh non.io ditulis dengan Web Components murni, dan merupakan SPA penuh. Setelah melampaui komponen blog bersarang yang sederhana, ada beberapa hal yang dipelajari
    Manajemen state masih belum punya jawaban. Jika tidak memakai framework pembungkus, banyak hal harus dikerjakan sendiri. Salah satu kelebihan React adalah manajemen state pada umumnya sudah terpecahkan, dengan pola dan ekspektasi yang sudah ada. Di Web Components rasanya seperti wilayah perintisan, dan karena tidak bisa mengoper objek kompleks sebagai atribut seperti JSX, akhirnya harus mencampur atribut, event, dan pemanggilan langsung fungsi class
    Performa juga tidak memberi keuntungan sebesar yang diharapkan. Untuk elemen atomik kecil, misalnya ikon, ketika jumlahnya ratusan di sebuah halaman, biaya pembuatan instance lebih besar daripada nilainya, jadi dikembalikan dari Web Components. Elemen statis, meski memberi keterbacaan kode, tidak layak ditulis sebagai Web Components, dan itu cukup mengecewakan
    Meski begitu, ada juga hal yang benar-benar disukai. Seperti yang dikatakan penulis, sangat mudah menambahkan komponen ke halaman baru terlepas dari framework yang digunakan. Jika dibuat sebagai Web Components, komponen itu benar-benar bisa dipakai di mana saja. Saat membuat situs pendukung seperti dokumentasi API nonio, meski stack-nya berbeda, mudah memilih komponen yang diinginkan dan memakainya, jadi itu menyenangkan. Jika perlu menyematkan komponen, cukup ambil JS dan tambahkan HTML, selesai
    Enkapsulasi style dari shadow root juga cukup bagus. Menyenangkan karena saat mengerjakan halaman tidak perlu khawatir merusak style suatu komponen. Pekerjaan menebak dan memeriksa apakah style elemen lain akan tertimpa jadi berkurang, dan kebutuhan akan framework pemeriksa perbedaan visual untuk menjamin hal itu juga berkurang
    Ukuran paket yang kecil juga bagus. Tidak ada library atau muatan tambahan, semuanya sudah bawaan. Karena mudah memilih komponen yang diperlukan saja, menjaga ukuran paket tetap rendah juga sangat mudah
    Komponen sumber nonio ada di sini: https://github.com/jjcm/nonio-frontend/tree/master/component...

    • Soal tidak bisa mengoper objek sebagai atribut, sebenarnya bisa lewat property elemen
      Untuk manajemen state juga tidak ada yang benar-benar menghalangi menghubungkan solusi manajemen state apa pun yang diinginkan. Jika tujuannya meminimalkan dependensi, saya juga cukup sering melihat solusi yang memakai model event bawaan browser
      Terakhir, menulis seluruh aplikasi dengan Web Components murni menurut saya pribadi cukup berlebihan. Dengan Lit sebesar 5KB, pengalaman developer bisa jauh lebih baik: https://lit.dev
    • Apakah performa memang menjadi keuntungan? Saya memperkirakan performanya lebih buruk dibanding memakai framework web umum seperti React, Vue, Svelte, dan sebagainya
      Framework semacam ini biasanya mendapatkan performa dengan mem-batch manipulasi DOM di seluruh halaman, sedangkan Web Components tidak bisa melakukannya
      Dengan alasan ini saja, menurut saya Web Components hampir seperti jalan buntu. Mungkin berguna ketika hanya membutuhkan pulau fitur kecil, bukan halaman yang sepenuhnya dirender di client
    • Saya penasaran apakah masalah performa juga ada pada Web Components yang tidak memakai shadow DOM
      Saya juga melihat batasan performa yang mirip, tetapi selalu mengira itu karena shadow DOM berat. Sekarang saya jadi penasaran apakah pembuatan instance itu sendiri yang berat
      Untuk manajemen state saya merasakan masalah yang sama, dan sedang mempertimbangkan mencoba pendekatan yang meminjam ide dari pengembangan desktop: menyediakan message bus tingkat jendela, lalu semua komponen melakukan subscribe dan filtering, serta memublikasikan semua perubahan state ke message bus tersebut
    • Objek kompleks bisa diteruskan sebagai atribut seperti di JSX
      Contoh mengoper objek kompleks sebagai atribut bisa dilihat pada zx-listeditor di sini:
      https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
      Web Component-nya sendiri ada di sini:
      https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
      Library kecil 500 baris yang memungkinkan hal ini ada di sini:
      https://github.com/wisercoder/uibuilder/#jsx-for-web-compone...
    • Karena manajemen state di Web Components disebut sebagai masalah yang belum terselesaikan, saya membagikan proyek yang menargetkan solusi untuk itu: https://github.com/launchscout/live_state
      Pola dasar LiveState adalah “dispatch event, subscribe ke state”. Event dan pembaruan state dikirim melalui koneksi WebSocket, dan library frontend serta backend adalah lapisan tipis di atas Phoenix Channels
      Saat ini fungsi event handler ditulis dalam Elixir, tetapi pekerjaan sedang berlangsung agar bisa ditulis dalam bahasa apa pun yang dikompilasi ke WebAssembly

  • Saya tidak berharap framework JS favorit akan tetap sama terus. Saya tahu umurnya pendek, dan saya justru menyukai itu
    Alasan memakai React, Vue, Svelte, dan sebagainya adalah untuk bergerak maju, membuat kemajuan, dan melakukan perbaikan. Saat ini saya tidak menginginkan sesuatu yang statis. Karena di antara framework yang bisa dipakai sekarang, termasuk Web Components, tidak ada yang menyelesaikan masalah dengan sangat elegan
    Kalau klaimnya adalah situs yang dibuat dengan Web Components akan bertahan lebih lama daripada situs yang dibuat dengan framework JS, saya ingin bertaruh. Terus terang, menurut saya dalam 20 tahun ke depan kemungkinan sebagian dari stack teknologi Web Components dihapus dari Chrome, Safari, dan Firefox hingga merusak aplikasi lebih besar daripada kemungkinan aplikasi React 16 yang ditulis 2 tahun lalu rusak karena perubahan JavaScript

    • Taruhan itu kemungkinan besar bisa Anda menangkan, tetapi sepertinya syaratnya dibuat hampir tidak bermakna
      Jika semua versi dependensi aplikasi React 16 dikunci sepenuhnya, mungkin ia tidak akan rusak. Namun itu lebih mirip menjalankan program lama di VM atau emulator daripada “masih bisa terus mengerjakan dan mengutak-atik aplikasi React 16”
      Taruhan yang lebih bermakna adalah “bisakah kita terus mengembangkan aplikasi React ZZZ vs bisakah kita terus mengembangkan aplikasi yang dibuat dengan Web Components”
      Kalau saya menetapkan syarat dengan cara yang lebih menguntungkan sudut pandang saya tetapi tetap lebih bermakna, bunyinya akan menjadi: “apakah biaya memperbarui aplikasi React untuk mengejar pembaruan dependensi selama N tahun lebih besar atau lebih kecil daripada aplikasi Web Components.” Jika aplikasi Web Components tidak diisi banyak dependensi aneh, saya rasa kemungkinan besar biaya pembaruan di sisi aplikasi React akan lebih besar
      Pada dasarnya ini adalah bertaruh bahwa vendor browser akan lebih jarang merusak kompatibilitas ke belakang dibanding para penulis React
    • Hal seperti itu sudah pernah terjadi
      HTML Imports dihentikan karena solusi khusus JS lebih disukai, dan Firefox bahkan sudah mengimplementasikannya
      Custom Elements v0 juga dihentikan; Chrome mengimplementasikannya, dan YouTube sempat buru-buru ditulis ulang dengan itu. Karena YouTube butuh waktu selama itu untuk beralih, penghapusan implementasinya harus menunggu sekitar 4 tahun
    • Menurut saya, jika menjalankan kode lama dan tidak memperbarui dependensi, situs bisa terekspos pada kerentanan keamanan yang ditemukan seiring waktu dan diperbaiki di versi library baru
      Untuk menjaga kode tetap aman, library harus diperbarui. Namun versi lama library akan berhenti didukung, dan kerentanan yang diketahui tetapi tidak bisa diperbaiki mulai menumpuk. Penyerang kemungkinan besar punya program yang memindai situs web dengan kerentanan yang diketahui dan melakukan serangan otomatis
      Sebaliknya, jika memakai library atau platform seperti Web Components yang mementingkan kompatibilitas ke belakang, kode lama bisa didukung lebih lama sambil tetap menjaga keamanan

  • Saya jadi lebih berfokus pada orang daripada teknologi
    Jika memulai proyek baru, saya lebih dulu melihat apa yang diketahui orang-orang yang akan mengerjakan proyek itu. Kalau ada denominator umum atau praktik terbaik, seperti React di frontend saat ini, saya langsung memakai itu
    Saya tidak terlalu pusing dengan keputusan teknis semacam ini. Komposisi tim, pasar pencari kerja, dan peringkat teknologi di StackOverflow dengan mudah menjawab pertanyaan seperti itu

    • Saya memahami pendekatan itu dan menganggapnya praktis
      Namun jika semua orang berpikir begitu, kita akan selamanya memakai React meskipun ada jawaban yang lebih baik untuk membuat perangkat lunak. Memakai sesuatu yang populer berarti menggantungkan peningkatan stack teknologi kepada orang lain yang akan menemukan solusi teknis yang baik dan membuatnya populer
      Dengan kata lain, strategi ini jelas berada di sisi pengadopsi pertengahan hingga akhir dalam kurva adopsi. Banyak tulisan dan diskusi seperti ini ditujukan untuk pengadopsi yang lebih awal

  • Karena HTML bisa ditulis di dalam Markdown, gagasan bahwa diagram interaktif yang mewah pun bisa portabel seperti bagian Markdown lainnya jika dapat direpresentasikan dengan tag HTML biasa, bisa dilakukan persis sama dengan MDX
    Di sini, teknologi Web Components itu sendiri tidak benar-benar membantu. Yang dipedulikan penulis adalah antarmuka antara markup dan potongan kode yang menerapkan fungsionalitas runtime. Web Components di sini hanyalah detail implementasi. Tidak penting apakah saat menulis nama di antara kurung siku Anda merujuk ke komponen React, sesuatu dari Astro, atau Web Component. Intinya adalah ada sesuatu yang lain yang dipanggil
    Kekurangan Web Components di sini adalah pada dasarnya hanya berjalan di klien. Karena tidak ada cara untuk meneruskan isi shadow DOM yang dirender di server ke klien, meskipun Web Component sepenuhnya noninteraktif, JS klien tetap diperlukan untuk merendernya. Framework lain tidak seperti itu
    Bukan berarti poin penulisnya salah. Sebagai cara untuk menata antarmuka antar potongan kode, Web Components mungkin merupakan cara terbaik dan paling tahan lama. Namun di server, Web Components tidak membantu apa pun. Ia tidak dirender, antarmukanya merepotkan, dan kemungkinan besar kodenya sudah ditulis dengan cara yang dapat ditangani secara menyeluruh. Jika Anda memakai Astro di server, terus saja pakai Astro. Begitu juga dengan React, Vue, atau apa pun
    Tempat Web Components bersinar adalah di klien. Saat menggunakan komponen pihak ketiga yang mungkin tidak ditulis dengan framework pilihan Anda, Anda tidak perlu tahu komponen yang Anda pasang di halaman dibuat dengan framework apa. Tulis tag HTML, dan ia akan bekerja. Mekanisme antarmukanya naik ke level browser, sehingga dua framework tidak perlu mengetahui detail implementasi satu sama lain

    • Saya kira Anda hendak berargumen bahwa di server, tag tidak punya cara ajaib untuk mendapatkan HTML internalnya sendiri
      Dalam hal itu, benar bahwa dibutuhkan suatu alat. Hanya saja alat itu bisa berupa mesin template sisi server apa pun yang mengisi HTML awal untuk bootstrap
      Namun shadow DOM yang dirender di server bisa diteruskan ke klien. Ini disebut declarative shadow DOM, dan bekerja di semua browser utama kecuali Firefox. Firefox juga sedang mengerjakannya, dan ada polyfill
    • Saya ingin menegaskan bahwa atribut ini juga ada pada HTML biasa
    • Ada proposal untuk meneruskan shadow DOM yang dirender di server ke klien. Namun tidak ada yang tahu apakah ini akan bertahan dalam jangka panjang
      https://developer.chrome.com/articles/declarative-shadow-dom...
      Sebagai catatan, polyfill ini cukup mudah, jadi mungkin bisa dipakai meski browser saat ini belum mendukungnya
    • Saya suka memakai Web Components bersama alat-alat bagus yang disediakan Lit, tetapi saya setuju bahwa kurangnya server-side rendering dan hydration membuatnya kurang praktis dibanding pustaka progressive enhancement sisi server seperti Stimulus atau Alpine
      Jika Web Components yang bisa dirender di server tersedia, akan terbuka banyak kemungkinan untuk membuat pengalaman pengguna pada aplikasi multi-halaman menjadi lebih baik

  • Dunia JS masih terlalu terpaku pada klien tebal yang memegang semua kendali, sehingga melewatkan hal-hal menarik yang terjadi di dunia server
    Solusi seperti Rails Hotwire, Phoenix LiveView, dan Laravel Livewire dapat menyelesaikan 80% kebutuhan frontend dengan JS minimal dan kompleksitas pengalaman pengembang yang nyaris tidak ada

    • Bukankah mungkin juga frontend dan backend sama-sama matang dan menjadi lebih kuat? Bukankah itu yang kita inginkan?
      Saya pernah membuat aplikasi frontend kaya fitur yang membaca dan menulis ke database serta object storage tanpa server. Portabilitasnya sangat baik, dan tahap instalasinya hanya mengunggah beberapa file. Bisa dijalankan langsung dari CDN sederhana dan sangat cepat
      Sebagian besar pengembang frontend yang saya kenal juga tahu keluarga Hotwire, tetapi bagi mereka stack seperti itu justru menambah kompleksitas pengalaman pengembang. Kadang orang mengatakan “kompleksitas”, padahal sebenarnya yang dimaksud adalah “ketidakakraban”. Frontend dan backend sama-sama bisa menjadi terlalu kompleks, tetapi tidak harus begitu
    • Kompleksitas harus ada di suatu tempat. Entah berada di tangan engineer, atau disapu ke bawah karpet agar framework bisa melakukan keajaibannya. Ini terutama mengingatkan saya pada ekosistem Rails
      Saat ada yang tidak beres, menurut saya lebih baik punya lebih banyak kendali. Terutama dalam lingkungan serbacepat ketika klien menuntut sesuatu sekarang juga
    • Pilihannya antara menulis HTML di dalam JavaScript, atau menulis JavaScript di dalam HTML
      Secara pribadi, saya lebih memilih menulis semuanya dengan JavaScript/TypeScript daripada menaburkan gula sintaks di atas HTML
    • Bukankah ini ruang trade-off yang sama, soal seberapa tipis UI dibiarkan, yang sudah dieksplorasi sejak awal UI?
      Menaruhnya di sisi server seperti Livewire tidak membuat kelemahan kuat seperti latensi menghilang
    • Saya juga ingin belajar lebih banyak tentang Inertia di sisi Laravel, tetapi sebagai pengembang Laravel, Livewire terasa luar biasa produktif, terutama ketika dipakai bersama Filament

  • Judulnya mungkin benar, tetapi saya tidak tahu apakah itu penting. Sebagian besar aplikasi tidak hidup selama itu
    Baru-baru ini saya mencoba Web Components, dan fitur yang sangat sederhana di framework mana pun ternyata sangat membingungkan dan rumit untuk disiapkan. Jika komponennya sederhana, mungkin tidak masalah, tetapi jika membuat aplikasi dengan JS, slot adalah fitur inti karena memungkinkan pembuatan komponen yang dapat dikomposisikan
    Men-debug shadow DOM di developer tools juga benar-benar membingungkan

    • Beberapa hal hampir mustahil dibuat bekerja dengan benar tanpa MutationObserver atau polyfill-nya
      renderProp di React atau scoped slot di Vue sangat umum dipakai untuk menyuntikkan data dari komponen induk ke komponen anak. Namun mereproduksi perilaku seperti itu di Web Component pada dasarnya mustahil tanpa hack MutationObserver. Asumsi Web Component bahwa komponen anak dan induk tidak perlu saling mengetahui informasi tidak cocok dengan dunia nyata
      Asumsi bahwa komponen anak selalu dimuat dan diinisialisasi terlepas dari induknya juga keliru di sebagian besar framework. Di sebagian besar framework, komponen induklah yang memutuskan apakah anak benar-benar akan dimuat atau diinisialisasi

  • Web Components mungkin lebih baik untuk membuat komponen yang terisolasi dan dapat digunakan ulang, tetapi DOM API yang dipakai untuk merangkai ini-itu agar aplikasi berjalan benar-benar buruk
    Masih terasa jelas bahwa itu dibuat untuk mengedit dokumen XML
    Ada satu alasan lagi mengapa saya tidak membuat Web Components bahkan untuk komponen yang terisolasi dan dapat digunakan ulang. Tidak ada editor yang benar-benar menangani hal seperti pelengkapan otomatis nama atribut atau event, maupun pemeriksaan typo

  • Agar berguna, kita harus merangkai berbagai dependensi, dan dependensi-dependensi itu kemungkinan tidak akan dipelihara sebaik React
    Saya pernah bekerja di perusahaan yang mengikuti filosofi seperti ini. Semua komponen UI adalah Web Component yang masing-masing punya paket npm yang harus diinstal sendiri. Memang berjalan dengan baik, tetapi sama sekali tidak ada manfaatnya. Enam tahun kemudian, manfaatnya masih belum ada. Mungkin ini berarti mengoptimalkan untuk masa depan yang tidak akan pernah datang

  • Situs HTML/CSS akan bertahan lebih lama daripada semuanya
    Karena teks, gambar, dan layout benar-benar berada di dalam sesuatu yang statis, bisa tetap hidup selamanya tanpa disentuh, dan tidak perlu menjalankan kode rumit atau mempertahankan semi-standar yang ambigu dan cepat berubah
    Jika ingin membuat situs yang awet dan memiliki teknologi yang awet, cukup pelajari cara membuat situs web HTML yang ditingkatkan secara progresif. Cara seperti Web Components yang membuat elemen HTML tak terdefinisi dengan tanda hubung yang tidak berguna lalu menjalankan banyak JavaScript untuk mendefinisikannya, atau framework JavaScript yang bahkan tidak berpura-pura memakai HTML, hanya akan bertahan beberapa tahun
    Setidaknya begitu sampai browser menghapus dukungan HTTP/1.1

    • Saya penasaran bagian mana dari Web Components yang menurut Anda tidak sesuai dengan definisi progressive enhancement
    • Saya penasaran apakah Anda melihat di mana saya memakai Web Components dalam tulisan itu. Bagaimana mungkin membuat artikel tutorial berisi demo interaktif tanpa JavaScript?