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 yang lebih enak, sistem reaktivitas Vue diem-diem udah signals-shaped dari lama, dan bahkan Preact sekarang punya package signals sendiri. React sementara itu masih ngelakuin re-render top-down yang direkonsiliasi lewat virtual DOM, dan pitch dari kubu signals bilang ini basically arsitektur lawas di titik ini. Saya bikin kebanyakan internal tool yang dihadapin ke 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 beneran baca argumennya dan ngoprek Solid sama Svelte di side project kecil, bukan cuma bereaksi ke hot take-nya, dan saya belum mau pindah, at least belum sekarang.

Yang beneran dibenerin sama signals itu nyata, dan saya nggak mau pura-pura nggak gitu. Pitch intinya emang beneran bagus: daripada komponen re-render terus React nyari tau apa yang beneran 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 bedanya di halaman dengan banyak widget yang update independen itu kerasa — nggak perlu memo, nggak perlu useCallback bungkus tiap prop, nggak perlu debug kenapa child re-render padahal props aslinya nggak berubah. Kalau saya mulai proyek dari nol dengan performa sebagai constraint utama, itu poin beneran buat Solid, bukan sekadar hipotetis.

Yang konsisten diremehin sama hype-nya: berapa banyak dari “React butuh useMemo di mana-mana” itu sebenarnya masalah skill, bukan masalah arsitektur. Kebanyakan re-render pain yang saya liat di codebase beneran — termasuk codebase klien yang saya warisin — itu bukan model rekonsiliasi React-nya yang gagal, tapi komponen yang kelewat luas, state yang taruh terlalu tinggi di tree padahal nggak perlu, dan context provider yang bungkus hal-hal yang sebenarnya nggak perlu reaktif ke context itu sama sekali. Saya benerin cascade re-render yang beneran jelek di proyek klien beberapa bulan lalu bukan dengan pake library signals, tapi dengan misahin satu komponen yang 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 React yang secara arsitektur nggak bisa dibenerin. Signals bikin kelas kesalahan itu lebih susah dilakuin secara default, yang mana itu win ergonomi yang legit — tapi itu beda sama React nggak bisa nyelesain itu.

Bagian yang beneran bikin saya tetep di React bukan performa, tapi matematika hiring dan ekosistem. Buat freelancer solo yang ambil kerjaan klien, stack yang saya pake harus yang bisa dimaintain sama hire klien di masa depan tanpa saya, dan yang di mana saya bukan satu-satunya orang di planet ini yang pernah nyentuh state library spesifik yang proyek Solid atau Svelte itu ujung-ujungnya bergantung buat apapun di luar yang basic. Ekosistem React lebih gede, lebih berantakan, dan iya, lebih dibebanin legacy dibanding Solid — tapi keberantakan itu dateng bareng sepuluh tahun “seseorang udah pernah nyelesain masalah persis ini” yang beneran saya andalin terus-terusan. Setiap kali saya butuh sesuatu yang obscure di proyek klien, 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.” Itu bukan nyinyirin kelebihan teknis Solid. Itu pernyataan soal berapa value “membosankan tapi terbukti” itu beneran buat proyek klien yang mungkin bakal saya handoff setahun lagi.

Bagian di mana saya rasa kubu signals bener kalau akhirnya bakal ada yang ngalah: tim React sendiri jelas tau tekanan ini ada. Kerjaan compiler yang lagi dikerjain React — otomatis memoize apa yang dulu harus dimemoize manual sama manusia — itu pengakuan diam-diam kalau tarian manual useMemo/useCallback itu emang nggak pernah dimaksudin jadi fitur permanen, itu stopgap. Kalau kerjaan compiler itu matang sampai titik di mana kebanyakan manajemen re-render manual ilang begitu aja tanpa ganti arsitektur sama sekali, banyak framing signals-vs-React berhenti penting, karena komplain beneran-nya — bahwa React bikin kamu mikirin re-render terus-terusan — keselesein tanpa harus ada yang nulis ulang apapun. Saya perhatiin itu lebih ketat dibanding perhatiin pertumbuhan Solid, karena itu jalan yang lebih realistis buat apa yang beneran saya maintain.

Yang beneran bisa ngubah pikiran saya: proyek klien dengan requirement UI real-time yang beneran demanding — sesuatu dengan puluhan widget yang update independen, bukan internal tool yang berat CRUD kayak kebanyakan kerjaan saya — di mana overhead re-render itu masalah beneran yang keukur, bukan sekadar teoritis. Saya belum ketemu itu. 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 jenis 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.