React vs. Backbone di Tahun 2025

• Perbandingan antara Backbone pada awal 2010-an dan React pada 2025, sambil meninjau kembali seberapa jauh perkembangan frontend benar-benar maju selama 15 tahun
• React tampak ringkas dan modern di permukaan, tetapi secara internal menyamarkan kesederhanaan lewat lapisan abstraksi yang kompleks
• Backbone memang lebih bertele-tele, tetapi alur event dan manipulasi DOM bersifat eksplisit, sehingga bahkan developer pemula pun dapat dengan mudah menelusuri cara kerjanya
• React memiliki struktur yang sulit di-debug jika tidak memahami cara kerjanya di dalam, karena melibatkan manajemen state, dependency array, dan masalah closure
• Pada akhirnya, tulisan ini mengingatkan kembali pada esensi “event + state = UI” dan mengajukan perlunya model baru yang sederhana serta memiliki struktur yang mudah diutak-atik (hackable)

---

Kemajuan selama 15 tahun

• Contoh field input kata sandi yang ditulis dengan framework era 2010-an (Backbone) dan React yang telah berkembang lebih dari 10 tahun
  • Kedua implementasi kode memiliki panjang yang mirip dan fungsi yang sama
  • React didukung oleh waktu kerja begitu banyak developer dan ekosistem yang sangat besar
  • Namun penulis menilai bahwa yang lebih menarik bukan “seberapa jauh React membaik”, melainkan “betapa sedikit kemajuannya”
• React menawarkan ilusi kesederhanaan di permukaan, tetapi kenyataannya lebih sulit dipahami karena abstraksi yang kompleks
  • Backbone secara eksplisit menampilkan alur sederhana: event terjadi → handler dijalankan → HTML dibuat → dimasukkan ke DOM
  • Sebaliknya, React menyembunyikan cara kerja internalnya, dan begitu melewati contoh sederhana, akan muncul masalah yang hanya bisa diselesaikan jika memahami mekanisme internalnya

Ilusi Kesederhanaan (The Illusion of Simplicity)

• Kode React terlihat rapi, tetapi itu adalah hasil dari memilih kompleksitas abstrak alih-alih kesederhanaan eksplisit
  • Backbone memang bertele-tele, tetapi dengan jelas menunjukkan “apa yang terjadi dan kapan itu terjadi”
  • Bahkan developer pemula pun dapat dengan mudah mengikuti alur kodenya
• Di React, state internal dan logika rendering disembunyikan, sehingga bug yang tidak terduga sering muncul
  • Contoh: jika key pada item daftar diubah menjadi indeks, React dapat mengenalinya sebagai komponen lain dan menginisialisasi ulang state
  • Jika value berubah menjadi undefined, dapat terjadi peralihan dari komponen tak terkontrol ke terkontrol yang menyebabkan nilai input di-reset
• Saat menggunakan useEffect, masalah loop tak berujung juga umum terjadi
  • Jika dependency array mencakup objek yang baru dibuat pada setiap render, React akan menganggapnya sebagai perubahan
  • Untuk mencegahnya, diperlukan useMemo dan useCallback untuk menstabilkan identitas (stabilize identities)
  • Akibatnya muncul beban untuk memikirkan konsep yang dulu tidak perlu diperhatikan
• Ada juga masalah ketika click handler mereferensikan state lama (stale state)
  • Karena fungsi menangkap state pada saat fungsi itu dibuat
  • Solusinya adalah memasukkan state ke dependency array, atau menggunakan functional update seperti setState(x => x + 1)
  • Namun kedua cara itu tetap terasa seperti solusi sementara (workaround)

Harga dari Keajaiban (Magic Has a High Price)

• Masalah-masalah ini bukan situasi pengecualian, melainkan masalah umum yang sering muncul pada aplikasi berskala menengah ke atas
  • Untuk melakukan debugging, perlu memahami algoritma reconciliation, render phase, dan scheduler (batch update)
  • React adalah struktur yang “tetap berjalan meski kita tidak tahu kenapa”, tetapi saat masalah muncul, solusinya menuntut pemahaman internal
• Kompleksitasnya sedemikian rupa hingga ada ungkapan “untuk benar-benar memahami React, kamu harus membuatnya sendiri”
  • Ada tutorial seperti “Build your own React”
  • Namun fakta bahwa untuk membuat validator kata sandi yang sederhana kita perlu memahami virtual DOM, prioritas scheduling, dan concurrent rendering memberi implikasi kritis
• Backbone dan jQuery memiliki struktur yang jujur dan hackable
  • Kita bisa langsung melihat dan memodifikasi source code-nya
  • Karena berbasis metode DOM, lebih mudah dipahami dan diperluas
  • Sebaliknya, lapisan abstraksi React membuat akses dan modifikasi internal menjadi sulit

Lalu, Apa Langkah Berikutnya? (So, What's Next?)

• Pada akhirnya, baik React maupun Backbone sama-sama merupakan upaya untuk menyelesaikan masalah yang sama: “event + state = UI”
• Pada aplikasi berskala besar, kompleksitas React mungkin bisa dibenarkan, tetapi untuk sebagian besar aplikasi kecil dan menengah, itu adalah beban yang berlebihan
• Dibutuhkan model UI baru yang memiliki kesederhanaan dan transparansi
  • Sistem yang kokoh namun intuitif seperti DOM
  • Struktur yang bisa langsung dipahami dan dimodifikasi seperti Backbone atau jQuery

[shakespeares]

Untuk aplikasi skala kecil hingga menengah, rasanya lebih tepat menyiapkan langkah ke depan dengan merancang JavaScript Class daripada memakai Backbone atau JQuery.
Menghafal lagi template-template yang ada di JQuery atau Backbone lalu melanjutkan pekerjaan rasanya seperti kemunduran.

[GN⁺]

Komentar Hacker News

• Sudah pernah memakai semuanya, dari Backbone, Angular 1, Ember, sampai React
  Jangan mengabaikan alasan React menjadi populer. Dalam hal komposisi komponen, penanganan event, manajemen state, dan pembaruan DOM yang efisien, React menyelesaikan masalah-masalah kronis pada framework sebelumnya
  Backbone rumit dalam mengelola siklus hidup DOM, dan karena event handler harus ditentukan sebagai string, pemeliharaannya sulit. React menyederhanakan masalah ini dengan alur state satu arah dan virtual DOM
  Kalau sekarang ingin memakai JS murni, saya rasa solusi templating seperti lit-html jauh lebih baik daripada Backbone

  • Contohnya terasa tidak realistis. Kalau mau membandingkan, TodoMVC adalah contoh yang representatif. Kalau melihat kode ini, versi Backbone sudah seperti mimpi buruk untuk dirawat. Versi React (tautan) jauh lebih jelas
    Frontend dulu juga rumit dan sekarang juga tetap rumit, tetapi sekarang jauh tidak terlalu menyakitkan
  • Setuju. React juga tidak sempurna, tetapi pada akhirnya ini soal kompromi. Alat apa pun yang dipakai, pengembang tetap harus menanggung kompleksitas itu. Yang penting adalah apakah kita memilih titik kompromi yang tepat
  • Sekarang banyak framework selain React yang juga menyediakan kemampuan seperti ini. Itu bukan lagi hak istimewa React saja

• Kompleksitas aplikasi bukan berasal dari jumlah komponen, melainkan dari manajemen state
  Karena alur data dua arah di Backbone Store, saya sering mengalami UI macet. Inovasi React adalah arsitektur Flux yang berpusat pada alur data satu arah
  Saya menganggap framework yang baik adalah alat yang secara alami mengarahkan kita ke “Pit of Success”. React sudah menjalankan peran itu dengan baik

  • Pengembangan frontend sebelum React/Flux/Redux benar-benar kacau. Bahkan pada kode yang belum sampai 1000 baris pun masalah manajemen state sudah meledak
  • Saya penulisnya. Memang benar alur data satu arah menyelesaikan masalah, tetapi React juga membawa kompleksitas baru
    Misalnya, masalah seperti stale closure, loop useEffect tak berujung, dan input ter-reset karena perubahan key tidak ada di Backbone
    Masalah di Backbone terlihat jelas dan mudah di-debug, tetapi masalah React tersembunyi di balik abstraksi
    Kebanyakan aplikasi tidak berskala Facebook, jadi pendekatan yang eksplisit dan sederhana justru bisa lebih baik
  • Saya lama memakai Angular lalu kembali ke React, dan walaupun tidak sempurna, React mendorong pengembang untuk menulis kode ke arah yang benar
  • Komponen itu sendiri adalah kompleksitas lain. Markup, event, logika bisnis, dan aksesibilitas digabung menjadi satu struktur besar. Pada akhirnya ini hanyalah kompleksitas demi kenyamanan; kesederhanaan tidak pernah gratis
  • Bukankah “alur data satu arah” sebenarnya mirip dengan perilaku dasar DOM? Yang dibuat tim React adalah Flux, bukan Flow

• Menyimpulkan bahwa teknologi populer itu “buruk” terasa seperti bentuk kesombongan naif
  Tentu saja popularitas tidak menjamin kualitas, tetapi menganggap semua insinyur hebat di seluruh dunia tertipu juga berlebihan

  • Teknologi populer tidak selalu benar. Coba ingat tren MongoDB, Kafka, dan Microservice
    Kalau didorong perusahaan besar dan pemasaran, para CTO akan mengadopsinya, dan kalau karier dipertaruhkan, tak ada yang mau bilang “ini kurang bagus”. Popularitas ≠ kecocokan
  • Saya penulisnya. Analogi “influencer paleo” itu menarik, tetapi yang baru juga tidak otomatis lebih baik
    React tidak menang hanya karena keunggulan teknis, tetapi juga karena pemasaran Facebook dan penguatan ekosistemnya sendiri
    Setelah 15 tahun, panjang dan kompleksitas kode juga tidak banyak berkurang. Hanya saja menjadi rumit dengan cara yang berbeda
    Menoleh ke masa lalu bukan karena nostalgia, melainkan untuk memeriksa apakah kita telah menambahkan kompleksitas yang tidak sepadan
  • React atau Tailwind punya keunggulan dalam kemudahan perekrutan. Alasannya bukan kesempurnaan teknis, melainkan kemudahan onboarding
    Web tetap seperti wilayah liar untuk pola desain. Setelah menerima itu, saya jadi lebih tenang
  • Menyebut React itu “bodoh” tampak seperti campuran kesombongan dan ketidaktahuan. Ada alasan jutaan pengembang memakainya. Penolakan total seperti itu mengabaikan Chesterton’s Fence
  • Mungkin bukan kesombongan, melainkan pengalaman dari sudut pandang berbeda. Ada yang menyukai ekosistem React, ada juga yang tidak suka karena banyaknya JS
    Pada akhirnya, untuk setiap proyek kita harus mengevaluasi ulang trade-off

• Klaim “untuk hal sederhana tidak perlu React” adalah React fallacy yang umum
  Menilai React dari contoh sederhana sama seperti “menilai bahasa dari panjang Hello World”-nya
  Alasan React dipakai untuk hal sederhana adalah karena React juga dipakai untuk hal kompleks. Set alat yang konsisten lebih menguntungkan untuk pemeliharaan

  • “Karena dipakai untuk hal kompleks maka dipakai juga untuk hal sederhana” itu seperti pergi belanja pakai truk. Intinya tetap memilih alat yang tepat

• Backbone itu “terlihat seperti framework, tetapi sebenarnya gumpalan glue code”
  Kemenangan sejati React adalah tidak perlu manipulasi DOM langsung dan adanya manajemen state reaktif. Dua hal ini sangat meningkatkan produktivitas pengembang

  • Sebagai orang yang dulu banyak memakai tutorial Backbone, ada sedikit rasa nostalgia
    Tautan tutorial lama, versi arsip
    Sekarang saya lebih tertarik pada bagaimana LLM memahami kode. Sintaks deklaratif seperti JSX ramah terhadap LLM
    Tetapi React setelah useEffect justru terasa makin kabur dari sisi daya ekspresi dan keeksplisitan
  • Marionette banyak mengurangi boilerplate Backbone
  • Muncul pertanyaan apakah React punya manajemen state bawaan

• Alasan React menjadi sangat populer terlihat jelas
  Kode React kebanyakan hanyalah JS dan HTML murni, dan intinya hanya useState. Sangat intuitif sehingga bisa dipahami tanpa dokumentasi
  Backbone bergantung pada selector string seperti .space-y-2, sehingga pemeliharaannya seperti neraka. Ganti satu nama class, setengah aplikasi bisa rusak
  React menyelesaikan masalah ini secara struktural

  • Muncul candaan bahwa “tulisan itu sepertinya bukan ditulis langsung, melainkan disuruh ke Claude”

• Kode Backbone jelas menunjukkan “apa yang terjadi dan kapan”, sedangkan React mengharuskan kita memahami cara kerja internalnya
  Saya juga berkali-kali membaca panduan useEffect dari Dan Abramov dan blog Mark Erikson untuk memahami kapan React bekerja
  Kode Backbone tetap langsung bisa dipahami bahkan setelah dilihat lagi 10 tahun kemudian

• Enam tahun lalu tim kami pindah dari Backbone ke Angular
  Backbone bagus untuk junior karena intuitif dan tanpa sihir, tetapi pada akhirnya TypeScript dan Angular lebih sistematis
  Sekarang kami memakai NG20 dan puas. Jika suatu hari browser menyediakan lebih banyak kemampuan secara bawaan, mungkin kami bisa kembali ke cara yang lebih sederhana

• Kita selalu memrogram di atas abstraksi
  Yang penting adalah apakah abstraksi itu memberi keuntungan produktivitas dibanding kompleksitasnya, dan apakah bisa dipercaya
  Setidaknya, dalam skenario terburuk pun tetap harus bisa di-debug

• Field input React menangani undo dengan lebih alami daripada Backbone
  Backbone mengembalikan satu huruf per satu huruf, sedangkan React mengembalikan per kata

  • Saya tidak paham kenapa menimpa perilaku bawaan browser dianggap lebih baik. Malah terasa seperti library JS yang merusak scroll alami
  • Menariknya, di Chrome hasilnya berbeda, tetapi di Firefox kedua framework berperilaku sama
  • Saya rasa cara Backbone lebih baik
  • Perilaku mana yang “benar” pada akhirnya adalah soal selera pribadi