Hal-hal yang Seandainya Diketahui Sebelum Memindahkan 50 Ribu Baris Kode ke React Server Components

 (mux.com)
1 poin oleh GN⁺ 2023-09-03 | 1 komentar | Bagikan ke WhatsApp
  • Saat memindahkan mux.com dan docs.mux.com ke React Server Components, Mux mendapati bahwa membagi batas eksekusi antara server dan klien berdampak langsung pada ukuran bundle dan biaya hydration
  • RSC memungkinkan komponen mengambil data langsung di server dan streaming hasilnya, sehingga sebagian tampilan bisa ditampilkan lebih dulu meski ada pemanggilan data yang lambat
  • Hambatan terbesar dalam migrasi nyata adalah tidak adanya dukungan CSS-in-JS, keterbatasan React Context di Server Components, dan kompleksitas karena harus terus melacak batas server/klien
  • Di app directory Next.js 13, default-nya adalah Server Component, sehingga adopsi bertahap dimungkinkan dengan cara secara perlahan menurunkan use client ke bagian yang lebih bawah dari root
  • Pola seperti Suspense, loading.js, menjaga library tetap khusus server, dan server-only harus diterapkan secara hati-hati hanya di area yang benar-benar membutuhkan keuntungan performa, sambil ikut menghitung biaya kognitif tim

Cakupan perpindahan Mux ke RSC

  • Sambil melakukan restrukturisasi situs dokumentasi dan rebranding, Mux memindahkan mux.com dan docs.mux.com ke Server Components
  • React Server Components bisa diterapkan pada codebase nyata dan mungkin layak digunakan, tetapi juga membawa keterbatasan dan kompleksitas
  • Pengalaman ini dirangkum dengan fokus pada mengapa RSC diperlukan, cocok untuk kasus seperti apa, situasi apa yang membuatnya rumit, dan bagaimana membawanya secara bertahap ke codebase nyata

Masalah yang dituju RSC setelah CSR, SSR/SSG

  • Pendekatan server rendering awal dengan teknologi seperti PHP mengambil data di server dan menangani pekerjaan CPU yang berat, lalu mengirim HTML ringan ke klien
  • CSR/SPA mengirim kode rendering ke klien dalam bentuk JavaScript sehingga interaksi bisa diproses dengan cepat, tetapi kelemahannya terlihat saat mesin pencari tidak menjalankan JavaScript, saat rahasia harus tetap disimpan di server, atau saat menghadapi perangkat lemah dan koneksi lambat
  • SSR/SSG adalah pendekatan yang, lewat alat seperti Next.js dan Gatsby, menghasilkan HTML dan JavaScript bersama-sama di server lalu mengirimkannya ke klien
    • Pengguna bisa langsung melihat HTML
    • Saat JavaScript dimuat, situs menjadi interaktif
    • Mesin pencari juga bisa membaca HTML
  • Pada SSR/SSG lama pun masih ada biayanya
    • Sebagian besar JavaScript yang dipakai untuk membuat halaman tetap dikirim ke klien, dan diperlukan hydration agar klien menjalankannya kembali lalu menggabungkannya dengan HTML
    • Jika server rendering memakan waktu lama karena pemanggilan database yang lambat atau banyak eksekusi kode, pengguna harus menunggu

Apa yang diubah React Server Components

  • React Server Components adalah komponen React yang berjalan di server, bukan di klien
  • Framework yang mendukung RSC memungkinkan lokasi eksekusi kode dibagi secara eksplisit
    • Server Components: kode yang seharusnya hanya berjalan di server
    • Client Components: kode yang harus berjalan di klien
  • Ketika lokasi eksekusi dipisahkan, JavaScript yang dikirim ke klien berkurang, dan pekerjaan yang harus dilakukan saat hydration juga berkurang
  • Server Component dapat mengambil data langsung di dalam komponen
    • Bisa menggunakan library Node atau fetch
    • Kebutuhan mengambil data sekaligus di level halaman lewat getServerSideProps lalu terus meneruskannya lewat props bisa dikurangi
    • Kasus pengelolaan status loading yang rumit dengan useEffect juga bisa berkurang
  • Setelah pengambilan data selesai, Server Component dapat streaming hasilnya ke klien
    • Sisa situs bisa ditampilkan lebih dulu sambil menunggu komponen yang lambat
  • Dimungkinkan juga mengambil data di server sebagai respons terhadap aksi pengguna di klien lalu melakukan streaming respons, tetapi secara ketat itu bukan RSC melainkan React Actions

Bagian yang rumit dari RSC

  • CSS-in-JS saat ini tidak berjalan di Server Components
    • Dalam perpindahan Mux ke RSC, bagian terbesar dari pekerjaan adalah berpindah dari styled-components ke Tailwind CSS
    • Jika codebase sangat bergantung pada CSS-in-JS, dibutuhkan migrasi terpisah
  • React Context hanya bisa diakses dari Client Components
    • Untuk berbagi data antarsesama Server Components tanpa props, kemungkinan besar harus memakai modul biasa
    • Tidak ada mekanisme yang baik di Server Components untuk membatasi data hanya pada subtree tertentu dari aplikasi React
  • Di situs dokumentasi Mux, ini bukan masalah besar karena area yang memakai Context sudah sangat interaktif dan memang harus dikirim ke klien
  • Di situs marketing, berbagi tema menjadi masalah
    • Setiap komponen di pre-footer perlu tahu bahwa mereka berada di atas latar belakang hijau agar bisa memakai border hijau tua
    • Sebagai gantinya, mereka banyak memanfaatkan CSS custom properties
  • RSC memberi fleksibilitas pada lokasi eksekusi dan cara mengambil data, tetapi sebagai gantinya kompleksitas juga meningkat
    • Developer baru harus terus mengecek “apa yang berjalan di server dan apa yang berjalan di klien”
    • Di setiap PR muncul umpan balik tentang kode yang tanpa perlu dikirim ke klien
    • Selama pengembangan, sering perlu menaruh console.log untuk memastikan apakah log muncul dari server atau browser
    • Caching juga menambah kompleksitas tersendiri

Cara dasar memakai RSC di Next.js 13

  • Pada saat penulisan, implementasi RSC yang siap produksi adalah app directory di Next.js 13
  • Di app directory Next.js 13, komponen yang ditulis secara default adalah Server Component
    • Dalam keadaan default, kode halaman tidak dikirim ke klien
    • Hanya HTML yang dikirim ke klien
  • Jika Server Component diberi async, komponen itu bisa mengambil data di dalam dirinya sendiri
  • Server Component yang memiliki pengambilan data lambat bisa dibungkus dengan React.Suspense
    • Di klien, fallback UI ditampilkan lebih dulu
    • Setelah server selesai mengambil data dan merender, komponen hasilnya di-stream ke klien
  • Suspense boundary dapat dimanfaatkan bukan hanya untuk data streaming, tetapi juga untuk selective hydration yang menyesuaikan prioritas hydration area tertentu sesuai interaksi pengguna
  • Kode yang harus berjalan di klien ditandai dengan menambahkan "use client" di bagian atas file
    • Digunakan untuk komponen yang membutuhkan status klien dan interaksi seperti listener onClick atau useState
    • Semua komponen yang di-import oleh komponen bertanda "use client" juga akan dikirim ke klien
  • Library yang tidak mendukung RSC bisa di-import di Client Component dan dimasukkan ke bundle klien
    • Contohnya adalah komponen ClientMuxPlayer yang membungkus @mux/mux-player-react

Kriteria memilih Server Component dan Client Component

  • Server Components cocok untuk kode yang tidak perlu dikirim ke klien
    • Merender isi utama artikel blog
    • Pekerjaan berat seperti syntax highlighting pada code block
    • Pengambilan data
  • Client Components cocok untuk UI yang merespons input pengguna atau statusnya berubah seiring waktu
    • useState
    • Event listener
    • Interaksi sisi klien
  • Jika seluruh aplikasi dibuat dengan Client Components, perilakunya akan mirip framework SSR lama
  • Tidak perlu mengubah seluruh aplikasi menjadi Server Components sekaligus; bisa diadopsi bertahap mulai dari area yang memberi manfaat paling besar

Tiga tahap membawanya secara bertahap ke codebase nyata

  • Playbook yang dipakai Mux terdiri dari tiga tahap
    • Menambahkan directive "use client" di root aplikasi
    • Memindahkan directive itu serendah mungkin di dalam render tree
    • Menerapkan pola lanjutan saat masalah performa mulai terlihat
  • Pada tahap pertama, mereka menambahkan "use client" ke page.tsx paling atas di Next.js 13 agar aplikasi tetap berperilaku seperti sebelumnya
  • Jika perlu pengambilan data sisi server, Server Component ditambahkan sebagai parent dari Client Component
    • Server Component mengambil data
    • Data yang diambil diteruskan ke Client Component lewat props
    • Ini bisa menggantikan peran getServerSideProps yang lama
  • Pada tahap kedua, "use client" dipindahkan dari komponen paling atas ke komponen anak
    • Pada <Title /> yang tidak membutuhkan kode klien, directive bisa dihapus sehingga bisa dikirim sebagai HTML murni
    • Pada <Player /> yang membutuhkan kode klien, "use client" harus dipertahankan karena jika tidak akan terjadi error
  • Pendekatan ini mendorong tim untuk mempertimbangkan Server Components saat membuat komponen baru atau melakukan refactor, dan membantu mengurangi ukuran bundle sampai batas tertentu

Pola yang diterapkan saat ada masalah performa

  • Situs dokumentasi Mux sebagian besar dibuat secara statis, tetapi changelog sidebar diambil dari CMS
  • Jika sidebar dibungkus dengan Suspense, sisa aplikasi tidak perlu menunggu hingga fetch CMS selesai
  • Konvensi loading.js di Next.js 13 juga secara internal memakai Suspense dan streaming
  • Untuk mempertahankan library besar tetap berada di server, penempatan Client Components dan Server Components perlu diatur
    • Contohnya, library syntax highlighting Prism tetap dipertahankan di server

Cara mencampur Server Component di dalam Client Component

  • Komponen yang di-import oleh Client Component akan ikut menjadi Client Component
  • Jika ingin menempatkan Server Component sebagai anak dari Client Component, jangan meng-import-nya secara langsung; kirimkan lewat children atau props
    • Server Component dirender di server
    • Hasil yang sudah diserialisasi diteruskan ke Client Component
  • Cara yang salah adalah meng-import Server Component langsung di file Client Component
  • Cara yang benar adalah naik ke Server Component induk terdekat lalu meneruskan Server Component itu ke Client Component sebagai child atau prop

Tidak bisa membagi satu file setengah server/setengah klien

  • Tidak mungkin membuat separuh isi satu file menjadi Server Component dan separuh lainnya menjadi Client Component
  • Mux sering memakai pola memisahkan fitur ke dua file
    • CodeBlock.server.js: meng-import library syntax highlighting yang besar dan merendernya di server
    • CodeBlock.client.js: memakai useState dan onClick agar pengguna bisa mengganti contoh kode
  • Contoh-contoh yang dirender di server diteruskan ke Client Component lewat props, sehingga pekerjaan khusus server tidak bocor ke bundle klien
  • Jika CodeBlock.server.js diekspor ulang dari index.js, pengguna cukup meng-import CodeBlock tanpa perlu menyadari pemisahan server/klien di dalamnya

Cara memastikan kode hanya berjalan di server

  • Pada awalnya, saat pengembangan mereka menambahkan console.log untuk memeriksa apakah log keluar dari server atau browser
  • Untuk memastikan kode khusus server tidak ikut masuk ke bundle, bisa meng-import server-only package
  • server-only berguna agar library besar atau secret key tidak salah berpindah ke tempat yang tidak semestinya
  • Next.js menyediakan perlindungan agar environment variable tidak secara tidak sengaja masuk ke bundle browser
  • server-only di bagian atas file juga membantu pemeliharaan
    • Maintainer bisa langsung tahu bahwa file tersebut berjalan di server

Biaya dan manfaat saat menilai apakah perlu mengadopsinya

  • React Server Components bukan fitur yang didapat secara gratis
  • Biayanya tidak hanya keterbatasan CSS-in-JS dan React Context, tetapi juga mencakup hal-hal berikut
    • Memahami lokasi eksekusi server dan klien
    • Memahami hydration
    • Biaya infrastruktur
    • Kompleksitas kode akibat mencampur Client Components dan Server Components
  • Kompleksitas memperluas permukaan tempat bug bisa masuk dan menurunkan kemudahan perawatan kode
  • Framework membantu mengurangi kompleksitas, tetapi tidak menghilangkannya
  • Manfaat yang bisa diharapkan antara lain
    • Ukuran bundle yang lebih kecil
    • Eksekusi yang lebih cepat
    • Peningkatan performa yang penting untuk SEO
    • Pola data loading lanjutan untuk situs yang kompleks dan kaya data
  • Jika tim siap menanggung biaya kognitif tambahan dan manfaat performanya cukup besar, RSC bisa menjadi pilihan yang tepat

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-03
Komentar Hacker News

  • Dalam rendering sisi server, klien menerima HTML yang bisa langsung dilihat
    Saya juga merasakan ini: kalau mengunggah file teks polos ke server, file itu terkirim ke browser dengan cukup cepat
    Kalau mengunggah file teks polos lain yang berakhiran .css, browser tahu cara memprosesnya, sehingga elemen-elemen di tampilan awal bisa bergerak dan mungkin jadi cukup enak dilihat
    Memang trik yang keren, tetapi tetap saja sekunder dibanding konten berguna yang bisa dibaca di tampilan awal

    • Adik saya mulai belajar pengembangan web tahun ini, dan dia sangat terkejut ketika saya beri tahu bahwa HTML bisa dikirim lewat HTTP
    • Browser awalnya bermula sebagai klien hiperteks, tetapi entah bagaimana berevolusi menjadi platform aplikasi yang bahkan mengimplementasikan semacam klien hiperteks kustom di dalamnya
      Entah bagaimana “mari tambahkan fitur untuk membuat hiperteks lebih kuat” berubah menjadi “sekarang silakan implementasikan sendiri aplikasi yang layak pakai dengan tumpukan fitur besar dan tidak konsisten ini”
    • Berikutnya mau bilang bahwa kita juga bisa mengirim file teks yang menjalankan kode per halaman?
    • Saya kira teknologi seperti itu sudah hilang

  • Sebaiknya berhenti sejenak sebelum masuk ke RSC
    Apa pun yang ingin dibuat, semuanya bisa ditangani jauh lebih mudah, cepat, dan skalabel dengan framework full-stack sungguhan atau framework web klasik
    Bisa memakai Rails/Django/Laravel/… ditambah Turbolinks/Htmx/…, atau cukup menaburkan sedikit JavaScript di sisi klien
    Kalau mengenal Elixir/Phoenix, Anda juga bisa mendapatkan beberapa keunggulan sekaligus
    Sebanyak apa pun orang men-tweet, jangan turun lebih jauh ke RSC
    Orang-orang dengan pengalaman industri kurang dari 10 tahun akan mengulang masalah-masalah dasar yang dulu dialami situs vanilla PHP, dan saya bahkan sudah melihat hook SQL inline dimasukkan ke dalam komponen React
    Kali ini kompleksitas insidental yang menumpuk jauh lebih banyak
    Tetap waras saja, cepat rilis produk nyata, lalu hasilkan uang untuk membeli Lamborghini

    • RSC mengingatkan saya pada CORBA
      CORBA adalah cara mencampur komponen lokal dan komponen jarak jauh, sudah matang, dan berjalan di banyak bahasa
      Lalu kenapa tidak semua orang memakainya? Sebagian besar developer saat ini mungkin bahkan belum pernah mendengarnya
      Kalau ingin membuat arsitektur komponen terdistribusi lain, perlu mempelajari mengapa CORBA dan turunannya tidak berhasil menjadi arus utama
      Petunjuknya adalah batas komponen yang tersembunyi menciptakan kompleksitas tersembunyi
      Di sisi lain, kubu “HTML yang dirender server” dan “HTML yang dirender klien” sama-sama berjalan dengan baik
      Menurut saya cukup beruntung bahwa setiap proyek web bisa memakai kedua pilihan itu
      Saya berharap pekerjaan RSC tidak mengaburkan dukungan React untuk aplikasi yang murni dirender di klien
      1. https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
    • Kalau mengenal Elixir/Phoenix, ini benar sekali
      Jika yang dibutuhkan bukan aplikasi frontend kaya yang progresif secara penuh, sebagian besar hal bisa ditangani LiveView lewat komponen sisi server dengan JavaScript seminimal mungkin
      Selain itu, setiap pengguna mendapatkan thread di sisi server, sehingga perubahan bisa didorong secara aktif ke frontend pengguna tanpa harus menulis handler JavaScript eksplisit
    • Ini benar-benar tepat
      Industri ini seperti terkena amnesia siklus 10 tahun
      Ada alasan yang sangat kuat mengapa kita menjauh dari UI yang dirender server
      Tentu selalu ada argumen optimasi mesin pencari, tetapi kalau itu yang dikhawatirkan, buat saja situs template server tradisional
      Mayoritas aplikasi satu halaman sama sekali tidak membutuhkan SSR dan kompleksitasnya
    • Saya karyawan Mux, dan sebagai fakta menarik, Elixir sejak awal merupakan komponen inti infrastruktur kami
      Antarmuka dasbor awal semuanya dirender dengan Phoenix, dan hanya halaman yang benar-benar membutuhkan interaksi klien tingkat lanjut yang menyertakan React secara terpisah
      Karena produk pertama kami adalah dasbor analitik, situasi itu segera membuat hampir seluruh dasbor menjadi seperti itu, dan memindahkannya ke aplikasi satu halaman penuh dengan memanfaatkan API yang kami ekspos ke pelanggan terasa alami
      Saat itu tahun 2016, jadi LiveView belum ada, tetapi saya tidak yakin apakah kami akan mengambil keputusan berbeda jika membangun ulang produk itu sekarang
      Artikel blog tersebut membahas aplikasi yang menjalankan situs pemasaran publik dan kebutuhannya cukup berbeda, tetapi saya ingin mengatakan bahwa kami juga memakai dan menyukai Elixir/Phoenix

  • Rasanya saya makin tua
    Framework zaman sekarang terlalu besar dan rumit
    Bahkan web “Hello world” yang sederhana pun butuh pipeline build dan kompilasi yang besar, dan sekarang ditambah lagi dengan komponen sisi server
    Saya benar-benar penasaran seberapa besar overhead-nya
    Entah berapa lapis kode framework frontend dan backend yang harus dilewati hanya untuk menjalankan contoh Hello world
    Saya akan kembali ke framework komponen sederhana berukuran 10KB yang cukup tekan F5 untuk build ulang

    • Framework seperti ini tidak dibuat untuk menyelesaikan aplikasi Hello world sederhana
    • Banyak situs web rasanya akan lebih baik dalam segala hal kalau dibuat hanya dengan HTML dan CSS, dan itu membuat frustrasi
      Ini seperti mengoptimalkan terlalu dini demi fitur-fitur mewah yang mungkin saja baru muncul nanti
      Mirip seperti mengatakan bahwa sebelum membangun kandang ayam, kita harus mempekerjakan insinyur untuk mengambil sampel inti tanah dan melakukan pemodelan gelombang seismik
    • Justru karena itulah mulai terlihat gerakan untuk menjauh dari kompleksitas
      Developer muda sekarang mulai menyadarinya
      Sama seperti kita dulu meninggalkan hal-hal mengerikan seperti SOAP dan XML lalu beralih ke teknologi yang lebih sederhana dan mudah digunakan, generasi ini juga sedang belajar lagi bahwa kompleksitas itu berbahaya
      Mungkin pengembangan software akan kembali menyenangkan, setidaknya selama beberapa tahun sebelum generasi baru mengacaukannya lagi
    • Sudut pandang seperti ini benar-benar menyebalkan
      Pipeline bisa dibuat serumit atau sesederhana yang diperlukan untuk kasus penggunaan tertentu
      Bisa saja dibuat hanya dengan file statis, bisa juga dengan Makefile kecil yang memakai satu perintah esbuild, atau konfigurasi Webpack raksasa dengan 30 plugin
      Anda bebas memilih sesuai kebutuhan dan kompleksitas dari apa yang ingin dibuat
      Selain itu, menilai tool berdasarkan mudah tidaknya membuat Hello world sederhana hanya berguna kalau pekerjaan yang sebenarnya memang membuat aplikasi semacam itu
    • Tulisan blog ini membahas SSR lebih baik daripada sebagian besar tulisan yang pernah saya lihat
      Setiap kali SSR atau turunannya masuk ke percakapan, saya selalu bertanya-tanya apakah ini tidak membuat segalanya jadi lebih rumit tanpa perlu
      Komponen rendering server React terdengar seperti sudah terlalu jauh, dan bertentangan dengan alur pengalaman developer yang alami
      Kalau kompleksitas aplikasi menjadi dua kali lipat, jebakan saat coding bertambah sehingga developer melambat dan bingung, sementara yang didapat hanya peningkatan performa kecil, saya ragu itu sepadan
      Situs PHP lama dan aplikasi Rails tanpa single-page app juga sudah lama berjalan dengan baik

  • Saya punya pengalaman saat membuat aplikasi baru dengan Next.js dan struktur direktori app yang baru
    Pertama, sulit menalar apa yang terjadi di server dan apa yang terjadi di klien
    Untuk mengetahuinya harus diselidiki, tetapi saat menulis kode dengan cepat, biasanya hal itu tidak terlalu diperhatikan
    Perubahan kecil saja bisa dengan mudah membuat bagian besar dari halaman tiba-tiba ingin berpindah dari server ke klien
    Saya tahu sebelum rilis final nanti perlu verifikasi yang hati-hati dan memakan waktu untuk tiap halaman, dan itu tidak menyenangkan
    Kedua, cukup banyak library React yang sudah ada menggunakan hook sehingga diasumsikan berjalan di klien
    Akibatnya, kode bisa ikut tertarik ke klien
    Tujuan melawan paradigma baru ini adalah server-side rendering demi loading cepat dan optimasi mesin pencari, tetapi kalau library yang diimpor tidak bekerja sama dengan baik, semuanya jadi sia-sia
    Ketiga, paradigma direktori app Next.js yang baru masih punya bug
    Karena masih baru dan sangat kompleks, route dinamis, route paralel, serta interaksi di antara keduanya bisa benar-benar rusak
    Saya sendiri membuka issue di GitHub Next.js, dan banyak komentar “saya juga” bermunculan
    Salah satu pendekatan yang saya pakai baru-baru ini diperbaiki oleh developer Vercel, tetapi saat itu saya sudah memilih pendekatan lain untuk mengakalinya
    Hal yang paling menyebalkan adalah lingkungan development memakai lazy loading dan sihir caching
    Sepertinya ia mencoba menghitung perbedaan halaman lalu mengirim update parsial lewat semacam WebSocket, tetapi bisa rusak total sampai tidak bisa dipulihkan
    Kadang recompilation memicu semacam komunikasi dari server ke klien, dan saat kembali ke tab Chrome, tab itu benar-benar membeku sehingga prosesnya harus dimatikan lewat Chrome Task Manager
    Secara keseluruhan, ini masih sangat baru dan masih memiliki banyak sudut kasar

    • Bagian “cukup banyak library React yang sudah ada menggunakan hook sehingga diasumsikan berjalan di klien” itu maksudnya bukan hook, melainkan context?
      Banyak hook juga berjalan di sisi server, dan pada praktiknya tidak melakukan apa-apa selain menginisialisasi nilai

  • Menarik bahwa PHP dan JavaScript sebenarnya punya sintaks yang nyaris sama
    Perbedaannya hanya sekitar simbol $ atau kata kunci var, tetapi NodeJS mengatakan “kami ingin menjalankan JS di server”
    Lalu 15 tahun kemudian JavaScript akhirnya mengejar dan pada dasarnya menjadi mirip PHP, hanya saja dengan lebih banyak singkatan dan kurva belajar yang lebih curam
    Tentu saja, streaming data dari server ke komponen klien dengan Suspense itu keren
    Saya memakai NextJS 13, dan saya suka karena ia membuat SSR semudah yang selama ini selalu mungkin di PHP; sangat saya rekomendasikan

    • Agar adil, sebelum PHP 7, tergantung zamannya, PHP adalah tempat sampah atau sesuatu yang lebih berbahaya
      Ketika orang menyebutnya “fraktal dari desain buruk”, itu 100% pantas, dan masuk akal juga kalau mereka mencari tempat lain untuk memecahkan masalah
      PHP hari ini adalah bahasa yang jauh lebih baik dan layak dilihat lagi, tetapi kita tidak boleh berpura-pura bahwa sejak dulu PHP sudah sebagus sekarang
      Dan jangan menilai NodeJS berdasarkan ekosistem React
      Jumlah API dan wrapper yang luar biasa besar yang diperlukan untuk menjalankan sistem berbasis React adalah tanggung jawab komunitas React
      Ini sindrom Stockholm yang klasik
    • PHP tidak punya client-side rendering, jadi ini perbandingan yang aneh
    • Orang sering mengabaikan bahwa browser itu sendiri juga sudah banyak membaik
      Banyak kemajuan modern menjadi mungkin karena browser membaik terlebih dahulu
      Ini bukan benar-benar kembali ke titik awal sepenuhnya, melainkan lebih seperti gumpalan yang dari jarak sangat jauh terlihat seperti lingkaran
    • Saya tidak pernah menyukai NodeJS
      Di satu sisi, ia inovatif karena model konkurensinya memungkinkan pembuatan backend yang lebih cepat, tetapi banyak fitur dari bahasa backend yang sudah ada seperti Java atau PHP tidak ada, sehingga banyak pola ditemukan ulang
      Bahasanya sendiri juga butuh bertahun-tahun untuk mencapai tingkat “keamanan” yang sudah dimiliki Java dan sedang dituju PHP
      Teknologi yang sudah teruji dan distandardisasi seperti XML, beserta jaminan kontraktual yang bisa diberikannya, juga ditinggalkan dengan alasan seperti terlalu berat dan JSON lebih enak dibaca dan ditulis manusia
      Saya merasa banyak waktu dan upaya hilang karena meninggalkan XML
      Dokumentasi REST/JSON API masih menyakitkan
      20–25 tahun lalu, dari payload XML kita sudah bisa menghasilkan model data dan parser
      Sampai sekarang saya masih tidak tahu apa yang begitu bermasalah dari XML
      Di jalur transmisi memang sedikit lebih berat daripada JSON, tetapi itu masalah yang bisa diselesaikan dengan kompresi atau mengubahnya menjadi protokol biner lewat EXI(https://www.w3.org/TR/exi/)
      Saya tidak tahu apakah EXI benar-benar mendapat tempat, tetapi saat itu saya cukup berharap karena tahu seberapa banyak XML yang lalu-lalang
    • Sepertinya banyak alasan awal NodeJS dibuat sudah dilupakan
      Saat itu, I/O non-blocking memberikan peningkatan performa besar
      Namun di benak pengembang modern, tampaknya ia tersisih menjadi sekadar alat bodoh untuk memuntahkan JSON atau meng-host toolchain

  • Mungkin karena memakai yang sudah familier, tetapi menggunakan React untuk situs dokumentasi alih-alih static site generator siap pakai atau CMS dengan caching terlihat seperti pemborosan
    Dari sudut pandang pengembang, React mungkin memang lebih menyenangkan

    • Situs dokumentasi yang bagus punya banyak bagian dinamis kecil
      Stripe memulai alur yang menampilkan potongan kode berisi API key akun sehingga bisa langsung diuji
      Situs dokumentasi frontend hampir selalu berisi contoh yang bisa dijalankan dan dicoba langsung di dalam dokumentasi
    • Saya sering mendengar hal ini, tetapi sulit memahaminya
      Bootstrap proyek baru itu sangat mudah dan cepat, secara harfiah lebih mudah daripada memulai proyek HTML murni
      Apa yang saya lewatkan?
      Selain itu, saya sungguh penasaran dengan sudut pandang orang-orang yang menekan downvote
    • Setuju
      Ini konten statis, jadi saya tidak paham kenapa tidak dihasilkan saja sebagai HTML dengan sedikit JavaScript untuk kotak pencarian
    • Itu memang dihasilkan secara statis
      Alasan memakai React adalah agar menggunakan satu bahasa di seluruh frontend
      Ini menghindari perpecahan seperti sebagian orang memakai React di satu situs, sementara yang lain memakai Gatsby/Hugo
      Next.JS bisa melakukan hal yang sama seperti Gatsby/Hugo, dengan fitur lebih banyak dan berbasis React
    • “Lebih menyenangkan bagi pengembang” sebenarnya adalah kutukan bagi pengembang perangkat lunak maupun pemberi kerja

  • Saya cukup tua untuk mengingat masa ketika server merender segalanya, sementara CSS dan Javascript dipakai untuk memperkaya halaman yang sudah dirender
    Web sudah menjadi tempat yang terlalu gelap dan terlalu direkayasa
    Hampir sulit dipercaya
    Jadi cara saya membuat aplikasi adalah server rendering dulu, lalu memperkayanya belakangan

    • Secara umum setuju
      Dropdown yang bisa dilipat atau drag-and-drop jQuery memang fitur yang menyenangkan, tetapi saya juga masih jelas mengingat neraka manajemen state pada era js/jQuery, dan saya tidak ingin kembali ke sana
    • Kamu pakai JavaScript?
      Bercanda, halaman Geocities pertama saya hanyalah HTML dengan hal-hal seperti penghitung pengunjung atau marquee
      Aplikasi/proyek PHP pertama yang saya buat di sekolah juga belum memakai JS; untuk menu dan header statis saya memakai frame, dan data dikirim ke backend hanya lewat submit form
      Memang ada masa seperti itu
      Pada magang satu tahun pertama yang menjadi bagian dari kurikulum kuliah, kami memakai backend Java, template JSX di lapisan presentasi, dan PrototypeJS untuk hal-hal seperti dialog atau accordion beranimasi
      Saat itu animasi berarti “mengubah tinggi elemen ini beberapa kali per detik”
      Di pekerjaan pertama, saya banyak memakai JS untuk memperkaya halaman, seperti memasukkan barang ke keranjang atau carousel gambar, dan itu adalah era jQuery
      Di pekerjaan berikutnya, kami membuat dengan buruk UI berbasis BackboneJS untuk staf dukungan pelanggan yang melihat-lihat sesuatu seperti SAP
      Pekerjaan setelah itu juga membangun ulang frontend investment banking untuk pelanggan dengan BackboneJS
      Itu adalah use case yang sangat cocok untuk apa yang saat itu disebut aplikasi satu halaman
      Tidak perlu optimasi mesin pencari, rendering frontend murni sudah cukup cepat, berpusat pada API, dan itu adalah masa ketika orang mulai menyadari bahwa API yang sama bisa dipakai untuk web dan mobile
    • Dari sudut pandang lain, saya juga ingat masa ketika CSS dan Javascript diciptakan, dan sejak saat itu saya sudah membuat website
      Menurut saya, tool pengembangan web belum pernah sebaik sekarang, dan pengalaman pengguna juga meningkat luar biasa selama bertahun-tahun
      Apa yang dulu kita sebut AJAX tumbuh dari mainan tambahan yang rapi menjadi elemen dasar sehari-hari dalam bentuk client component dan single-page app
      Server tetap kuat jika kita menginginkannya, tetapi untuk aplikasi interaktif seperti dashboard, peta, game, forum, aplikasi office, dan IDE online, kemampuan sisi klien yang kuat itu bagus
      Berkat ini, aplikasi sehari-hari bisa berpindah besar-besaran dari aplikasi desktop khusus tiap sistem operasi ke platform universal yang mencakup semua laptop dan desktop
      Tentu saja, kekuatan itu membutuhkan lebih banyak kompleksitas
      Menulis blog atau landing page dengan HTML/CSS sangat berbeda dari menulis aplikasi web utuh
      Angular dan React dibuat untuk membantu pengembangan aplikasi yang beberapa kali lebih kompleks dari sebelumnya, pada masa ketika runtime JS dan bahasanya sendiri jauh lebih primitif dibanding bahasa server-side saat itu
      Pada akhir 2010-an, ada periode yang benar-benar menyakitkan ketika berbagai framework JS hanya menyelesaikan bagian yang sangat kecil dari masalah
      Sekarang tidak separah itu
      Next menang dan menjadi default, dan itu pantas
      Ia menyediakan tingkat abstraksi yang tepat untuk aplikasi dengan kompleksitas menengah, serta memungkinkan kita mencampur server-side rendering dan halaman client-side dengan baik
      React server component membuat pemisahan itu menjadi konsep kelas satu yang lebih rapi
      Namun itu hanya masuk akal di atas tingkat kompleksitas tertentu
      Jika tidak perlu, tidak usah dipakai
      Jika itu blog atau situs dokumentasi yang sebagian besar statis, ada arsitektur yang lebih sederhana
      Kita masih bisa menulis HTML dan menyisipkan beberapa baris JS seperlunya, dan untuk sebagian besar bisnis kecil juga bisa memakai WordPress atau Wix
      Namun jika membuat aplikasi yang lebih kompleks, dibanding pendekatan lama yang bolak-balik ke server untuk setiap interaksi kecil guna menghitung ulang UI dan mengirim seluruh halaman HTML setiap kali, React benar-benar terasa seperti mimpi
      Pendekatan seperti itu membuat kita kehilangan konteks, posisi halaman, form yang sudah terisi sebagian, dan sebagainya; mendorong penggunaan data form sebagai state; serta sering membuat pekerjaan hilang karena tidak sengaja menekan tombol kembali atau karena gangguan server yang sering terjadi sebelum scaling cloud yang mudah tersedia
      Menurut saya, itu baru overengineering ketika diterapkan secara salah
      Pada use case yang tepat, tool seperti ini benar-benar berguna dan kadang penting
      Bagian yang disayangkan mungkin adalah terlalu banyak diajarkan dan dianjurkan untuk dipakai bahkan dalam situasi ketika tidak perlu atau justru merugikan
      Pada akhirnya, gunakan tool yang sesuai dengan pekerjaan
      Saya bukan bermaksud mendorong React di atas Vue, Svelte, atau HTMX, melainkan bahwa kompleksitas sisi klien juga ada gunanya
    • Justru pendekatan ini, yaitu server component, memang dibuat untuk itu

  • Saya mendapat kesan React sedang berusaha mengejar alternatif-alternatif yang lebih modern, mudah, cepat, dan murah
    Namun alih-alih memperbaiki masalah mendasar seperti rerendering, memoization yang sering diperlukan, dan abstraksi yang bocor, React justru menjadi semakin kompleks
    Kalau hasil akhirnya hebat, saya bisa memahami upaya itu, tetapi kenyataannya tidak begitu
    React di lingkungan nyata lebih lambat daripada yang ditunjukkan benchmark, dan Next bahkan lebih parah
    Belakangan ini saya melihat banyak website sangat lambat yang dibuat dengan Next
    Saya benar-benar tidak mengerti
    Jika tim React ingin memperbaiki React, mereka harus memperbaiki inti-nya

    • Mereka tidak bisa memperbaikinya
      Sekarang sudah terlalu banyak dependensi ekosistem sehingga akan rusak
      Target.com, Walmart.com, Microsoft Teams, dan tak terhitung banyaknya situs memakai React
      Ada juga ekosistem komponen yang sangat besar dan perusahaan-perusahaan yang dibangun di atasnya
      Konsep intinya rusak, tetapi memperbaikinya berarti bisa merusak semua yang lain
      Kalau pada akhirnya semuanya akan dirusak juga, lebih baik memakai yang lain
      Sekarang, karena massa dependensi, mereka terikat pada React dan mau tidak mau harus terus menggelinding
      React menjadikan rerendering sebagai default lalu kita harus opt out, sedangkan Vue, Solid, Preact, dan Svelte semuanya bekerja dengan cara opt in di tempat yang diperlukan
      Ini adalah salah satu alasan utama mengapa sulit dipakai dengan benar dan rentan terhadap jenis bug tertentu
      Dari luar tampak seperti JavaScript biasa, tetapi kita harus terus memperhatikan apakah perlu opt out, sementara di framework lain bug seperti itu jarang atau hampir tidak ada
    • Untuk rerendering dan memoization yang sering diperlukan, ada pekerjaan ini
      https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...

  • Saya tidak mengerti kenapa sekarang baru memakai React di backend untuk merender HTML
    Apa kita mau kembali ke 10 tahun lalu?

    • Bahwa “lingkungan itu” memiliki sistem template benar-benar bernilai besar
      Belakangan ini saya sering bolak-balik antara Svelte dan template Django, dan Svelte jauh lebih enak dipakai hanya karena ia memahami DOM
      Saya belum pernah melihat hal seperti ini di sistem template non-JS
      Saya juga pernah mengalami PHP, jQuery, dan sebagainya
    • Model pemrograman React menarik bagi banyak orang, dan React cocok untuk masalah yang memiliki output yang dapat diprediksi seperti HTML
      Selain itu, jika frontend-nya React, jauh lebih mudah menaruh semua pembuatan HTML di satu tempat
    • Developer “senior” berusia 25 tahun butuh teknologi lama untuk dijatuhkan demi menopang ego mereka, dan PHP menjadi sasarannya
    • Karena Vercel ingin meng-host backend Anda dan sedang merambah React
    • Lebih baik daripada sebagian besar sistem template lain, dan saat ingin menambahkan interaksi, bagus karena bisa ditangani dengan satu bahasa dan paradigma
      Ditambah lagi ada dukungan tipe statis

  • Saya tidak bermaksud membela bahwa RSC atau React adalah solusi terbaik sepanjang masa, tetapi sebagian bantahan di sini belum matang
    Manfaat React/RSC secara teknis tidak sama dengan server yang mengembalikan HTML/CSS dan sedikit JavaScript
    Ini tetap satu aplikasi, dan dibandingkan SSR/hydration, ini adalah cara yang menangani batas klien/server dengan lebih cerdas
    Saya tetap ingin membaca sebanyak mungkin bantahan yang lebih paham tentang apakah React merancang dirinya sendiri ke jalan buntu dan apa jalur keluarnya, tetapi kembali ke PHP bukan jawabannya

    • Belakangan ini HN bukan tempat yang bagus untuk mendapatkan sudut pandang frontend yang benar-benar paham
      React juga tidak sesulit itu untuk dipelajari, dan ada alasan mengapa non-developer pun bisa mempelajari dasarnya dalam beberapa minggu bootcamp
      JSX secara objektif lebih unggul daripada sistem template Django, PHP, dan Rails
      Setengah dari bantahan yang asal lempar itu sepertinya bahkan belum pernah mem-benchmark proyek mereka sendiri dengan alat seperti Lighthouse