- Saat ini, adopsi React terjadi sebagai pilihan default, bukan karena keunggulan teknis, dan hal ini memperlambat inovasi di ekosistem frontend
- Banyak tim memilih “React yang semua orang kenal” tanpa mempertimbangkan batasan proyek, sehingga efek jaringan lebih menentukan keputusan arsitektur daripada kecocokan teknis
- Framework inovatif seperti Svelte, Solid, dan Qwik menawarkan model performa yang lebih baik, tetapi tertinggal dalam persaingan arus utama karena rendahnya tingkat adopsi
- React memiliki banyak keunggulan, tetapi masalah utamanya adalah pola pikir React-sebagai-default yang memperbesar biaya peluang dan menutup ruang untuk mempertimbangkan alternatif yang lebih baik
- Untuk ekosistem yang sehat, dibutuhkan keberagaman dan persaingan, serta pentingnya memilih framework berdasarkan batasan dan kecocokan, bukan sebagai default
Kemenangan React sebagai default dan batasannya
- React tidak lagi sering dipilih karena keunggulan teknis, melainkan diadopsi sebagai pilihan default
- Ini memperkuat kebiasaan tim menggunakan React secara otomatis tanpa mengevaluasi batasan proyek
- Framework alternatif (Svelte, Solid, Qwik) tidak dievaluasi secara layak meskipun dalam skenario tertentu memiliki keunggulan performa dibanding React
- Masalahnya bukan pada React itu sendiri, melainkan pola pikir React-sebagai-default yang menciptakan struktur yang menghambat inovasi
Plafon inovasi
- Virtual DOM milik React cocok pada 2013, tetapi kini sering menjadi overhead yang tidak perlu
- Hooks memang menyelesaikan masalah komponen berbasis class, tetapi juga memperkenalkan kompleksitas baru seperti dependency array dan stale closure
- Server Components dan React Compiler mencoba meningkatkan performa, tetapi itu merupakan cara untuk mengakali keterbatasan model React
- Sebaliknya, Runes di Svelte, granular reactivity di Solid, dan resumability di Qwik menunjukkan potensi yang lebih tinggi dengan model yang benar-benar berbeda
Utang teknis
- Memilih React sebagai default menimbulkan biaya runtime yang tidak perlu dan beban pengelolaan re-rendering
- Developer akhirnya menghabiskan waktu untuk mengurus dependency effect atau hydration alih-alih menghasilkan nilai bisnis
- Dalam benchmark, Solid menunjukkan performa update 2–3 kali lebih cepat daripada React
- Pola pikir yang berpusat pada pola React melemahkan dasar-dasar web dan memperdalam inersia arsitektur
Framework alternatif
-
Svelte: revolusi compiler
- Svelte memproses sebagian besar pekerjaan pada compile time dan menghilangkan virtual DOM
- Komponen menjadi lebih dekat dengan struktur dasar web, dan overhead saat runtime berkurang drastis
- Namun, tingkat adopsinya rendah karena persepsi bahwa “peluang kerja sedikit”
- Berbagai contoh seperti The Guardian, Wired, dan Shawn Wang membuktikan bahwa setelah mengadopsi Svelte, ukuran bundle dan waktu muat berkurang signifikan, sementara produktivitas developer meningkat
- Sebagai contoh, Shawn Wang mengurangi ukuran situsnya dari 187KB di React menjadi 9KB dengan Svelte
-
Solid: pendekatan murni pada reaktivitas granular
- Solid menghadirkan reaktivitas presisi tinggi (granular) yang dipadukan dengan sintaks JSX
- Melalui signal, Solid langsung menyentuh hanya DOM yang berubah, sehingga sepenuhnya menghindari bottleneck reconciliation
- Solid unggul dalam performa dan kesederhanaan state management
- Kasus adopsinya memang masih terbatas, tetapi pengalaman tim-tim awal menunjukkan lompatan besar dalam efisiensi maupun kesederhanaan kode
-
Qwik: inovasi resumability
- Qwik unggul dalam startup instan melalui resumability, alih-alih traditional hydration
- Hanya fitur yang dibutuhkan saat ini yang dimuat secara bertahap, dan baik state maupun kode dapat diserialisasi
- Qwik menunjukkan hasil sangat baik pada situs besar, sesi panjang, dan jaringan lambat
- Meski belum banyak dicoba banyak tim, tim yang sudah mengadopsinya melaporkan peningkatan besar pada waktu muat awal dan efisiensi sumber daya
-
Kompleksitas API React dan kesederhanaan framework alternatif
- API React mencakup konsep kompleks seperti hook, context, reducer, memoization, dan lainnya, sehingga beban kognitif developer menjadi tinggi
- Jika disalahgunakan, masalah dependency dapat memicu bug atau beban desain yang berlebihan
- Sebagai contoh, gangguan Cloudflare pada 12 September 2025 juga disebabkan oleh kesalahan pengaturan dependency array di
useEffect - Sebaliknya, alternatif seperti Svelte, Solid, dan Qwik menekankan kesederhanaan dan prinsip dasar web dengan API yang jauh lebih kecil dan terfokus
- Ketiga framework ini sama-sama memiliki keunggulan teknis yang memadai, tetapi karena budaya React sebagai default, kebanyakan bahkan tidak pernah sempat diuji
Penjara efek jaringan
- Dominasi React menciptakan penghalang yang terus menguat dengan sendirinya
- Pasar kerja hanya mencari “developer React”, dan di tiap organisasi library komponen serta kebiasaan pengembangan mengeras mengikuti React
- Para pemimpin yang ingin menghindari risiko tentu memilih React yang dianggap aman, dan lembaga pendidikan pun menyesuaikan diri
- Struktur seperti ini adalah ciri ekosistem yang kehilangan persaingan sehat
Mematahkan efek jaringan
- Untuk keluar dari situasi ini, dibutuhkan pilihan yang sadar dan disengaja
- Pemimpin teknis harus meninggalkan inersia dan menentukan arsitektur berdasarkan kebutuhan, sementara perusahaan dapat mengalokasikan anggaran pilot untuk mencoba alternatif
- Developer juga perlu mempelajari semangat dari berbagai framework, bukan bersikeras pada satu paradigma saja
- Lembaga pendidikan perlu memperbanyak pengajaran konsep yang agnostik terhadap framework, dan para kontributor open source dapat membantu menopang ekosistem yang lebih kecil
Perubahan tidak datang dengan sendirinya; perubahan harus diciptakan secara sengaja.
Checklist evaluasi framework
Untuk proyek baru, hal-hal berikut dapat dijadikan kriteria evaluasi
- Kebutuhan performa: initial load, efisiensi update, ukuran bundle, serta ada tidaknya optimasi compile time
- Kapabilitas tim dan kurva belajar: pertimbangkan pengalaman yang ada, termasuk adanya alternatif yang kompatibel dengan React seperti Solid
- Skalabilitas dan biaya kepemilikan: evaluasi biaya jangka panjang termasuk maintenance, pengelolaan dependency, dan utang teknis
- Kecocokan ekosistem: keseimbangan antara kematangan dan inovasi, serta uji pilot dan ROI pada pekerjaan non-inti
Sanggahan umum dan tanggapannya
- Kematangan ekosistem: ekosistem yang lebih tua tidak otomatis lebih cocok untuk masalah masa kini. Ketergantungan tinggi pada paket pihak ketiga justru membawa efek samping seperti beban maintenance, celah keamanan, dan bundle yang membesar. Sebaliknya, ekosistem yang lebih kecil bisa lebih fokus pada fondasi web, dan dengan kemajuan alat AI, solusi kustom dapat dibuat dengan mudah dan cepat.
- Masalah perekrutan: permintaan pada akhirnya menjadi standar perekrutan. Kekurangan kapabilitas bisa ditutup melalui pembelajaran di lapangan setelah menguji alternatif di area non-inti.
- Library komponen: lock-in dapat dikurangi sambil menjaga produktivitas melalui design system yang independen dari framework atau dengan memanfaatkan Web Component.
- Stabilitas: React sendiri juga terus berubah dengan hooks, Server Components, dan lainnya. Framework alternatif justru sering menawarkan API yang lebih konsisten.
- Perlu validasi lewat kasus skala besar: dulu jQuery juga pernah menjadi contoh global. Keberhasilan masa lalu tidak menjamin tetap relevan di masa depan.
Dampak buruk bagi ekosistem dan industri secara luas
- Monokultur React memperlambat perkembangan web itu sendiri
- Bakat dan modal terkonsentrasi hanya pada penyelesaian masalah React, sementara inovasi khas platform tertunda
- Lembaga pendidikan juga semakin menambah pembelajaran keterampilan yang tidak portabel karena kurikulum berorientasi pada kesiapan kerja instan
- Perkembangan platform web sendiri terhambat oleh jawaban “cukup pakai React”, dan kurangnya keberagaman ekosistem pada akhirnya menjadi kerugian jangka panjang bagi semua pihak
Ekosistem ideal yang bisa kita bangun
- Keberagaman adalah syarat penting bagi ekosistem yang sehat
- Inovasi lahir ketika berbagai paradigma saling bersaing dan bertukar gagasan
- Developer berkembang dengan mempelajari berbagai cara berpikir, dan platform web itu sendiri ikut maju berkat beragam tantangan dan eksperimen
- All-in pada satu framework menciptakan satu titik kegagalan. Saat batasnya tercapai, pertumbuhan berhenti dan peluang yang lebih baik ikut hilang
- Setiap proyek harus memilih berdasarkan batasan teknis dan kecocokan, dan diperlukan sikap yang tidak hanya bergantung pada React sebagai default
- Hanya keberagaman yang dapat menjamin inovasi sejati
- Sekarang saatnya berhenti menanam “benih (React)” yang sama di mana-mana, dan ikut membangun ekosistem web yang lebih tangguh serta inovatif lewat eksperimen dengan framework yang lebih beragam
- Pilihan ada di tangan kita
19 komentar
Tidak masalah jika developer junior memilih React karena nyaris tak terhindarkan, tetapi menjadi masalah ketika developer senior berhenti memikirkan alternatif lain.
Memang benar kalau React atau Java itu sudah jadi sampah kuno yang bertahan terlalu lama meski sudah ada banyak alternatif yang jauh lebih baik wkwk
Eksperimen sudah banyak dilakukan pada era kekacauan besar framework sebelumnya...
Dalam pekerjaan, tidak perlu membongkar total yang sudah dipakai selama ini, dan bahkan untuk proyek baru pun
tidak banyak orang yang setuju membuang yang sebelumnya sudah dipakai dengan baik lalu belajar dari nol dan pindah, apalagi ada juga masalah perekrutan..
Semoga Solid bisa berkembang dengan baik..... bagaimana caranya memecah monopoli React ya
Selama hampir 10 tahun terakhir, begitu banyak alat bermunculan di ekosistem FE, dan setelah melalui naik turunnya kejayaan hingga akhirnya baru sekarang agak stabil, masa mau mencoba kekacauan besar seperti itu sekali lagi..
Ini tulisan yang terlalu bias, bukan?
"Framework inovatif seperti Svelte, Solid, dan Qwik menawarkan model performa yang lebih baik, tetapi karena kurangnya adopsi, mereka tersisih dari persaingan arus utama"
Jika tidak ada standar yang konsisten untuk memahami makna kata inovasi,
sepertinya asumsi dasarnya sendiri sudah keliru.
Kalau melihat tulisan seperti ini, saya jadi merasa fokusnya bukan pada membuat produk, melainkan terlalu tenggelam dalam software engineering. Pada akhirnya semuanya kurang lebih mirip, jadi yang penting adalah membuat produknya dengan baik, tetapi tiap saat mencari framework baru dan arsitektur baru, lalu melakukan overengineering, dan karena yang ini katanya lebih baik jadi ingin ganti lagi. Menurut saya, yang penting bukan hal baru itu lebih bagus, melainkan apa pun alatnya digunakan dengan baik sampai produknya dirilis.
Memang tidak terhindarkan, karena big tech domestik merekrut dengan standar React (Next.js).
Bahkan untuk vue.js yang tergolong mayor sekalipun, posisi lowongan di big tech juga tidak banyak.
Sulit mengabaikan ekosistem... akhir-akhir ini sebagian besar library pihak ketiga atau open source yang bermunculan memang mendukung React secara resmi, tetapi framework lain hanya didukung oleh komunitas, jadi kalau ingin menggabungkan ini-itu untuk dipakai, pada akhirnya React mau tak mau menjadi pilihan yang paling aman...
Bidang apa lagi yang bereksperimen sediversifikasi frontend...
Berkat dedikasi tim pengembang React di Facebook, tantangan dalam pengembangan web app jadi jauh lebih banyak. Bukan pihak jahat.. mereka mengakhiri era php jquery.
Komentar Hacker News
Menurut saya, bukan karena React sekadar menjadi default, melainkan karena ia sangat efektif dan dirancang dengan baik hingga pada dasarnya menjadi standar, dan pada saat yang sama kini juga menjadi pihak yang disalahkan.
Klaim bahwa React memperlambat inovasi terasa sangat tidak masuk akal.
Di tengah begitu banyak framework yang sekadar ingin ikut-ikutan dan desain yang membingungkan, React pada dasarnya adalah satu-satunya pilihan yang stabil dan masuk akal.
Saya dengan rendah hati tidak setuju.
Saya belum pernah membuat aplikasi interaktif yang kompleks dengan React, hanya beberapa kali membuat situs sederhana yang sebelumnya sudah dipilihkan React oleh anggota tim.
Hasilnya, React justru jelas tidak bisa diperkecil dengan baik untuk situs sederhana.
Untuk halaman login sederhana, Anda bisa langsung menyimpan state di DOM dan mengirim nilai hanya dengan
<form>, lalu fitur tampilkan/sembunyikan kata sandi cukup dengan sedikit JS.Namun jika dibuat dengan React, ada terlalu banyak hal yang harus dipelajari seperti JSX, hooks, siklus hidup komponen, build pengembangan, packaging produksi, dan lain-lain.
Framework lain seperti Vue atau Alpine bisa dipakai secara "bertahap" dan bahkan bisa langsung dimulai hanya dengan CDN.
React juga mengklaim bersifat bertahap, tetapi karena karakteristik JSX, proses build-kompilasi itu wajib, sehingga tidak ada cara untuk langsung memulai lewat CDN di dokumentasi resminya.
Bukan berarti benar-benar mustahil, tetapi pada akhirnya Anda harus ikut mengirim compiler ke klien, jadi secara praktis itu adalah opsi terburuk.
Sebagian besar situs bukanlah Facebook, Spotify, atau Netflix (bahkan Netflix pernah mengumumkan menjauh dari React), jadi sulit setuju dengan klaim bahwa React begitu efektif dan dirancang dengan baik.
Saat React muncul 12 tahun lalu, itu benar-benar inovatif.
Tetapi tak lama kemudian muncul banyak framework serupa, dan setelah itu React berhenti menjadi pusat inovasi dan hanya bertahan di level "lumayan bisa dipakai".
Sekarang ia makin menambah boilerplate sambil berusaha menyelesaikan masalah desain Virtual DOM yang sudah usang, dan jadi kurang menarik dibanding alternatif modern.
Makna judul tulisan ini terbalik.
Kenyataannya terasa seperti "inovasi" gagal mengejar rumus resmi React, yaitu rumus kesuksesan.
Saya juga mempertanyakan seberapa besar inovasi itu benar-benar diperlukan.
Sering kali pengulangan dan penyempurnaan justru lebih baik dan lebih murah.
Saya suka tulisan ini dan sudut pandang pluralistis ala 2015~16.
Saya ingin berkata kepada tim, "ayo buat use case kecil terpisah dengan Svelte", tetapi checklist evaluasi justru bekerja kebalikan dari argumen tulisan ini.
Performa: pada 99% aplikasi, perbedaannya tidak terasa, jadi akhirnya pilih React.
Keahlian tim dan learning curve: semua orang hanya tahu React, tidak tahu Qwik dan lain-lain. Alhasil tetap pilih React.
Skalabilitas, biaya operasional: tidak ada perbedaan besar.
Ekosistem: React jauh lebih besar dan stabil. Pilih React.
Ditambah lagi, tool AI belakangan sangat mendukung React, dan para developer pun hampir otomatis belajar dengan fokus ke React.
Pada akhirnya React tak terhindarkan menjadi pilihan yang rasional.
Saya pikir web components adalah jalan keluar dari situasi oligopoli framework ini.
Semua framework selain React sangat mendukung web components, jadi jawabannya adalah memanfaatkan ekosistem komponen dan utilitas yang kompatibel tanpa perlu masing-masing membangun ulang ekosistem React versi sendiri.
Banyak orang melihat web components sebagai pesaing framework, padahal sebenarnya ia mendefinisikan antarmuka antara implementasi komponen dan browser sehingga interoperabilitas dan perakitan yang andal menjadi mungkin.
Di atas API level rendah seperti ini, inovasi dalam berbagai cara membuat komponen—tanpa build, JSX, template, sintaks kustom, compiler, dan sebagainya—serta berbagai pendekatan perakitan komponen dan manajemen state tetap bisa terus terjadi.
Kita hanya bisa mengatasi dominasi React jika bisa membanggakan hal seperti, "framework Flugle baru kami berjalan baik dengan framework apa pun dan punya tool otomatisasi yang melimpah!"
Saya juga memakai web components dengan wrapper untuk menghindari boilerplate.
Dengan cara ini saya bisa mendapatkan 80% manfaat web component dengan usaha yang sangat kecil.
GitHub terkait: ZjsComponent, lihat juga tautan diskusi HN lama (Diskusi HN).
Memang tidak sempurna, tetapi bagi saya belum ada cara yang lebih mudah dan cepat untuk membuat komponen HTML baru.
Jika tidak ada alternatif setara React Native, maka web components saja tidak cukup.
Teknologi browser belum cukup cepat untuk mencapai level aplikasi native.
Nilai terbesar React adalah kemampuannya menyatukan pengembangan GUI di berbagai platform.
Saya punya pengalaman membuat aplikasi bisnis dengan lit web components.
Cukup tidak nyaman karena semua properti harus bertipe string, dan jelas tidak bisa dibandingkan dengan library komponen yang berfokus pada real-time.
Di perusahaan besar kami, aplikasi internal wajib memakai library React terpusat.
Bukan "React karena default", melainkan "hanya React yang boleh dipakai".
Saya pikir jalan keluarnya adalah mengimplementasikan ulang library terpusat itu dengan web components agar framework apa pun bisa dipakai.
Saya penasaran apakah ada yang pernah berhasil menggunakan web components dengan baik di library UI React.
Saat membuat library komponen yang disesuaikan dengan design system tertentu, saya cukup puas bergantung pada library headless seperti RAC.
Saya paham web components bisa menjadi pelengkap, tetapi saya masih belum yakin paling cocok dipakai untuk apa dalam praktiknya.
Sebenarnya tulisan ini bukan soal performa React, melainkan bahwa "keuntungan sosial" React jauh lebih besar daripada alternatif, sehingga pilihan lain jadi sulit.
Dengan kata lain, saya setuju bahwa React menjadi pilihan default bukan karena menonjol secara teknis, melainkan karena network effect lebih berpengaruh pada keputusan daripada kecocokan teknis.
Meski begitu, bagi tim tetap ada keunggulan React yang jelas dibanding alternatif.
Dalam praktiknya, sebagian besar tim yang kompeten tahu dengan baik bahwa mereka hanya akan mengadopsi alternatif lain jika kasus mereka benar-benar luar biasa.
Saya pernah ikut menentukan tech stack di berbagai perusahaan dan startup, tetapi belum pernah mendengar orang memilih React karena "kelebihan framework itu sendiri".
Keputusannya selalu didasarkan pada familiaritas, kemudahan merekrut, dan ekosistem.
Orang sering berasumsi developer web membuat keputusan secara rasional, tetapi menurut pengalaman saya tidak begitu.
Manusia mudah dipengaruhi bias seperti “bukti sosial” dan “otoritas”.
Saya belum pernah mendengar orang berkata, "kami pakai React karena React itu bagus".
Alasannya selalu hanya "karena lebih mudah merekrut".
React memang kuat dalam menyelesaikan masalah yang kompleks.
Tetapi tidak semua masalah itu kompleks, dan menjadikan alat yang kompleks sebagai default justru menambah kompleksitas yang tidak perlu dan mengurangi fleksibilitas proyek.
Ketidakstabilan ekosistem yang harus dipelihara karena fitur lama atau fitur masa depan juga bukan masalah yang hanya dimiliki React.
Ke depan saya berharap ada arus baru yang melampaui paradigma web app generasi sekarang.
Ada alasan untuk khawatir terhadap monokultur frontend, yaitu dominasi React, tetapi yang menarik bagi saya adalah bahwa 10 tahun lalu situasinya justru benar-benar kebalikan.
Framework baru membanjiri HN setiap minggu, ada kekacauan perpindahan dari Angular 1.x ke 2.0, sampai muncul istilah "kelelahan JavaScript", jadi frontend development terasa berat sekali.
Sekarang React jelas sudah mengeras menjadi standar, dan berkat itu kita bisa lebih tenang fokus mengembangkan layanan.
Saya bukan memuja React—saya juga tidak suka hooks—tetapi saya tetap bersyukur ini bukan lagi era seperti 2015.
Menarik melihat bagaimana suasananya kini perlahan mulai berubah seiring waktu.
Saya ingat masa ketika library JavaScript butik bermunculan seperti orang gila.
Menurut saya dominasi React adalah semacam kemenangan.
Saya rasa kita perlu berhati-hati agar tidak memaksa membuang sesuatu yang sudah akrab dan stabil hanya demi konsep "inovasi" yang samar.
Saya benar-benar relate.
Dari 2009 sampai 2015 saya cukup progresif dalam membuat banyak UX browser setara aplikasi native.
Kekuatan utamanya adalah standar web dan memanfaatkannya sedekat mungkin secara langsung, lalu setelah itu saya beralih ke backend dan menyaksikan kebangkitan React dari kejauhan.
React tampak tidak efisien, dan keterbatasan JSX yang menuntut "semuanya harus berupa ekspresi" juga terasa menjengkelkan.
Meski begitu, saya tetap menilai React berjasa besar karena membawa perubahan paradigma penting dalam state management.
Peralihan dari model state lama ke aliran data immutable satu arah adalah proses yang sulit, tetapi pada akhirnya bermakna.
Meski masa itu kacau, benar bahwa React membawa inovasi dan perubahan besar pada cara berpikir tentang desain aplikasi web.
Namun jika dibandingkan dengan SolidJS sekarang, Solid menawarkan manfaat yang sama dengan bentuk yang lebih ringkas, performa lebih baik, dan jauh lebih mudah dikelola.
Ia juga memberikan JSX, server components, dan reactive state management dengan lebih baik, dan developer React pun bisa berpindah dengan mudah.
Cara berpikir tentang struktur aplikasi juga hampir sama, jadi hampir semua kelebihan nyata yang didapat dari React bisa dinikmati dalam bentuk yang lebih baik, lebih cepat, dan ukuran bundle yang jauh lebih kecil.
Tetap saja, seluruh pasar sudah terlanjur condong ke React, jadi mau tak mau kita terus memakainya.
SolidJS juga masih punya titik lemah.
Masalah terbesarnya adalah sulit mengetahui secara intuitif apakah suatu prop adalah signal atau bukan.
Sistem tipe juga tidak banyak membantu.
Di React jelas bahwa jika referensinya berubah maka tempat yang menerima prop pasti akan dirender ulang, sedangkan di Solid tidak jelas apakah perubahan itu akan teramati atau tidak.
Saya rasa kebanyakan orang puas memakai apa yang sudah mereka kenal.
Banyak developer sebenarnya tidak ingin dipaksa memakai React, tetapi pada akhirnya mereka hanya bisa memakai yang paling mereka kuasai.
Waktu itu terbatas, dan demi keluarga, hobi, serta kehidupan lain, kita perlu membuat pilihan yang efisien.
Tidak harus selalu terikat pada React.
Perusahaan saya—praktis hanya saya sendiri—juga punya framework yang kami kembangkan selama 10 tahun terakhir, dan sudah saya rilis sebagai open source dengan lisensi MIT.
Tautan Q.js
Saya ingin mendengar pendapat orang lain.
Hooks memang mengatasi kelemahan class component, tetapi sekaligus memunculkan kompleksitas baru seperti dependency array, stale closure, penyalahgunaan, dan sebagainya.
Namun masalah-masalah ini bukan semata karena hooks; pada masa komponen berbasis class dulu pun hal serupa sudah ada.
Masalah dependency array juga dulu sering muncul sebagai bug karena perubahan props atau state terlewat.
Stale closure pun terjadi persis sama pada argumen kedua
setState.Penyalahgunaan lifecycle method (
componentDidMount,componentWillMount, dan lain-lain) juga sering terjadi.Saya rasa dokumentasi seperti "gunakan Effect hanya saat benar-benar perlu" juga akan dibutuhkan pada masa lalu.
Hooks jelas berkontribusi pada perbaikan karena mengurangi kesempatan untuk melakukan kesalahan, membuat kesempatan itu lebih mudah dikenali, dan bahkan memberi peringatan.
Masalah dependency array sangat mudah diselesaikan jika memakai aturan terkait react-hook di eslint.
Memakai fast-check untuk pengujian prop sangat membantu mencegah bug saat terjadi perubahan kecil.
Komunitas JavaScript mungkin sebaiknya berhenti berinovasi selama beberapa tahun.
Inovasinya terlalu banyak tetapi hasil nyatanya kurang.
Sekarang sudah saatnya sisi browser yang mengambil peran untuk pengembangan komponen web yang masuk akal.
Kalau browser mendukung hal seperti combobox dengan dukungan backend atau date picker standar, kita tidak perlu terus-menerus terobsesi pada inovasi manajemen state untuk kontrol UI dasar seperti itu.
Saya juga merasa masalahnya adalah browser sendiri tidak lagi menjalankan peran aslinya dengan baik.
Google punya pengaruh yang nyaris monopolistik lewat Chrome, jadi di standar web pun kemajuan sulit terjadi kecuali untuk hal-hal yang diminati Google dan mau diberi sumber daya pengembangan.
Safari dan Firefox memang sedikit menjaga keseimbangan, tetapi agar bisa berkembang menjadi platform yang benar-benar berbeda, tetap perlu ada pihak yang memegang kepemimpinan dan mendorongnya maju.
Pada akhirnya kubu JS terus terpaksa mengakali semuanya seperti menyolder chip NAND, karena dukungan di level platform tidak ada—situasi yang cukup menyedihkan.
Saya merasa browser dan CSS belakangan ini terus memperbaiki atau menyelesaikan use case yang secara tradisional bergantung pada JS.
Akan bagus jika gerakan seperti ini terus meluas.
Bahkan mungkin layak mempertimbangkan memecah browser menjadi 5 atau 6 jenis seperti belanja, perbankan, sosial, dan sebagainya.
Biarkan layanan-layanan itu bersaing berinovasi hanya di backend, sementara frontend memberi pengalaman yang seragam; itu akan lebih menguntungkan pengguna.
Setiap perusahaan terus-menerus mengembangkan frontend yang pada dasarnya sama adalah pemborosan besar.
Toko sandwich seharusnya bersaing membuat sandwich yang lebih enak, bukan membuat frontend serupa demi merebut 8% pengguna yang mau memasang aplikasi.
Sebenarnya cukup mengagumkan melihat apa yang berhasil dicapai framework-framework di atas platform yang serumit ini, yaitu HTML/CSS/JS.
'Web' cocok saat ia berfokus pada dokumen/teks dan form sederhana, tetapi kini ia menjadi fondasi yang sangat tidak cocok untuk aplikasi interaktif yang kompleks.
Suatu saat nanti semuanya memang harus dibangun ulang sepenuhnya.
React menang bukan karena "yang terbaik", tetapi karena menjadi "default yang aman".
Semua orang tahu React, rekrutmen mudah, dan ekosistemnya besar, sehingga itu terasa stabil.
Akibatnya inovasi berkurang, dan alternatif yang lebih ringan seperti Svelte atau Solid bahkan tidak sempat dicoba.
React masih bekerja dengan baik, tetapi menurut saya dalam praktiknya ia lebih sering dipakai karena inersia daripada karena benar-benar paling cocok.
Saya setuju dengan pendapat penulis. Namun, inersia menggunakan React tidak sepenuhnya salah seperti yang dikatakan. Jika alternatif seperti Svelte yang disebut itu adalah iPhone 17, maka saya melihat React kira-kira seperti iPhone 15 atau 16. Dari sisi biaya dibanding manfaat, itu masih cukup layak dipakai dan belum terasa perlu diganti. Di masa kekacauan besar frontend, pilihan kita terhadap React, berbeda dengan pendapat penulis, bukanlah sesuatu yang terjadi secara sadar. Setelah mencoba berbagai hal, React terasa paling layak digunakan sehingga akhirnya terpilih. Jika di masa depan React menjadi tidak nyaman dan yang lain terlihat lebih layak, saya rasa perpindahan yang alami akan terjadi tanpa perlu sengaja menantang diri atau bereksperimen.
Melihat contoh perang standar kaset video antara VHS dan Betamax, tampaknya yang secara teknis lebih unggul tidak selalu yang dipilih pasar.
Bukankah masalah frontend justru karena terlalu banyak melakukan inovasi yang tidak perlu?
Saya cukup setuju. Ada juga sisi bahwa ketika format menjadi baku, produktivitas jelas bisa meningkat, seperti di backend ketika framework Spring Boot sampai melahirkan e-government framework, jadi saya pikir mungkin React juga sedang berubah ke arah seperti itu.
Ya, saya juga merasa makna React adalah ia telah menetapkan desain berbasis komponen dan perilaku rendering yang dipahami oleh cukup banyak orang. Namun React sendiri adalah framework tingkat rendah untuk membangun web app, jadi saya berharap setidaknya router dan form disediakan secara bawaan, dan untuk state serta effect, saya sempat berpikir bagaimana jadinya jika perbandingan mendalam didukung secara default dan logika bisa ditulis hanya dengan struktur data dan fungsi. Karena keterbatasan perbandingan dangkal di JavaScript, pada akhirnya kita jadi menulis class dengan sintaks custom hook.
Kalau dibilang low-level juga tidak terlalu... Untuk membuat form, hal yang sebenarnya bisa selesai hanya dengan memakai tag input HTML malah menuntut kita mengetahui terlalu banyak hal yang tidak perlu seperti state, JSX, serta komponen uncontrolled/controlled, dan harus menghasilkan banyak kode; saya rasa hal-hal seperti itulah yang mungkin menjadi motivasi tulisan utama ini.
Saya setuju.