Apakah benar ada orang yang benar-benar menyukai React?

 (jsx.lol)
1 poin oleh GN⁺ 4 jam lalu | 3 komentar | Bagikan ke WhatsApp
  • Kumpulan materi kurasi yang menghimpun tulisan-tulisan kritik tentang React dan alat-alat turunannya, disusun dalam format kutipan dari berbagai developer dan blogger
  • Banyak tulisan yang menyoroti keterbatasan struktural React seperti penurunan performa, meningkatnya kompleksitas, dan masalah hidrasi
  • Pilihan teknologi yang berpusat pada React dikritik karena lebih mengeras akibat inersia dan efek jaringan daripada kecocokan teknis, dan asumsi bahwa “semua orang tahu React” dianggap mendahului keputusan arsitektur
  • Kekhawatiran soal keamanan dan tata kelola di sekitar React Server Components dan Next.js membesar, dan CVE-2025-55182 dipublikasikan sebagai kerentanan remote code execution tanpa autentikasi dengan rating CVSS 10.0
  • Kekacauan desain API dan krisis kualitas dalam ekosistem React, serta kompleksitasnya, menyulitkan pemeliharaan jangka panjang dan pembelajaran, hingga memicu perdebatan tentang arah React mulai dari Hooks, fitur UI modern, sampai alur rilis

Gambaran situs

  • Situs kurasi dengan pertanyaan provokatif "Does anybody actually like React?"
  • Koleksi cherry-picked yang menghimpun tulisan-tulisan kritik terhadap React dan alat-alat yang dipengaruhi React
  • Menyediakan fitur langganan RSS

Kritik mendasar terhadap React itu sendiri

Masalah keamanan dan tata kelola

Masalah desain API dan kurva pembelajaran

  • Is it Time to Regulate React?

    • Kegagalan inti React diperparah oleh desain API yang membingungkan
    • Dokumentasinya plin-plan, dan perdebatan tentang cara penggunaan yang benar terus berlanjut tanpa akhir

  • I don't have time to learn React

    • Berlawanan dengan klaim bahwa React mengajarkan UI modern, pada kenyataannya React hampir tidak benar-benar menangani UI modern
    • autofocus rusak, dan custom elements tidak berjalan di luar versi eksperimental
    • Untuk memakai fitur modern seperti dialog dan popover, diperlukan useEffect
    • Karena sistem synthetic event, pengguna hampir tidak belajar perilaku DOM yang sebenarnya
    • Bukan UI modern, melainkan UI level tahun 2013

  • The React Blog Post: Reflections and Reactions

    • Sikap yang menganggap semua masalah sebagai “skill issue” dan mengatakan semuanya bisa diselesaikan dengan library eksternal terasa aneh
    • Teknologi seharusnya tetap bisa dikerjakan meski kembali setelah 3 tahun, tetapi frontend, khususnya React, tidak demikian

  • React, where are you going?

    • Dua masalah yang membuat React semakin tidak menyenangkan hari ini: ownership dan complexity
    • Ada kekhawatiran bahwa developer baru bisa merasa ciut menghadapi React

Masalah performa dan pengalaman pengguna

  • Why use React?

    • Pada dasarnya terjebak dalam pola hidrasi yang sudah terkenal buruk
    • Struktur yang menjalankan semua komputasi dengan JS di server, langsung mengirim HTML, lalu mengirim ulang JS yang sama ke klien

  • How React 19 (Almost) Made the Internet Slower

    • Setelah penolakan terbuka dan perdebatan sengit, tim React menunda perubahan tersebut

  • An even faster Microsoft Edge

    • Beralih dari React ke Web Components modern + arsitektur HTML-first
    • Memberi manfaat besar terutama bagi pengguna perangkat keras kelas bawah

  • Switching costs

    • Berharap akan ada lebih banyak keluhan tentang pengalaman pengguna yang buruk yang dipaksakan oleh React sisi klien
    • Namun, keluhan nyata hampir semuanya justru berfokus pada pengalaman developer

  • Pivoting From React to Native DOM APIs: A Real World Example

    • Sebuah tim developer beralih dari “VDOM yang terlalu dominan” di React ke DOM API modern
    • Peningkatan kecepatan dan interaksi langsung terasa

Masalah mobile dan platform

Masalah ekosistem dan komunitas

Kritik terhadap React Server Components

Kembali ke dasar dan penekanan pada alternatif

Kasus migrasi dan transisi

Arus besar secara umum dan prospek ke depan

Hooks dan paradigma alternatif

  • Why Signals Are Better Than React Hooks

    • Hooks di React sulit digunakan dengan benar, dan lebih sulit lagi digunakan dengan performa yang baik
    • Menjadi penyebab penurunan kualitas kode dan performa di banyak aplikasi

Kritik metaforis

  • What Is React.js?

    • Video yang mengibaratkan dengan Kekristenan keanehan para pendukungnya, keseriusan diri yang berlebihan, dan dokumentasi yang tak ada habisnya

Bacaan terkait

3 komentar

 
bichi 8 menit lalu

React itu cuma soal keyakinan (sesat)
 
bichi 7 menit lalu

Seperti Ant Mill //
 
GN⁺ 4 jam lalu
Opini Hacker News

  • Ada beberapa hal yang tidak saya sukai dari React. React adalah framework untuk merender HTML interaktif di layar, bukan untuk membuat pemrograman yang sangat rumit
    Pertama, React terlalu bergantung pada konsep dan istilah yang rumit. Dibandingkan dengan Vue, useEffect setara dengan watch, dan useMemo setara dengan computed
    Kedua, cara yang “terlalu pintar” seperti ini meresap bukan hanya ke istilahnya, tetapi juga ke ekosistemnya. Redux dulu mengharuskan banyak kode di banyak file hanya untuk menambah satu angka, dan terasa seperti itu karena pembuatnya menyukai konsep ilmu komputer yang canggih. Pada saat yang sama, di VueX kita tinggal menaikkan angka itu saja. Untungnya, sekarang ekosistem React punya lebih banyak state manager yang waras
    Ketiga, React tidak menyediakan alat kerja CSS secara bawaan
    Keempat, React tidak mengurus optimasi secara otomatis. Kita harus tahu kapan dan bagaimana memakai atau tidak memakai useEffect dan useMemo, dan ada banyak semacam cerita rakyat seputar optimasi React. Masalahnya, inti tujuannya justru adalah rerendering. Di Vue, framework memaksa kita memakai alat bawaannya dan di dalamnya sebagian besar optimasi sudah ditangani, jadi saya tidak pernah merasa perlu mengoptimalkan aplikasi Vue secara manual
    Kelima, cerita rakyat itu sendiri adalah masalah. API React dan “cara menulis React yang benar” sudah berubah besar berkali-kali, sehingga sampai sekarang sangat sulit membedakan mana nasihat yang masih benar dan mana yang tidak
    Pada akhirnya, React bisa diringkas sebagai sesuatu yang terlalu berfokus pada ide, ilmu komputer, dan abstraksi tingkat tinggi, dan kurang fokus pada memudahkan pembuatan HTML interaktif di layar
    Saya banyak memakai React, Vue, dan Svelte, tetapi saat memakai React saya terus harus memikirkan hal-hal yang di Vue atau Svelte sebenarnya sudah ditangani. Dari sisi performa, ketiganya mirip
    Saya juga pernah menulis soal ini dulu: https://www.brachkow.com/notes/what-i-like-in-vue/

  • Sebagai orang yang sudah mengalami semua arus utama JavaScript selama sekitar 16 tahun terakhir, dalam arti tertentu saya memang suka React
    React adalah framework JavaScript terburuk, jika tidak menghitung semua hal lain yang pernah kita coba
    Saya akan memilih React kapan pun dibanding era Angular 1. Dibanding pendekatan merakit semuanya sendiri dari nol seperti Backbone, saya lebih memilih MVC berat ala Angular 1, dan dibanding struktur sup klasik JQuery, struktur MVC minimal Backbone masih lebih baik. Pada masa itu, saya juga akan langsung memilih manipulasi DOM dan pelengkap standard library dari JQuery daripada API native
    React memang punya trade-off, tetapi kita sampai di titik ini setelah lama mengalami begitu banyak alternatif yang tidak berjalan baik

    • Saya senang memakai React, dan akan memilih React dibanding hal-hal yang datang sebelumnya. Tapi kalau kebutuhan saya hanya segitu, saya tidak akan memilih React dibanding htmx/data-star dan server-side rendering, bahkan jika ada beberapa halaman yang sedikit lebih kompleks pun tetap begitu
    • Tapi saya tidak paham kenapa orang memilih React daripada Vue. Hal yang paling membuat frustrasi adalah Vue pada akhirnya bergerak ke arah React. Struktur komponen asli Vue, yaitu template HTML, state JavaScript, dan style CSS yang ada bersama, itu sangat bagus. Cara mengambil data lewat URL di dalam komponen juga sangat intuitif
    • Setuju. Saya berpindah dari HTML cgi-bin yang ditulis manual ke JQuery, Angular v1, lalu React, dan React adalah alat yang dengan senang hati akan saya ambil. React melakukan apa yang saya butuhkan
    • React lebih baik daripada Angular, dan Vue lebih baik daripada React
    • Saya penasaran apakah Anda sudah mencoba Svelte. Saya benar-benar tidak mengerti kenapa seseorang bisa lebih menyukai React. Menurut saya satu-satunya kelebihan React adalah posisinya seperti IBM-nya frontend. Tidak ada orang yang dipecat karena memilih React

  • Tentu saja ada orang yang menyukai React. Ini bukan seperti JavaScript yang secara praktis terpaksa harus dipakai, dan bukan juga seperti React atau framework web lain dipaksakan, tetapi React tetap menang. Setidaknya itu bisa dilihat sebagai bukti bahwa React cukup disukai dibanding kebanyakan framework lain
    Sampai akhir 2010-an, keluhan umum tentang pengembangan web adalah perubahan yang terlalu cepat dan selalu ada hal baru yang harus dipelajari, dan keluhan itu memang masuk akal. Tetapi begitu monokultur React naik ke puncak, sekarang semua orang mengeluh karena itu juga. Memang tidak mungkin menang

    • Di tempat kerja saya hampir tidak pernah bisa memilih framework atau library. Hampir selalu saya melanjutkan pekerjaan yang dimulai seseorang beberapa tahun sebelumnya, atau terikat pada organisasi dengan pilihan yang ketat. Secara pribadi, saya tidak akan memilih React
      React menang karena menjadi pilihan default dan karena orang menyukai hal yang sudah akrab dengan preferensi mereka sendiri
    • React memang punya kelebihan, tetapi sering dipilih karena inersia lebih daripada karena itu alat terbaik untuk pekerjaan tersebut. Alasan seperti “semua orang memakai React jadi kita bisa memaksimalkan pool rekrutmen dan pool vendor”, atau “proyek React terlihat bagus di resume” memang berpengaruh
    • Justru saya dipaksa memakai React dan Next.js. Banyak vendor SaaS bermitra dengan Vercel, dan hanya membuka titik ekstensi ke arah itu
      Kalau ingin memakai yang lain, kita harus mengimplementasikan integrasinya sendiri, mencari proyek open source yang sudah melakukannya, atau bertanya ke AI
      Untuk proyek hobi mungkin bisa, tetapi di lingkungan kerja sulit dibayangkan
    • Saya tidak paham maksudnya tidak ada yang dipaksa memakai React. Di mana dunia baru yang indah itu, tempat orang bisa belajar Lisp lalu memakainya untuk semua hal yang diinginkan, dan budaya perusahaan sama sekali tidak memengaruhi pilihan teknologi?

  • Saya suka React. Saya juga sudah serius mencoba kubu HTMX/Hotwire
    Saya ingin membuat tombol kembali yang, jika datang dari inbox, akan kembali menggunakan browser API, dan jika tidak, akan mengarah ke tautan inbox agar posisi scroll tetap terjaga. Saya harus menghubungkan perilaku di HTML untuk memanggil fungsi kembali, lalu di controller menentukan halaman sebelumnya, kemudian menurunkan tombol kembali JavaScript-aktif atau hard link. Logikanya tersebar di 3 file
    Di React, JavaScript di dalam komponen bisa menentukan apakah halaman sebelumnya adalah inbox, lalu berdasarkan nilai itu menampilkan JSX tombol kembali atau tautan. Semuanya selesai dalam satu file. Bagi saya, cukup memodelkan satu entitas konseptual, sedangkan dengan cara lain saya harus memaksakan fungsionalitas itu ke 3 entitas berbeda
    Apakah lebih lambat? Jelas lebih lambat. Tapi tetap membuat saya senang. Jika Anda menderita karena codebase React yang berantakan di perusahaan, salahkan rekan kerja Anda. Tanpa React, pasti akan lebih buruk

    • Karena itu saya tidak suka aplikasi satu halaman React. Sepertinya selalu menemukan cara bodoh untuk merusak tombol kembali dan tombol navigasi browser
      Selain kadang untuk peningkatan form, saya akan selalu lebih memilih htmx/server rendering dan perilaku native
    • Menurut saya HTMX paling baik dipakai hanya untuk hal-hal yang terkait status data. Untuk hal seperti tombol kembali pintar yang tidak bergantung pada status resource, sebaiknya tidak dihitung di backend
      Jika mengikuti cara htmx yang direkomendasikan, Anda bisa menghubungkan tombol onclick ke JavaScript inline, atau jika tidak suka itu, memanggil fungsi seperti goBackOrInbox
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      Jika sering memakai pola seperti ini, Anda tinggal membuatnya berparameter dengan menerima path tujuan sebagai argumen
    • Menurut saya cara terbaik menyelesaikan masalah tombol kembali adalah jangan dibuat terlalu rumit, dan pastikan hanya hal yang benar-benar ingin dikembalikan saja yang masuk ke riwayat browser. Rumusan masalahnya sendiri seperti berteriak, “kalau strukturnya lebih rapi, ini jadi masalah yang tak perlu dipecahkan”
    • Pasti ada bagian rumit di sana-sini, tapi rasanya ini juga bisa dilakukan dengan Web Components, bukan?

  • Saya sudah lama menulis kode React, dan sekarang di kantor sedang mengerjakan proyek Vue besar. Dulu semua orang bilang Vue adalah pilihan yang lebih mudah dan lebih ramah di antara keduanya, tapi sekarang saya mulai melihatnya secara berbeda
    React secara elegan membuat komponen pada dasarnya hanyalah fungsi, dan di luar itu tidak banyak lagi. Kalau ekosistem Next.js disisihkan dulu, ini yang paling elegan dari apa pun yang pernah saya lihat di pengembangan frontend
    Sebaliknya, Vue terasa campur aduk. Terlihat jejak backend developer yang tidak benar-benar ingin belajar JavaScript dengan baik lalu menerima dan memujinya, dan hasilnya terasa seperti campuran canggung yang tidak menyatu rapi

    • Saya tidak pernah benar-benar paham pandangan seperti ini. Komponen React bukan sekadar fungsi, melainkan fungsi yang ditempeli konteks yang disuntikkan seperti sihir dan diakses lewat hook. Hook ini menuntut berbagai macam jaminan, dan jika itu tidak disadari, hasilnya bisa sulit di-debug. Menurut saya ini jauh dari elegan
      Saya sudah memakai semua framework utama, dan sekarang sedang membuat web app Angular besar. Di Angular, komponen diekspresikan sebagai class, template, dan style. Event listener umumnya memanggil method dari class, dan state bisa sesederhana properti pada class. Jauh lebih alami dan jebakannya juga jauh lebih sedikit. Tentu bukan nol
    • Saya penasaran sudah berapa lama Anda memakai Vue. Saya juga beberapa tahun lalu melihat Vue dari latar belakang React dan punya pikiran serupa. Tapi sekarang saya lebih memilih Vue daripada React, dan untuk proyek pribadi maupun proyek kerja, Vue yang saya pilih lebih dulu
      Pengalamannya memang agak berbeda. Ada hal-hal yang lebih mudah di React dan ada juga yang lebih mudah di Vue, tetapi fakta bahwa Vue memakai signal adalah keunggulan besar bagi saya

  • Daripada React itu sendiri, saya lebih tertarik pada pertanyaan yang lebih umum: bagaimana cara terbaik menulis UI dengan kode
    Saya penggemar React dan memakai React untuk hampir semua aplikasi web yang saya buat, tetapi masalah terbesar dan paling jelas adalah menulis UI dengan React tidak terasa senatural memakai Go untuk alat baris perintah atau Elixir untuk aplikasi real-time
    Ada bahasa yang terasa sangat alami dan nyaris tanpa friksi untuk tugas tertentu. Namun untuk UI, tampaknya belum ada yang benar-benar berhasil menaklukkannya. Swift, JSX/HTML, Svelte, atau framework populer lain sejenisnya semuanya terasa seperti sekadar mengakali masalah sampai batas tertentu. Seolah para perancang bahasa/framework pada suatu titik terpaksa memasukkan kompromi sintaks yang berantakan, aneh, atau menyakitkan demi memenuhi kebutuhan
    Antarmuka yang alami untuk UI itu bersifat visual, jadi alat seperti Figma bisa menjadi bagian penting dari solusinya. Meski begitu, rasanya masih ada yang kurang. Seharusnya ada cara yang lebih intuitif untuk mengekspresikan hal visual dalam kode. Sulit menjelaskan dengan tepat, tetapi solusi yang ada sekarang selalu terasa sedikit kurang di suatu sisi

    • Perasaan saya mirip. Saat React pertama kali muncul, saya sangat menyukainya karena dibandingkan alternatif pada masa itu rasanya nyaris sempurna
      Sampai sekarang pun saya lebih memilih React daripada hampir semua yang lain, termasuk Svelte, Vue, dan Solid. Namun belakangan saya mulai memakai Crank(https://crank.js.org/), dan itu tampak selangkah lebih dekat ke arah yang ingin saya tuju. Hanya saja sejauh ini saya baru memakainya untuk proyek main-main, jadi sulit mengatakan seberapa baik skalanya baik dari sisi performa maupun pengalaman pengembang
    • Saya sangat setuju dengan pernyataan bahwa “ada bahasa yang terasa sangat alami dan tanpa friksi untuk tugas tertentu, tetapi untuk UI belum ada yang benar-benar menaklukkannya.” Jika melihat buku-buku[1] dari awal 90-an yang membahas masalah ini, isinya masih tetap relevan sampai sekarang
      Analisis terbaik yang pernah saya lihat sejauh ini ada di tulisan Chatty, “Programs = Data + Algorithms + Architecture: consequences for interactive software engineering”[2]. Memang agak sulit dibaca, tetapi sangat layak
      Singkatnya, masalahnya adalah arsitektur, lebih tepatnya ketidakcocokan antara bahasa dan arsitektur. Gaya arsitektur panggil/kembali yang didorong oleh bahasa pemrograman “serbaguna” tidak cocok dengan arsitektur yang dibutuhkan antarmuka pengguna, bahkan cenderung berbenturan
      Saya juga menulis tentang topik ini di “Can Programmers Escape the Gentle Tyranny of call/return?”
      Pendekatan saya saat ini adalah membuat terlebih dahulu Objective-Smalltalk[4], bahasa pemrograman yang bisa mengekspresikan gaya arsitektur alternatif dengan mudah
      Dengan itu saya sekarang sedang membuat framework UI bernama interscript, yang juga mencakup HTMXNative dan berbagai elemen tambahan
      Sejauh ini tampaknya berjalan cukup baik
      [1] Contoh: “Languages for developing user interfaces” oleh Myers dkk. https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • Sebagai engineer, mudah melihat setiap masalah dan berpikir, “pasti ada solusi sempurna, kita hanya belum menemukannya”
      Namun seiring waktu, saya jadi menerima jawaban yang tidak terlalu idealistis. Mungkin memang tidak ada solusi seperti itu. Ruang masalahnya mungkin terlalu kompleks, sehingga tidak ada solusi umum yang secara manusiawi mungkin dan bisa mencakup semua bentuk. Jika ada satu bidang di mana itu benar, mungkin bidang itu adalah UI

  • Betul. React adalah antarmuka paling intuitif sejauh ini yang berhasil menggabungkan gaya deklaratif dan imperatif. Di antara framework UI dari semua bahasa, menurut saya tidak ada yang mendekati JSX

    • Banyak platform lain seperti Flutter, SwiftUI, dan Jetpack Compose telah mengimplementasikan React sebagai semacam framework UI mereka sendiri
    • Kalau memang seintuitif itu, saya tidak tahu kenapa hampir semua aplikasi React mengandung bug performa

  • Saya sangat menyukai Svelte, dan untuk aplikasi yang lebih kompleks saya memakai SvelteKit
    Dalam banyak kasus yang dulu mungkin akan saya kerjakan dengan React, ini terasa sebagai peningkatan yang jauh lebih baik
    Svelte tampaknya jauh lebih mudah dipelajari bagi orang yang sudah memahami dasar-dasar pengembangan web, HTML, CSS, dan JavaScript. Namun belakangan saya sering melihat orang memulai pengembangan web dengan React, dan urutannya terasa agak terbalik
    Secara pribadi saya membuat aplikasi mobile dengan SvelteKit + Capacitor, dan konfigurasi saya tulis di sini: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    Untuk landing page sederhana, saya lebih memilih Astro

    • Saya juga selalu mengambil Svelte + SvelteKit lebih dulu. Memakai Kit untuk aplikasi sederhana mungkin berlebihan, tetapi menyenangkan punya itu saat kompleksitas tak terduga muncul
      Saya setuju bahwa sekarang banyak orang memulai pengembangan web dengan React dan itu terasa terbalik. Svelte menangani HTML seperti bahasa ibu, jadi cukup efektif mencegah masalah ini. Kalau mulai belajar pengembangan web dengan Svelte(Kit), kemungkinan besar orang akan mempelajari lebih banyak dasar dibanding jika memulai dengan React
    • Bagi saya kombinasi Svelte + Astro yang paling pas. Sangat bagus untuk situs dokumentasi dan halaman yang interaktifnya opsional

  • Saya memang bias karena termasuk salah satu orang yang ikut memungkinkan React lahir, tetapi saya benar-benar menyukai React. Sebelumnya saya mencoba segala macam hal untuk memperbaiki masalah yang saya hadapi di frontend. Namun sejak React muncul, kebutuhan itu hilang, dan saya bisa fokus hanya pada membangun sesuatu

  • Salah satu presentasi yang paling saya sukai adalah https://www.youtube.com/watch?v=h9SDuTSy7ps. Dari pengalaman saya, arsitektur React itu sangat bagus dan cukup cocok untuk membangun aplikasi besar
    Sayangnya, masalah terbesar React adalah ia memaksa kita masuk ke ekosistem JS/TS. Bagi saya, JavaScript/TypeScript tanpa diragukan lagi lebih terasa sebagai target kompilasi daripada sistem yang ingin saya tangani secara langsung
    Saya puas dengan Elm. Komunitasnya memang sangat kecil, dan kadang kita harus membuat library sendiri. TEA kadang terasa tidak alami jika datang dari React, tetapi saya selalu bersemangat saat bekerja dengan Elm karena tidak perlu mengkhawatirkan state implisit dan tak terduga seperti useEffect
    Selain itu, Claude tampaknya bertahan lebih baik di Elm daripada di React, setidaknya di dalam codebase besar yang menakutkan

    • Dari pengalaman saya, Elm pada dasarnya sudah mati. Lebih baik pakai React dan TypeScript yang punya library yang terus berfungsi. Ada juga upaya-upaya untuk membuat TypeScript bisa dikompilasi secara native
    • Saya suka TEA, tetapi saya belum sepenuhnya paham bagaimana itu berkembang pada aplikasi dengan komponen yang dapat digunakan ulang atau halaman yang cukup kompleks. Saya penasaran apakah ada cara yang disepakati untuk menanganinya
      State tampaknya seperti tabu besar, jadi rasanya agak bertentangan. Saya juga penasaran apakah pada akhirnya ini berarti semua aplikasi Elm menjadi aplikasi Redux + React global tanpa efek. Saya ingin tahu lebih banyak tentang apa yang menyenangkan dari Elm dan bagaimana biasanya orang bekerja dengannya. Tautan juga boleh