Hal-hal yang Seandainya Sudah Saya Ketahui Sebelum Memindahkan 50 Ribu Baris Kode ke React Server Components

• Artikel tentang pengalaman dan pelajaran yang didapat penulis saat memindahkan 50.000 baris kode ke React Server Components (RSCs)
• RSCs adalah komponen React yang berjalan di server alih-alih di klien, dan memberikan dua keuntungan utama dibandingkan server-side rendering (SSR)
  • Pertama, RSCs memungkinkan pengembang menentukan di mana kode dijalankan, sehingga ukuran bundle dapat dikurangi dan pekerjaan selama hydration berkurang
  • Kedua, komponen server dapat mengambil data langsung di dalam komponen dan melakukan streaming ke klien, sehingga pengambilan data di React menjadi lebih mudah dan efisien
• Namun, ada beberapa keterbatasan dalam penggunaan RSCs. CSS-in-JS tidak berfungsi di komponen server, React Context hanya dapat diakses di komponen klien, dan kompleksitas dalam mengelola lokasi eksekusi kode bisa menjadi tantangan
• Penulis mengusulkan pendekatan 3 tahap untuk mengadopsi RSCs secara bertahap:
  • Menambahkan direktif "use client" di root aplikasi
  • Memindahkan direktif itu ke posisi serendah mungkin dalam pohon rendering
  • Mengadopsi pola lanjutan saat masalah performa muncul
• Terlepas dari kompleksitas tambahan tersebut, penulis menyimpulkan bahwa manfaat RSCs, seperti ukuran bundle yang lebih kecil, eksekusi yang lebih cepat, dan pola pemuatan data yang lebih canggih, dapat lebih besar daripada biayanya jika keuntungan performa itu memang bernilai bagi tim

[GN⁺]

Opini Hacker News

• Artikel ini membahas perpindahan 50K baris kode ke React Server Components (RSCs).
• Beberapa pengguna menyinggung kecepatan dan kemudahan server-side rendering, serta menyoroti bahwa klien menerima HTML yang bisa langsung dilihat.
• Ada usulan bahwa mempertimbangkan full-stack atau framework web klasik seperti Rails, Django, dan Laravel alih-alih RSCs bisa menjadi solusi yang lebih cepat dan lebih mudah diskalakan.
• Sebagian pengguna menyatakan kekhawatiran tentang kompleksitas framework modern, dengan menyebut pipeline build dan kompilasi yang luas bahkan untuk pekerjaan yang sederhana.
• Pengguna membagikan pengalaman pribadi mereka dengan next.js dan konfigurasi direktori app barunya, serta menekankan sulitnya memahami di mana pekerjaan berlangsung (di server atau klien) dan masalah dengan library React lama yang mengasumsikan pekerjaan sisi klien.
• Sebagian pengguna menunjukkan bug dan bagian yang masih kasar dalam paradigma direktori app baru di next.js, termasuk masalah terkait dynamic routes dan parallel routes.
• Seorang pengguna menyebut kemiripan PHP dan JavaScript, serta menyoroti bahwa JavaScript telah berkembang untuk menyediakan fungsi sisi server yang serupa, meski dengan lebih banyak singkatan dan kurva belajar yang lebih curam.
• Sebagian pengguna mempertanyakan perlunya menggunakan React untuk pekerjaan yang sebenarnya bisa diselesaikan dengan alat yang lebih sederhana seperti static site generator atau CMS dengan caching.
• Ada nuansa nostalgia terhadap masa ketika server merender semuanya dan CSS serta JavaScript menyempurnakan halaman setelah proses render.
• Sebagian pengguna menyampaikan pandangan bahwa React menjadi semakin kompleks demi mengejar alternatif modern yang lebih mudah dan lebih cepat.
• Ada perdebatan tentang penggunaan React untuk merender HTML di backend; sebagian pengguna mempertanyakan kebutuhannya, sementara yang lain membela keunggulannya dibandingkan metode pengembalian dari server tradisional.