Jika Bukan React, Lalu Pakai Apa?

 (infrequently.org)
11 poin oleh GN⁺ 2024-12-01 | 12 komentar | Bagikan ke WhatsApp

> "Frameworkism (paham yang memuja framework) sudah tidak lagi berlaku. Jawabannya bukan alat lain, melainkan keberanian untuk benar-benar melakukan engineering"

  • Selama 10 tahun terakhir, telah menangani lebih dari 100 proyek melalui beragam produk dan tech stack untuk web desktop dan mobile
  • Banyak waktu dihabiskan bukan untuk meningkatkan Web API, melainkan untuk menyelesaikan masalah performa dan aksesibilitas yang disebabkan framework frontend seperti React
  • React pada dasarnya sudah merupakan teknologi legacy, tetapi masih terus diadopsi dalam proyek baru
  • Ada yang mengklaim React itu "modern", tetapi itu pada dasarnya hanya mengulang cara lama

Aturan kompleksitas sisi klien seminimal mungkin

  • Kode sisi server dapat dikendalikan developer, sehingga performa dan availability bisa dikelola secara efektif
  • Kode sisi klien berjalan di beragam lingkungan yang tidak dapat dikendalikan developer, sehingga sulit menjamin stabilitas dan performanya
  • Strategi terbaik adalah mengurangi jumlah kode yang dikirim ke klien
    • Utamakan HTML dan CSS untuk meminimalkan ketergantungan pada JavaScript
    • React dan framework serupa menimbulkan duplikasi kode yang tidak perlu serta penurunan performa

Kalau begitu, apa alternatifnya?

Diskusi yang terbelah menjadi dua pertanyaan

  • Pertanyaan sempit: "Jika client rendering memang diperlukan, teknologi apa yang bisa menggantikan React?"
    • Framework modern (mis. Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue, Stencil, dll.) layak dipertimbangkan
    • Namun, bahkan saat memakai framework-framework ini, payload dan kompleksitas sisi klien tetap harus dikelola dengan ketat. JavaScript setidaknya 3x lebih mahal dibanding HTML/CSS
  • Pertanyaan luas: "Bagaimana cara meninjau ulang secara menyeluruh tech stack yang bergantung pada React?"
    • Bukan sekadar mengganti dengan alat baru, tetapi memahami tujuan dan batasan arsitektur yang ada lalu merancang ulang

Pendekatan untuk pertanyaan sempit

  • Buat beberapa PoC (Proof of Concept) kecil untuk mengevaluasi skalabilitas performa dan batasannya
  • Eksperimen objektif seperti ini memberi pengalaman engineering yang bermakna bagi anggota tim

Situasi umum tim yang mengajukan pertanyaan luas

  • Dalam diskusi tentang mengganti React, sering kali muncul kebingungan
    • Kebanyakan keputusan dibuat dengan mengikuti arsitektur yang sudah ada
    • Tidak adanya pemahaman yang jelas tentang pengalaman pengguna dan pengambilan keputusan berbasis data

Perbedaan frameworkism dan pendekatan berpusat pada pengguna

  • Frameworkism: keyakinan bahwa semua masalah akan selesai jika menambahkan lebih banyak fitur ke framework
    • Pada praktiknya, sering kali gagal menyelesaikan masalah pengguna
    • Mengabaikan pola non-standar atau bukti yang berpusat pada data
  • Realisme: mengukur pengalaman pengguna dan mengambil keputusan berdasarkan data nyata
    • Memahami kebutuhan dan batasan pengguna, lalu merancang tech stack berdasarkan itu
    • Titik awalnya selalu kebutuhan pengguna

Cara menerapkan realisme

  • Memanfaatkan data RUM: gunakan metrik performa yang berpusat pada pengguna seperti Core Web Vitals
  • Pengujian performa: gunakan alat seperti WebPageTest(WPT) untuk mengukur critical user journeys
  • Menghubungkan tujuan bisnis dan pengalaman pengguna: gunakan data untuk menilai arah perbaikan dan efektivitas investasi

Pentingnya pendekatan berbasis data

  • Alih-alih mengadopsi framework berdasarkan kepercayaan, verifikasi efektivitasnya dengan data
  • Bandingkan biaya dan dampak nyata dari adopsi teknologi yang didorong tren
  • Dorong pemilihan teknologi yang berfokus pada optimasi pengalaman pengguna melalui metrik yang dapat diukur

Tidak ada satu pun hal berharga yang hilang

Efek kebijakan yang menghambat penyebaran React

  • Melarang pendekatan yang berpusat pada React dan framework lain berkontribusi pada pengurangan biaya dan penataan ulang tim agar berpusat pada pengguna
  • Namun, tanpa benar-benar menyingkirkan frameworkism, sulit mencapai perbaikan hasil yang mendasar
  • Walau satu kesalahan berhasil dihindari, dampaknya tetap terbatas jika masih berinvestasi pada kesalahan lain dalam kategori yang sama

Solusi umum untuk masalah yang lebih luas

Berpusat pada pengguna

  • Pengambil keputusan harus bertanggung jawab langsung atas hasil dari pilihan engineering mereka
  • Tanpa alasan, jika sistem tidak bekerja dengan baik bagi pengguna (terutama pengguna yang terpinggirkan), terapkan versi alternatif
  • Yang ada hanya masalah yang harus diselesaikan; tidak ada ruang untuk "mensakralkan" cara lama secara membabi buta

Pendekatan berbasis bukti

  • Diperlukan komitmen realisme yang dibagikan antara manajemen dan engineering
  • Dalam pengambilan keputusan, bukti yang lebih baik harus selalu menang

Guardrail

  • Diperlukan kebijakan untuk mencegah klaim ilusif dari frameworkism
  • Contoh: persyaratan teknis progressive enhancement dari UK Government Digital Service
    • Kebijakan bisa disesuaikan dengan kondisi organisasi (mis. membuat jalur eskalasi untuk situasi pengecualian)
    • Namun yang penting adalah menetapkan standar yang jelas. Kebijakan berbasis bukti punya daya pengaruh yang kuat

Evaluasi perbandingan teknologi

  • Jangan meluncurkan sistem baru tanpa critical user journeys yang terdefinisi dengan jelas
  • Critical user journeys mewakili tugas yang paling sering dilakukan pengguna dalam sistem
  • Berdasarkan itu, lakukan evaluasi perbandingan (bakeoffs) yang menguji hasil tiap teknologi di bawah batasan yang ada
    • Product manager harus melampaui sekadar mengusulkan eksperimen, dan mendefinisikan hipotesis produk yang jelas serta kriteria keberhasilannya
    • Ini bisa menjadi proses yang tidak nyaman, tetapi merupakan peran inti product manager
    • Pengunduran diri PM yang merasa itu bukan bagian pekerjaannya dianggap dapat diterima

Studi kasus

Memahami perbedaan realisme dan frameworkism lewat contoh

  • Kriteria pemilihan teknologi
    • Pemilihan teknologi dinilai berdasarkan jumlah update data utama dan panjang sesi
    • Sebagian kelas aplikasi ditandai oleh sesi yang panjang dan update data yang sering
      • Dalam kasus ini, model data lokal bisa cocok
      • Namun ini adalah situasi langka dan pengecualian
  • Untuk sesi pendek
    • Situs dengan durasi sesi rata-rata yang pendek harus meminimalkan jumlah JavaScript awal yang dimuat
    • Sebagian besar situs tidak memerlukan arsitektur SPA
  • Jika arsitektur SPA memang diperlukan
    • Arsitektur SPA hanya boleh dipertimbangkan jika memenuhi kondisi tertentu
      • Saat sesi panjang dan perlu beberapa kali update terhadap data yang sama
    • Situs yang tidak memenuhi kondisi ini tidak seharusnya mengadopsi SPA
  • Pertanyaan inti
    • Pilihannya bukan soal framework JavaScript mana
    • Dalam banyak kasus, inti persoalannya adalah apakah tepat menggunakan alat yang memang berorientasi SPA sejak awal
    • Untuk sebagian besar situs, jawabannya jelas "tidak"

Situs web informasional (Informational)

  • Struktur optimal: gunakan HTML semantik dan progressive enhancement bila perlu
  • Static site generator (Hugo, Astro, 11ty, Jekyll) cocok digunakan
  • Untuk konten yang sering diperbarui, gunakan alat CMS seperti WordPress
  • Blog, situs marketing, homepage perusahaan, dan situs informasi publik harus meminimalkan payload JavaScript sisi klien semaksimal mungkin
  • Jangan gunakan framework yang dirancang untuk arsitektur SPA
  • Mengapa markup semantik dan progressive enhancement cocok?
    • Ditandai oleh sesi pendek dan model data yang dimiliki server
      • Sumber data yang ditampilkan di halaman selalu dikelola di server
      • Tidak perlu abstraksi model data klien atau definisi komponen
    • Konfigurasi CMS:
      • Editor bertrafik rendah dengan interaksi tinggi untuk penulis
      • Viewer UI bertrafik tinggi dengan interaksi rendah untuk pembaca

E-commerce

  • Arsitektur yang direkomendasikan: HTML semantik yang dihasilkan server dan progressive enhancement
  • Kesenjangan performa antara Amazon dan pesaing berbasis React terlihat jelas
    • Lebih dari 70% trafik Walmart berasal dari mobile, dan Next.js berbasis SPA berdampak negatif pada bisnis
  • Mengapa progressive enhancement cocok
    • Struktur umum e-commerce:
      • Landing page yang berisi produk yang sedang ditawarkan dan fitur pencarian
      • Halaman hasil pencarian yang mendukung filter dan perbandingan
      • Halaman detail produk: media, ulasan, dan alternatif yang direkomendasikan
      • Layar pengelolaan keranjang, checkout, dan manajemen akun
    • State milik server:
      • Menjaga konten tetap segar (mis. harga)
      • Mengurangi latensi melalui optimasi halaman yang ringan
      • Menggunakan strategi caching agresif, optimasi gambar, dan pengurangan ukuran halaman

Situs web konsumsi media (Media)

  • Struktur dasar: dirancang berbasis progressive enhancement
    • Tambahkan kompleksitas sesuai perubahan produk bila diperlukan
  • Mengapa progressive enhancement dan struktur Islands cocok
    • Elemen interaktif seperti thread komentar dapat disusun sebagai model data yang independen
    • Dapat diimplementasikan dalam halaman statis dengan memanfaatkan Web Components
  • Saat SPA cocok
    • Persistensi pemutaran media:
      • Perlu mempertahankan mini player saat menavigasi halaman
      • Gunakan teknologi SPA sambil mengelola batas ukuran JS klien
    • Dukungan pemutaran offline:
      • Diperlukan logika untuk mengelola cache media lokal
      • Pertimbangkan sistem sinkronisasi data seperti Zero, Y.js

Media sosial (Social)

  • Model hybrid: interaksi ringan berbasis model data milik server + update media sesekali
  • Mengapa progressive enhancement cocok
    • Interaksi umum:
      • Klik "like", update sesekali, dan semacamnya
      • Pendekatan hybrid dengan Hotwire atau HTMX cocok digunakan
  • Saat SPA cocok
    • Pulau interaksi yang dalam:
      • Memanfaatkan cache klien untuk hal seperti menyimpan draft post
    • Dukungan offline:
      • Tetap kirim HTML lebih dulu, lalu implementasikan sinkronisasi dan logika offline melalui Service Worker

Aplikasi produktivitas (Productivity)

  • Aplikasi produktivitas berpusat pada dokumen memiliki kebutuhan kompleks (editing kolaboratif, dukungan offline, mode tampilan ringan)
  • Model data lokal dan arsitektur berbasis SPA bisa cocok
  • Mengapa SPA cocok
    • Update data yang sering:
      • Dalam aktivitas seperti input keyboard atau drag mouse, logika klien lebih unggul
    • Perlu pengelolaan batas performa:
      • Mengelola ukuran bundle awal
      • Menerapkan strategi pemuatan paket tertunda

Kelas aplikasi lain (Other Application Classes)

  • Kebutuhan khusus:
    • 3D CAD, editor pemrograman, game streaming, game berbasis web, editing media, sistem produksi musik, dll.
    • Tiap kelas aplikasi perlu dievaluasi hati-hati dengan cara yang sama seperti aplikasi produktivitas
  • Syarat keberhasilan:
    • Mendefinisikan critical user journeys
    • Menganalisis rata-rata kedalaman sesi
    • Menetapkan metrik jaminan performa
    • Mengendalikan script dan resource inti

Sedikit tentang enterprise software

  • "Aplikasi bisnis enterprise" umumnya menimbulkan masalah performa terburuk
    • Dashboard, sistem workflow, aplikasi chat enterprise, dan sejenisnya adalah contoh yang umum
  • Performa adalah budaya:
    • Gagal mendefinisikan dan mengukur waktu loading awal dan performa setelah interaksi
    • Budaya yang berpusat pada developer dan mengabaikan pengguna menjadi racun

"Tapi…"

  • Manajer yang terikat pada framework tertentu termasuk React sering mengajukan berbagai logika untuk membenarkan pilihan tersebut
  • Namun, argumen-argumen ini tidak menempatkan pengalaman pengguna di pusat, dan kekurangan itu terus berulang.

"...kami harus bergerak cepat"

  • Pertanyaan: "Menurut Anda, itu akan bertahan berapa lama?"
  • Proyek berbasis NPM yang dibangun cepat akan memicu masalah aksesibilitas, performa buruk, dan kompleksitas yang meningkat, sehingga pada akhirnya justru memperlambat
  • Biaya remediasi: butuh berbulan-bulan untuk menyelesaikan masalah JavaScript, dan kecepatan rilis fitur pun makin turun
  • Untuk mencapai Product-Market Fit, aksesibilitas dan kualitas harus diprioritaskan
  • Memilih React demi "bergerak cepat" dalam jangka panjang lebih mahal dan menghambat pertumbuhan

"...kan dipakai dengan baik di Facebook"

  • Sebagian besar perusahaan tidak menghadapi masalah yang sama seperti Facebook
  • Facebook juga mengalami masalah performa akibat penggunaan React, tetapi menutupinya lewat posisi dominan mereka
  • Perusahaan biasa tidak boleh meniru kasus Facebook secara mentah-mentah

"...tim kami sudah tahu React"

  • Developer React tetaplah web developer. Pekerjaan dengan CSS, HTML, JavaScript, dan DOM itu wajib
  • React adalah lapisan paling sederhana yang bisa diganti dalam tech stack
  • Tidak ada hambatan besar untuk mempelajari framework yang lebih kecil dan cepat seperti Preact, Svelte, Lit, FAST, dll.

"...perekrutan harus mudah"

  • Industri IT saat ini adalah kesempatan emas untuk merekrut developer hebat
  • Pengetahuan React tidak bisa menjadi standar perekrutan
  • Developer yang tahu React pada umumnya juga bisa dengan mudah mempelajari web standard
  • Sebaliknya, sistem yang lebih sederhana justru memberi ROI lebih tinggi

"...semua orang pakai ponsel cepat"

  • Dalam 10 tahun terakhir ketika penggunaan mobile meningkat, asumsi bahwa resource klien itu murah sudah jelas merupakan anggapan yang salah
  • Pengguna ponsel dengan performa rendah pun kemungkinan besar merupakan pelanggan utama produk
  • Memilih React berarti mengasumsikan semua pengguna memakai perangkat mahal, dan itu berisiko

"...React itu standar industri"

  • React bukan standar yang konsisten.
    • Pendekatan React sendiri (class component vs functional component), penggunaan TypeScript atau tidak, pilihan alat state management, dan lain-lain berbeda di setiap proyek.
  • Stack React selalu berubah-ubah, dan klaim "standar" hanyalah fiksi yang menenangkan

"...ekosistem..."

  • Sangat sedikit library yang hanya kompatibel dengan React, dan sebagian besar alat juga bisa dipakai di Preact dan lain-lain
  • Semua paket NPM berfungsi sebagai utang teknis terhadap masa depan
  • Dependensi yang tidak perlu seperti CSS-in-JS hanya menambah biaya

"...Next.js juga cukup cepat"

  • Next.js pada dasarnya membawa serta masalah performa React
  • Alat yang mengutamakan HTML (mis. Astro, 11ty) memberi performa yang lebih baik daripada Next.js
  • Ada juga masalah lock-in ke API startup yang didanai VC

"...React Native!"

  • React Native membuat aplikasi mobile lebih lambat dan menuntut biaya maintenance yang tinggi
  • Menggunakan PWA serta Capacitor/Cordova adalah pilihan yang lebih baik
  • Facebook juga sedang menjauh dari React Native.

Bacaan terkait

12 komentar

 
nemorize 2024-12-08

Perusahaan pada umumnya tidak seharusnya asal mengikuti contoh Facebook.

  • Facebook juga sedang menjauh dari React Native.

Pengguna ponsel dengan performa rendah juga sangat mungkin menjadi pelanggan utama produk.

  • Implementasi sinkronisasi dan logika offline melalui Service Worker

React Native membuat aplikasi mobile lebih lambat dan menuntut biaya pemeliharaan yang besar.

  • Menggunakan Capacitor/Cordova adalah pilihan yang lebih baik.

Wkwkwkwkwkwk wkwk
 
wildmental 2024-12-03

Tulisan ini terlalu panjang sehingga fokus utamanya jadi kabur.

Penulis tampaknya menganggap bahwa pendapat yang mendukung penggunaan React selalu berangkat dari fundamentalisme framework.

Setelah mengatakan bahwa kita perlu keluar dari fundamentalisme framework dan mendekati tiap kasus secara spesifik, ia justru mencoba membuat semacam resep untuk semua jenis kebutuhan engineering.

Yang paling menonjol adalah upaya berlebihan untuk menguasai percakapan dengan menjawab semua kemungkinan sanggahan. Sanggahan balik terhadap keberatan-keberatan itu juga terlalu sempit.

Dengan kata lain, untuk menjalankan diskusi yang membahas hal-hal umum melampaui kasus tertentu, penulis tampak sangat kurang dalam sikap dan keterampilan berdiskusi yang diperlukan.

Akibatnya, meskipun saya tidak suka menggunakan React, hanya karena sikap penulis yang sepihak saya jadi ingin sedikit lebih mendengar pendapat orang-orang yang mendukung penggunaan React.
 
savvykang 2024-12-03

Secara pribadi, untuk saat ini saya berpendapat bahwa React masih pilihan terbaik.

Saya mulai belajar pengembangan web sejak era PHP dan jQuery, dan di perusahaan tempat saya bekerja sekarang saya sudah pernah menggunakan AngularJS, Angular, React gaya class, dan React gaya hook. Dari pengalaman itu, menurut saya mengganti tech stack setelah berbagai trial and error dari para pengguna awal serta ekosistem library-nya sudah matang akan jauh lebih mengurangi pusing. Kalau dianalogikan dengan semantic versioning, ini seperti memakai major version terbaru dikurangi satu. Selama kebutuhan dan fitur tingkat tinggi tidak berubah, seharusnya tidak ada masalah, tetapi ketika tidak ada referensi untuk teknologi dasarnya, produktivitas benar-benar sulit didapat. Selain itu, karena karakteristik proyek di perusahaan kami berbeda dengan layanan SaaS, siklus produknya panjang dan ada periode yang hanya berisi maintenance, sehingga makin sulit untuk menerapkan teknologi paling baru.

Mungkin saat React beralih arah ke Next.js, menghentikan dukungan SPA, dan memaksa perubahan arsitektur, saya perlu mempertimbangkan lagi perpindahan teknologi. Kalau Vue lebih luas diadopsi, tentu akan masuk kandidat. Tidak ada alasan untuk tidak memakainya.
 
dalinaum 2024-12-03

Kalau RN dibilang membuat aplikasi mobile jadi lambat, kenapa malah merekomendasikan Capacitor atau Cordova? Menurut saya, pendekatan yang setidaknya menampilkan UI secara native itu dari sisi performa jauh lebih baik dibanding web hybrid.
 
dalinaum 2024-12-03

Sedihnya, di pasar kerja Korea, jika "sikap framework-agnostic tidak berlaku," kemungkinan besar Anda akan langsung gagal saat wawancara. Dalam banyak wawancara, pertanyaan yang diajukan adalah hal-hal yang hanya diketahui jika Anda sudah banyak menggunakan framework.
 
clastneo 2024-12-03

Developer RN menangis tersedu-sedu
 
clastneo 2024-12-03

Kalau mau dibahas serius, nilai RN itu ada pada kemampuannya menangani komponen native lewat bundle JS, jadi use case-nya sama sekali berbeda dengan PWA.

Bahkan ada bagian yang sulit ditangani dengan webview, lalu PWA? Dalam jangka panjang saya memang melihat arahnya akan menuju ke sana, tetapi untuk saat ini masih terlalu dini. Rasanya sejak awal ini seperti membandingkan hal-hal yang sebenarnya tidak ada artinya untuk dibandingkan.
 
bbulbum 2024-12-04

Betul. Isi artikelnya nyaris berpendapat bahwa aplikasi native hampir tidak diperlukan.
 
savvykang 2024-12-03

Selama masih ada orang yang tergoda pada hal-hal baru, masalah seperti ini akan terus berulang. Karena sudah ada sistem yang dibangun dengan React, mengabaikan persoalan rekrutmen tidak akan mengubah kenyataan. Alasan Facebook mendorong React dan alasan perusahaan pada umumnya memilih React setelah 10 tahun itu berbeda.

Saya rasa diskusi untuk mengubah arsitektur dan paradigma harus dilakukan dengan lebih hati-hati daripada ini dan sebisa mungkin meyakinkan sebanyak mungkin orang.
 
huiya 2024-12-03

Tapi preact juga react-like, dan kalau keluar dari React jumlah library-nya.....
Begitu terlihat seperti library yang lumayan bagus, ternyata semuanya khusus React; developer Vue pun menangis
 
alucard 2024-12-03

Saya memakainya dengan baik, jadi rasanya memang ada sedikit kesan dipaksa mengkritik.. Kalau ditulis bertele-tele seperti ini, jadinya terasa seperti ingin membuat orang merasa sedang berhadapan dengan masalah besar..
 
GN⁺ 2024-12-01
Opini Hacker News

  • Saya rasa sebagian besar alasan menentang penggunaan React adalah karena mencoba menyelesaikan masalah yang keliru. Masalah performa sebenarnya bukan isu besar. Dalam kebanyakan kasus, peningkatan backend lebih efektif

    • React dikritik karena menggunakan sistem event yang kuno, tetapi ini tidak menimbulkan masalah bagi pengguna. Ini bukan alasan untuk sepenuhnya meninggalkan React
    • Diskusinya terasa kurang karena tidak ada alternatif pengganti React yang diajukan. Saya pikir alternatifnya lebih buruk daripada React

  • Alasan React dan jQuery menjadi populer adalah karena kodenya terlihat rapi. Contoh kode awal AngularJS tidak enak dilihat

    • React pada akhirnya akan tergantikan, seperti jQuery, jika muncul alternatif yang lebih baik. Penting agar contoh kodenya terlihat bagus

  • Inti React adalah memungkinkan state UI O(n) dirender secara fungsional. Di masa lalu, mengelola transisi state O(n^2) itu rumit

    • React adalah alat arus utama pertama yang mengurangi kompleksitas ini, dan layak atas keberhasilannya

  • Alasan terus menggunakan React adalah karena teknologinya stabil dan matang seperti Java. Komunitas dan sumber dayanya sangat melimpah

  • Tulisan Alex menunjukkan frustrasi terhadap perdebatan yang terus berulang. Banyak orang tidak membaca tulisannya sampai selesai

    • Ia seperti Cassandra yang melihat kebenaran tentang performa web tetapi tidak ada yang mempercayainya

  • Ungkapan bahwa pengembang React adalah pengembang web terasa makin tidak tepat. Semakin banyak pengembang yang hanya terbiasa dengan SPA React dan framework styling

    • Alasan orang memakai React adalah karena Facebook, dan banyak orang tidak pernah mempertanyakannya

  • Sebagian besar situs tidak memerlukan SPA. Namun, bisnis yang membutuhkan banyak data diuntungkan oleh SPA

    • Ada banyak kritik terhadap paket NPM, tetapi kurang ada upaya untuk memahami alasannya
    • React bukan framework, melainkan view library

  • Saya tidak menyukai React. Sebagai pengembang backend, saya lebih memilih HTML yang dihasilkan server dengan sedikit JavaScript

    • Untuk proyek baru, saya sedang mempertimbangkan Elixir/Phoenix/LiveView dan HTMX

  • Pengembangan frontend bergeser ke framework JavaScript karena biaya pemeliharaan

    • Jika build frontend sudah termasuk dalam proses, biayanya bisa ditekan
    • Pola SPA paling cocok dengan build frontend

  • Ada banyak kritik yang keliru terhadap React. Pengembang React bisa menyelesaikan pekerjaan tanpa harus membuat bahasa template baru

    • Alasan situs web lambat bukan karena React, melainkan karena pengembangnya atau kurangnya anggaran