Svelte 5 bukan Javascript

 (hodlbod.npub.pro)
9 poin oleh GN⁺ 2025-02-19 | 7 komentar | Bagikan ke WhatsApp
  • Ringkasan masalah yang dialami setelah baru-baru ini meng-upgrade aplikasi web ke Svelte 5
    • Terjadi perilaku tak terduga akibat fitur deep reactivity dan perubahan lifecycle
  • Meski telah lama menikmati Svelte 3/4, ke depannya sepertinya saya tidak akan memilih Svelte untuk proyek baru

Kebutuhan akan kecepatan

  • Tim Svelte mencoba melakukan optimasi performa melalui deep reactivity, dan berhasil menghasilkan performa yang lebih baik
  • Sebelumnya pun Svelte sudah memberikan performa cepat lewat proses kompilasi, dan itu merupakan keunggulan yang membedakannya dari framework lain
  • Ini memang membuat framework menjadi kurang transparan dan sulit di-debug, tetapi terasa sebagai trade-off yang masih bisa diterima dari sisi performa dan produktivitas

Kebutuhan akan kecepatan

  • Perubahan utama yang menjadi fokus tim Svelte di Svelte 5 adalah “deep reactivity”, yaitu upaya meningkatkan performa lewat reaktivitas yang lebih granular
  • Pada versi-versi Svelte sebelumnya, tujuan ini terutama dicapai dengan memanfaatkan compiler Svelte
    • Keunikan Svelte menonjol karena pengembang tidak perlu mempelajari konsep baru secara langsung, sementara logika internal tetap bisa direstrukturisasi dengan baik
  • Namun pada saat yang sama, proses kompilasi ini juga membuat framework menjadi tidak transparan, sehingga debugging masalah kompleks menjadi sulit
    • Bug pada compiler sendiri dapat memunculkan error yang sulit dilacak penyebabnya, dan kadang hanya bisa diselesaikan dengan me-refactor total komponen yang bermasalah
  • Meski begitu, ini tetap terasa sebagai kompromi yang masuk akal dari sisi kecepatan dan produktivitas, sehingga saya pun menerima kerepotan harus me-reset proyek secara berkala

Svelte bukan Javascript

  • Svelte 5 melipatgandakan trade-off ini
  • Perbedaan intinya adalah titik kompromi antara abstraksi dan performa kini tidak lagi berhenti di tahap kompilasi, tetapi merembes ke bagian runtime
    • Penggunaan proxy untuk mendukung deep reactivity
    • Status lifecycle komponen yang implisit
  • Dua perubahan ini meningkatkan performa dan membuat API pengembang terlihat lebih slick
  • Apa yang tidak disukai? Sayangnya, kedua fitur ini dapat dianggap sebagai contoh klasik dari leaky abstraction
    • Pada akhirnya ini menciptakan lingkungan yang lebih kompleks untuk dihadapi pengembang

Proxy bukan objek

  • Dengan penggunaan Proxy, tim Svelte bisa sedikit lebih meningkatkan performa framework tanpa meminta kerja tambahan dari pengembang
    • Di framework seperti React, saat state diteruskan melalui beberapa komponen, hal itu mudah memicu re-render yang tidak perlu; Svelte memperkenalkan Proxy untuk mengurangi hal tersebut
    • Compiler Svelte sebelumnya juga sudah menghindari sebagian masalah yang bisa muncul dari proses diff virtual DOM, tetapi tampaknya mereka menilai performa masih bisa ditingkatkan lagi lewat Proxy
    • Tim Svelte juga menyebut bahwa Proxy membantu meningkatkan developer experience, dengan klaim bahwa mereka dapat “memaksimalkan efisiensi dan kemudahan penggunaan sekaligus”
  • Masalahnya adalah, Svelte 5 terlihat lebih sederhana di permukaan, tetapi sebenarnya menambahkan lebih banyak abstraksi
    • Misalnya, memakai Proxy untuk mendeteksi method array memberi keuntungan karena kita tak perlu lagi menulis kode seperti value = value seperti di Svelte 4
    • Di Svelte 4, pengembang perlu sedikit memahami cara kerja compiler untuk memicu reaktivitas. Sebaliknya, Svelte 5 memberi kesan bahwa kita bisa “melupakan compiler”, padahal kenyataannya tidak begitu
    • Seiring kemudahan yang didapat dari abstraksi baru, jumlah aturan yang harus diketahui pengembang agar compiler bertindak sesuai harapan juga bertambah
  • Selama lama menggunakan Svelte, secara pribadi saya makin sering memakai Svelte store dan makin jarang memakai deklarasi reaktif
    • Svelte store pada dasarnya lebih dekat ke konsep Javascript, cara memanggil method update juga sederhana, dan sintaks $ hanya terasa sebagai bonus tambahan
    • Proxy, seperti deklarasi reaktif, memunculkan masalah “terlihat seperti satu hal, tetapi bekerja berbeda di titik batas tertentu”
  • Saat pertama kali memakai Svelte 5, semuanya tampak berjalan baik, tetapi ketika mencoba menyimpan state Proxy ke IndexedDB, muncul DataCloneError
    • Lebih parahnya lagi, untuk memastikan apakah suatu nilai adalah Proxy, kita harus mencoba structured clone dengan try/catch, dan itu punya biaya performa yang besar
    • Pada akhirnya, kita harus terus mengingat apa saja yang merupakan Proxy, lalu memakai $state.snapshot setiap kali berada dalam konteks eksternal yang tidak mengenali Proxy
    • Akibatnya, alih-alih “abstraksi meningkatkan kenyamanan pengembang” seperti niat awalnya, situasinya justru menuntut aturan dan prosedur yang lebih rumit bagi pengembang

Komponen bukan fungsi

  • Sekitar tahun 2013, virtual DOM menjadi populer karena aplikasi bisa dimodelkan sebagai kombinasi fungsi
    • Svelte selama ini mempertahankan pendekatan memakai compiler alih-alih virtual DOM untuk menyederhanakan fungsi lifecycle dan meningkatkan performa
    • Namun di Svelte 5, konsep lifecycle ditambahkan kembali dengan nuansa yang mirip React Hooks
  • Di React, Hooks adalah konsep abstraksi yang mengurangi kode terkait state dalam method lifecycle
    • Kodenya memang jadi lebih rapi, tetapi banyak hal yang tetap harus diwaspadai pengembang, misalnya saat mereferensikan state di dalam setTimeout
    • Bahkan di Svelte 4 pun, kode asinkron yang mengakses elemen DOM saat komponen unmount bisa menimbulkan masalah
    • Kini di Svelte 5, tampaknya status implisit telah ditambahkan ke lifecycle komponen untuk mengoordinasikan perubahan state dan effect
  • Dokumentasi resmi tentang $effect menjelaskannya sebagai berikut:
    > “$effect dapat ditempatkan di mana saja, tetapi harus dipanggil saat inisialisasi komponen (atau selama parent effect aktif), dan akan hilang saat komponen (atau parent effect) di-unmount”
  • Ini mengisyaratkan bahwa, berbeda dari penjelasan bahwa lifecycle hanya memiliki dua tahap mount/unmount, sebenarnya ada struktur effect yang kompleks yang perlu melacak perubahan state
  • Dokumentasi lifecycle resmi mengatakan “before update/after update tidak ada”, tetapi konsep baru seperti $effect.pre dan tick tetap muncul
  • Itu pada dasarnya berarti bahwa selain mount/unmount, kita tetap perlu memahami timing perubahan state
  • Bagian yang benar-benar menimbulkan masalah saat digunakan adalah bahwa state yang diteruskan ke fungsi yang tidak terkait dengan Svelte pun tetap terikat pada lifecycle komponen
  • Misalnya, saya menggunakan pola mengelola modal window lewat store sambil meneruskan callback ke komponen anak 
    const { value } = $props()  
const callback = () => console.log(value)  
const openModal = () => pushModal(MyModal, { callback })
  • Jika kode ini berada di dalam komponen modal, komponen yang memanggil modal bisa lebih dulu di-unmount, dan pada saat itu value berubah menjadi undefined
  • Di repositori tersebut sudah ada contoh reproduksi minimal
  • Artinya, props yang dirujuk oleh callback yang masih hidup setelah lifecycle komponen berakhir bisa tiba-tiba menjadi undefined
  • Ini adalah perilaku yang berbeda dari Javascript dasar, dan membuat Svelte terlihat seperti melakukan sesuatu yang mirip garbage collection sendiri
  • Mungkin ada alasan engineering di baliknya, tetapi tetap terasa mengejutkan karena tidak terduga

Kesimpulan

  • Hal yang mudah memang jelas menarik, tetapi seperti kata Rich Hickey, mudah tidak berarti sederhana
  • Seperti kata Joel Spolsky, saya tidak suka ketika perilaku tak terduga terjadi
  • Svelte selama ini telah menunjukkan banyak “sihir”, tetapi di versi kali ini, hal-hal yang harus dihafal untuk memakai sihir itu bertambah banyak sehingga bebannya terasa lebih besar daripada manfaatnya
  • Inti tulisan ini bukan untuk menyalahkan tim Svelte; saya justru menyadari bahwa banyak orang memang menyukai Svelte 5 (dan React Hooks)
  • Yang penting adalah keseimbangan antara memberi kenyamanan kepada pengguna dan membiarkan pengguna tetap memegang kendali
  • Perangkat lunak yang benar-benar baik dibangun bukan di atas “kepintaran”, melainkan “pemahaman”
  • Seiring berkembangnya alat AI, penting untuk memilih tool yang membantu memanfaatkan kebijaksanaan yang sudah terakumulasi dan memperdalam pemahaman, alih-alih tool yang membuat kita tidak tahu apa yang sebenarnya sedang kita lakukan
  • Terima kasih kepada Rich Harris dan tim atas pengalaman pengembangan yang menyenangkan selama ini. Semoga tulisan ini bisa menjadi masukan yang tidak sepenuhnya meleset

Bacaan terkait

7 komentar

 
firea32 2025-02-24

Orang yang membuat proxy jadi lebih nyaman, tapi orang yang harus men-debug jadi kesal, wkwk.
 
bichi 2025-02-21

Untuk side project, solidjs adalah DX nomor satu >m< / bahagia
 
pcj9024 2025-02-20

Saya rasa karena ada alternatif seperti Svelte, React/Next.js pun bisa mendapat dorongan besar.
Pada dasarnya, Svelte adalah sebuah bahasa, jadi saya harap ini juga bisa menunjukkan dengan baik arah yang seharusnya dituju oleh bahasa untuk mendeskripsikan UI.

Saya akan memakai React.
 
iolothebard 2025-02-20

Terlalu berlebihan itu tidak baik
Menyimpang karena terlalu mendalami
Lapisan di atas lapisan
 
colus001 2025-02-20

Menurut saya, Svelte berubah aneh sambil cukup banyak terpengaruh oleh React dan terutama Next. +page sulit dipahami kalau dilihat tanpa mengenal Svelte, dan rune seperti $state, $derived terasa seperti mengikuti React; malah rasanya zaman ketika cukup menaruh $: di depan variabel masih lebih baik. Sintaks lama seperti {#each a in array} {/each} masih bisa ditoleransi, tetapi tetap merepotkan. Kalau peningkatan performa dari reaktivitas opsional yang dicari, menurut saya SolidJS jauh lebih mengarah ke jalur yang lebih baik. Karena memakai JSX apa adanya, perpindahan dari React juga relatif lebih mudah. Sampai terasa aneh bahwa SolidJS relatif tidak mendapat banyak perhatian.
 
xiniha 2025-02-19

Sepertinya Signals sedang menuju Trough of disillusionment dalam Gartner hype cycle 🤔 Dengan use case yang makin terbentuk, saya rasa penilaiannya bisa membaik secara bertahap
 
GN⁺ 2025-02-19
Komentar Hacker News

  • Awalnya saya tidak terlalu tertarik dengan runes. Namun, saya berubah pikiran ketika saya bisa mengimpor komponen eksternal yang reaktif ke dalam template .svelte dan mengenkapsulasi reaktivitas secara internal. Artinya, kita bisa menulis pengujian vitest sambil tetap mendapatkan manfaat reaktivitas. Ini benar-benar kuat, dan setahu saya, unik di dunia frontend

    • Sebagian besar pengembang frontend sama sekali tidak melakukan testing. TypeScript adalah alat yang dipakai orang untuk menjamin ketepatan, dan memang ada alasannya. Namun, pengguna Svelte selalu punya pandangan yang agak sempit terhadap TypeScript, dan itu juga ada alasannya
    • Secara pribadi saya lebih suka menulis kode frontend yang bisa diuji, dan Svelte 5 terasa revolusioner dalam hal itu. Reaktif di browser, tetapi tetap sebagus unit test
    • Setelah mengatakan semua ini, postingan blog itu memang mengatakan kebenaran. Menambahkan proxy terasa sangat tidak nyaman. React dan Vue kehilangan saya saat mereka mulai menambahkan abstraksi di atas abstraksi, dan proxy adalah titik mulainya
    • Fakta bahwa Svelte 5 bukan JavaScript adalah <i>alasan saya menyukai Svelte 5</i>
    • Saya rasa ada dua cara utama yang masuk akal untuk melakukan frontend/web
        1. HTML statis atau template yang dirender di server, mungkin HTMX
        1. Bahasa/platform yang dikompilasi ke JavaScript. Minimal TypeScript, tetapi karena saya pikir HTML dan CSS sebenarnya sudah cukup bagus, maka JSX, React, Tailwind, dan sebagainya <i>dikecualikan</i>, dan Svelte 5 serta beberapa framework lain benar-benar merupakan peningkatan dibanding TypeScript vanila
    • Svelte 5 adalah pemenang yang jelas di kategori 2
    • Ia punya template HTML yang bagus, propagasi state yang mudah dan masuk akal, serta kemampuan untuk menulis kode modular dengan mudah. Bekerja baik dengan CSS, sering memungkinkan membuat aplikasi dan alat sederhana sekali pakai dalam satu atau dua file, dan juga mampu menangani aplikasi yang lebih besar dan serius. Lebih sedikit sihir dan kejutan dibanding Svelte 4, dan sejujurnya menyenangkan untuk dipakai. Syukurlah saya tidak peduli soal IndexedDB
    • Saya benar-benar tidak tahu alasan untuk menulis satu baris JavaScript pun saat ini, tetapi ya terserah masing-masing

  • Saya sedang aktif mengembangkan aplikasi SvelteKit yang sudah didistribusikan secara komersial, dan ingin membagikan pendapat saya tentang pengalaman tersebut

    • Hal yang awalnya menarik saya ke SvelteKit adalah kesederhanaannya. Setelah menyiapkan proyek, saya bisa mengerjakan satu file HTML/JS/CSS pada satu waktu sambil tetap menikmati manfaat framework modern tanpa kerumitannya. Itu mengingatkan saya pada masa awal pengembangan web, ketika semuanya berjalan hanya dengan meletakkan file HTML di server Apache
    • Namun, mengecewakan melihat Svelte menjauh dari paradigma sederhana itu. Sejak awal, Rich Harris menjual kemudahan penggunaan dan kesederhanaan Svelte sebagai nilai utamanya. Versi SvelteKit saat ini tidak buruk, tetapi saya lebih menyukai versi sebelumnya. Saat itu saya tidak perlu berurusan dengan struktur routing seperti +page. Saya bisa menaruh file Svelte di mana saja yang saya mau, dan semuanya dirender dengan mulus sambil tetap mendapatkan manfaat framework modern
    • Perubahan ini menambahkan kompleksitas yang sebelumnya tidak diperlukan, dan berpotensi menjauhkan Svelte dari daya tarik awalnya. Saya memilihnya berdasarkan apa yang saya kenal sebelumnya

  • Sayang sekali EmberJS menghilang. API-nya cukup stabil selama 10 tahun terakhir. Ironisnya, orang yang menulis aplikasi EmberJS selama 10 tahun terakhir mungkin akan lebih sedikit kesulitan saat migrasi dibanding orang yang melakukan hal yang sama dengan React, Svelte, Vue, dan lain-lain

    • Sayangnya, tim Ember membuat beberapa keputusan aneh di awal, dan itu tidak mudah dipahami dibanding JavaScript biasa (sebagian besar sekarang sudah diperbaiki)
    • Apakah sesuatu itu JavaScript atau bukan, menurut saya tidak terlalu penting dibanding stabilitas API
    • Secara pribadi, masalah JavaScript adalah ia terlalu sering berubah

  • Dua tautan Github yang dicantumkan penulis di bagian atas postingan mengarah ke masalah yang sama, dan masalah itu punya solusi (gunakan $state.raw)

    • Saya sudah menjadi penggemar Svelte sejak mungkin versi 2 atau 3. Karena ini adalah hal terdekat dengan menulis HTML/CSS/JS vanila sambil tetap mendapatkan manfaat framework (dan memakai Sass serta TypeScript). Luar biasa
    • Svelte 5 awalnya terasa mengkhawatirkan bagi saya karena runes terlihat aneh. Setelah meng-upgrade proyek dan mengerjakan proyek lain, ternyata tidak seburuk itu. Svelte 5 tidak mengizinkan kita mencampur cara lama dan cara baru dalam menangani state, dan pesan error-nya sebagian besar informatif
    • Saya melihat orang di komentar ini bilang htmx dan JS vanila secara objektif lebih baik... ya tidak juga? Mungkin untuk pekerjaan yang Anda lakukan, iya. Secara pribadi, Svelte masih jauh lebih mudah dipahami daripada React. Bagi orang yang peduli benchmark, Svelte secepat SolidJS (pengguna React tampaknya bisa beralih ke Solid dengan cukup mudah, sintaksnya terasa mirip)

  • Svelte 5 bukan JavaScript dengan cara yang <i>paling buruk</i>. Ia tidak menyelesaikan masalah js, hanya memberikan abstraksi yang bocor untuk beberapa masalah frontend. Saya pikir Solid adalah arah yang lebih baik daripada Svelte. Solid tidak bergantung pada bahasa baru. Namun, ada dorongan alami untuk membuat sesuatu yang bukan js karena js memang tidak ideal. Elm adalah pendahulu svelte. Tetapi saya rasa kita bisa membuat sesuatu yang lebih baik...[0]

  • Saya mulai menggunakan Svelte 5 karena saya benar-benar tidak suka store di Svelte 4. Saya memakai Sveltekit dan Svelte 5 untuk proyek baru, dan harus saya katakan... produktivitas React masih belum terkalahkan, meskipun secara teknis teknologi Sveltekit dan Svelte lebih baik

    • Beberapa hal yang sangat mengganggu: semua halaman dinamai +page.server.ts atau +page.svelte atau variannya, sehingga sulit mencari kode dengan mudah. Tooling Svelte terpisah dari tsc dan ESLint, jadi lebih sulit diintegrasikan ke CI dan digunakan saat development
    • Ada juga masalah kompatibilitas mundur yang aneh. Misalnya, kebanyakan paket Svelte masih memakai store, jadi kita harus berjuang dengan dua dunia versi, dan menulis kode kadang jadi sangat membingungkan. Selain itu, Svelte HMR masih terasa seperti tahap awal, jadi saat modul Svelte dimuat ulang, state bisa berantakan
    • Saya benar-benar ingin menyukai Svelte. Rendering-nya cukup cepat dan saya suka ide di baliknya. Tetapi produktivitas React tidak tertandingi

  • Agak aneh mengatakan Svelte bukan JavaScript hanya karena perilaku tak terduga saat meneruskan closure dalam callback. Judul yang lebih baik mungkin adalah "Saya tidak suka Svelte 5 karena ia mengejutkan saya"

  • Jika Anda mencari library untuk membangun komponen dan aplikasi yang bisa memakai JavaScript murni, coba lihat Lit: Lit

    • Ada paket tambahan untuk signal demi reaktivitas mendalam, dan paket itu menargetkan integrasi dengan proposal Signals TC39 yang akan datang: Signals
    • Lit dipakai di aplikasi besar seperti Photoshop, Reddit, Home Assistant, dan The Internet Archive

  • Ingin pengalaman frontend yang masuk akal? Gunakan Javascript vanila, web components, htmx, Blazor

    • Framework JS itu, entah kenapa, kegilaan