Semua Orang Heboh Soal Signals — Saya Belum Mau Rewrite Stack React Saya

Kalau kamu follow frontend Twitter atau baca cukup banyak newsletter JS, kamu pasti udah liat framing-nya: signals menang perang framework, dan React itu satu-satunya yang masih ngotot re-render sama useMemo masih fine-fine aja. Solid udah pake signals dari hari pertama, runes-nya Svelte itu signals dengan ergonomi lebih enak, sistem reaktivitas Vue diem-diem udah signals-shaped dari lama, bahkan Preact sekarang punya package signals sendiri. React masih ngelakuin re-render top-down yang direkonsiliasi lewat virtual DOM, dan pitch dari kubu signals bilang ini basically arsitektur lawas.

Saya bikin kebanyakan internal tool klien pake React + Spring Boot, jadi ini bukan debat abstrak buat saya — ini pertanyaan beneran soal apakah stack default saya diam-diam jadi hal yang orang mesti minta maaf kalau masih pake. Saya habisin sebagian tahun ini baca argumennya beneran dan ngoprek Solid sama Svelte di side project kecil, bukan cuma reaksi ke hot take. Kesimpulannya: belum mau pindah. At least belum sekarang.

Yang beneran dibenerin sama signals itu nyata

Pitch intinya emang bagus: daripada komponen re-render terus React nyari tau apa yang berubah lewat diff virtual DOM, signal ngelacak persis bagian DOM mana yang bergantung ke dia dan cuma update itu, tanpa ngejalanin ulang fungsi komponen di sekitarnya sama sekali. Saya bikin dashboard kecil di Solid khusus buat ngerasain ini, dan di halaman dengan banyak widget yang update independen, bedanya kerasa — nggak perlu memo, nggak perlu useCallback bungkus tiap prop, nggak perlu debug kenapa child re-render padahal props-nya nggak berubah. Kalau saya mulai proyek dari nol dengan performa sebagai constraint utama, itu poin beneran buat Solid, bukan sekadar hipotetis.

Tapi banyak “React butuh useMemo di mana-mana” itu masalah skill, bukan arsitektur

Kebanyakan re-render pain yang saya liat di codebase beneran — termasuk yang saya warisin dari client — bukan model rekonsiliasi React yang gagal. Itu komponen yang kelewat luas, state yang ditaruh terlalu tinggi di tree padahal nggak perlu, context provider yang bungkus hal-hal yang nggak perlu reaktif ke context itu sama sekali. Saya benerin cascade re-render yang jelek di proyek klien beberapa bulan lalu bukan dengan pake library signals, tapi dengan misahin satu komponen overload jadi tiga komponen lebih kecil dan mindahin satu state lokal ke lebih bawah bukannya biarin di atas.

Itu masalah React yang kamu belajar buat dihindarin, bukan masalah yang secara arsitektur nggak bisa dibenerin. Signals bikin kelas kesalahan itu lebih susah dilakuin secara default — win ergonomi yang legit — tapi itu beda sama React nggak bisa nyelesain itu.

Yang beneran nahan saya di React: matematika hiring, bukan performa

Buat freelancer solo yang ambil kerjaan klien, stack saya harus bisa dimaintain sama hire client di masa depan tanpa saya, dan bukan stack di mana saya satu-satunya orang di planet ini yang pernah nyentuh state library spesifik yang project Solid atau Svelte itu bergantung buat apapun di luar yang basic. Ekosistem React lebih gede, lebih berantakan, lebih dibebanin legacy dibanding Solid — tapi keberantakan itu dateng bareng sepuluh tahun “seseorang udah pernah nyelesain masalah persis ini” yang beneran saya andelin terus. Tiap kali saya butuh sesuatu yang obscure di project client, selalu ada jawaban React, library yang ke-maintain, thread Stack Overflow dari tiga era ekosistem yang beda. Jawaban Solid buat masalah yang sama seringnya “ini caranya kalau mau, cuma kita belum butuh library buat itu karena komunitasnya masih lebih kecil.” Bukan nyinyirin kelebihan teknis Solid. Itu pernyataan soal seberapa besar value “membosankan tapi terbukti” buat proyek client yang mungkin bakal saya handoff setahun lagi.

Tim React sendiri jelas tau tekanan ini ada, sih — kerjaan compiler yang lagi dikerjain (otomatis memoize apa yang dulu harus dimemoize manual) itu pengakuan diam-diam kalau tarian useMemo/useCallback manual emang nggak pernah dimaksudin permanen, cuma stopgap. Kalau itu matang sampai kebanyakan manajemen re-render manual ilang tanpa ganti arsitektur sama sekali, banyak framing signals-vs-React berhenti penting, karena komplain beneran-nya — React bikin kamu mikirin re-render terus — keselesein tanpa ada yang nulis ulang apapun. Saya perhatiin itu lebih ketat dibanding pertumbuhan Solid.

Yang beneran bisa ngubah pikiran saya

Project client dengan requirement UI real-time yang beneran demanding — puluhan widget yang update independen, bukan internal tool berat CRUD kayak kebanyakan kerjaan saya — di mana overhead re-render itu masalah terukur, bukan teoritis. Belum ketemu. Kebanyakan yang saya bikin itu form, tabel, dan dashboard di mana bottleneck-nya nggak pernah model rendering React, tapi API call di baliknya. Nulis ulang stack buat nyelesain masalah performa yang sebenernya nggak saya punya, atas janji bakal butuh nanti, itu persis premature optimization yang saya coba cegah dari klien saya buat codebase mereka sendiri.

Saya nggak nolak signals sebagai hype tanpa substansi — arsitekturnya beneran elegan dan ergonominya beneran lebih enak buat masalah spesifik yang dia selesein. Saya cuma nggak mikir “beneran lebih bagus di satu hal spesifik” itu sama dengan “hal yang semua orang harus nulis ulang stack-nya buat itu,” dan buat jenis kerjaan yang beneran bayarin tagihan saya, stack yang membosankan dengan ekosistem lebih gede masih taruhan yang lebih bagus.