23 poin oleh GN⁺ 2025-01-03 | 17 komentar | Bagikan ke WhatsApp
  • Hasil yang diperoleh setelah memigrasikan dashboard ComfyDeploy dari Next.js ke React:
    • Waktu build dipangkas dari 3 menit → 18 detik
    • Hot reload membaik menjadi di bawah 200ms
    • Anggota tim jauh lebih puas
  • Awalnya dimulai sebagai aplikasi full-stack dengan Next.js, dan berkat Drizzle serta Server Actions, aplikasi berjalan baik dengan type safety dan kode yang rapi, tetapi muncul masalah berikut:
    • Biaya API yang tinggi di Vercel sebesar $2.000 akibat pengguna tertentu
    • Kompleksitas pengujian API meningkat: Server Actions dan rute API bercampur
    • Waktu build lambat dan lingkungan pengembangan lokal yang tidak efisien
    • Bahkan perubahan kecil memicu reload SSR penuh
  • Masalah
    • Kompleksitas Next.js meningkat: pendekatan all-in-one (full-stack) Next.js menimbulkan kompleksitas pengembangan seiring pertumbuhan aplikasi
    • Dashboard kami pada dasarnya berbasis React, dan tidak memerlukan fitur server dari Next.js
  • Peralihan dari Next.js ke React
    • Beralih dari Next.js ke React menggunakan TanStack Router dan Rspack
      • Server pengembangan mulai dalam waktu kurang dari 2 detik
      • Waktu build di Vercel: 18 detik
    • Konfigurasi API ditingkatkan, dependensi yang tidak perlu dihapus, dan kode disederhanakan sehingga produktivitas meningkat
  • Perbandingan performa
    • Next.js 15 (menggunakan mode Turbo)
      • Build halaman pertama: 10,4 detik
    • React + TanStack Router + Rspack
      • Perhitungan route: di bawah 200ms
      • Build bundle awal: 1,67 detik
  • Trade-off
    • Yang hilang
      • Co-location kode frontend dan backend: dengan memisahkan frontend dan backend, batasnya menjadi lebih jelas
      • Fitur caching Next.js: karena banyak data diperbarui secara real-time, diganti dengan caching kustom
      • Pre-rendering dan initial load: alih-alih Static Generation, diterapkan UX yang lebih baik - tidak ada lagi tombol nonaktif yang ditampilkan
      • Server Components dan Actions: kehilangan "keajaiban" server component, tetapi membaik lewat desain API yang lebih disengaja
    • Yang didapat
      • Desain kontrak API yang lebih kuat
      • Caching diimplementasikan hanya di tempat yang diperlukan
      • Alur data dan manajemen state dirancang dengan lebih cermat
  • Kesimpulan
    • Next.js cocok untuk pekerjaan seperti landing page dan SEO, tetapi untuk sebagian besar produk menimbulkan kompleksitas yang berlebihan
    • Untuk pekerjaan landing page dan SEO, kami tetap menggunakan Next.js
    • Dashboard dipindahkan ke Pure React + TanStack Router + Rspack
    • API menjalankan server Python FastAPI di Google Cloud Run dan melakukan autoscaling sesuai kebutuhan
  • Memilih alat yang tepat itu penting, dan bagi kami Next.js adalah pilihan yang berlebihan

17 komentar

 
zerocyber 2025-01-04

Saat perusahaan kami sedang bersiap menyatukan/memigrasikan frontend ke Next.js, membaca tulisan seperti ini benar-benar membuat saya banyak berpikir....

 
nemorize 2025-01-04

Kami hanya mengoperasikan layanan yang memungkinkan pendekatan mobile-"app"-first,
jadi untuk area yang memerlukan SEO, kami sama sekali tidak menggunakan React (atau sesuatu yang mirip dengannya) dan menjaganya tetap sangat ringan.
Web hanya digunakan untuk menarik trafik SEO, lalu mengarahkan pengguna ke aplikasi...

 
beenzinozino 2025-01-04

"Memilih alat yang tepat itu penting, dan bagi kami Next.js adalah pilihan yang berlebihan."

Sepertinya kalimat terakhir itulah inti pesannya.

Untuk memilih alat yang tepat, rasanya penting juga untuk mengalami banyak kegagalan seperti ini dan itu.

 
iolothebard 2025-01-03

Kalau butuh SEO, berarti konten adalah inti,
namun karena komponen UI(?) dan state justru mengambil porsi inti… maka lahirlah makhluk aneh seperti SSR, ISR, Hydrate…

 
schang124 2025-01-03

Saya sangat setuju dengan isinya.
Saya pribadi sama sekali tidak akan mengadopsi Next.js kecuali memang membutuhkan SEO.
Seperti pada tulisan di atas, jika hanya menggunakan React ada banyak kelebihan:

  • Kompleksitas dan pola khas Next.js yang tidak perlu jadi hilang.
    • Maintenance menjadi lebih sederhana
  • Terbebas dari pengeluaran biaya SSR yang tidak perlu
  • Pilihan terhadap library yang termasuk FE infra seperti router, bundler, dan lain-lain menjadi lebih luas
 
jhj0517 2025-01-03

Saya kurang paham, tapi sepertinya ada perbedaan waktu build yang cukup besar.

 
bichi 2025-01-03

Sepertinya Anda masih belum tahu bahwa React dalam banyak hal masih lebih lambat dibanding framework lain.

 
slowandsnow 2025-01-03

Karena kecepatan tidak terlalu penting. Kalau kecepatan penting, expressjs mungkin tidak akan masih digunakan. Komunitas dan pustakanya jauh lebih banyak.

 
devheerim 2025-01-03

Sepertinya fokusnya memang pada migrasi dari Next ke React, ya haha

 
bbulbum 2025-01-03

Karena komunitas React meninggalkan CRA di tahap awal dan beralih ke framework, saya tidak yakin apakah menentang arus ini merupakan pilihan yang mudah.

 
sacru2red 2025-01-03

Kebanyakan sudah pindah ke Vite, dan framework masih kami gunakan sesuai kebutuhan bahkan sampai sekarang

 
bbulbum 2025-01-06

Jika Anda membangun aplikasi baru atau seluruh situs dengan React, kami merekomendasikan penggunaan framework.

Begitulah yang dikatakan di react.dev~

 
kandk 2025-01-03

Menarik juga. Apakah Next lebih berat dibanding React?
Saya baru pernah mencoba menyiapkan proyek dengan Next, dan saat itu pembangunan proyek serta mulai pengembangannya terasa sangat sederhana.

 
cichol 2025-01-03

"Sederhana" <= untuk mencapai ini, ada keajaiban(?) tersembunyi yang memicu banyak trade-off.

 
beenzinozino 2025-01-04

Saya setuju. Ada banyak sekali dependensi besar yang tersembunyi di balik Next.js...

 
GN⁺ 2025-01-03
Komentar Hacker News
  • Banyak orang terlalu fokus pada apakah sebuah ide bisa diskalakan ke miliaran pengguna. Karena itu, ada yang memakai Kubernetes padahal situs webnya cuma punya 5 pengunjung. Saya juga pernah melihat mahasiswa memakai Next.js untuk membuat situs web yang sebenarnya bisa ditulis cukup dengan HTML + CSS sederhana

  • Saya pernah membangun proyek dengan Next.js, tetapi terasa rumit untuk digunakan. API akses cookie berbeda antara klien dan server, dan hal-hal seperti harus mengakses variabel lingkungan lewat process.env.NEXT_PUBLIC_* juga membingungkan. Saya ingin menulis kode yang bisa berjalan di klien dan server dengan perubahan seminimal mungkin, tetapi kenyataannya tidak begitu. Rasanya pembelajaran dan overhead-nya tidak sepadan dengan apa yang diberikan Next.js

  • Codebase menjadi lebih sederhana dan rendering halaman jadi lebih cepat. Sayang sekali komunitas terdorong secara tidak perlu ke framework seperti ini. Kebanyakan orang hanya butuh npx rsbuild init. Dengan rspack dan rsbuild, saya mendapatkan router sederhana dan kesederhanaan yang indah

  • Saya sudah menggunakannya sejak rilis Next.js v14, dan sangat puas. Dengan RSCs, banyak bagian aplikasi tetap berfungsi dengan baik bahkan saat JS sisi klien dimatikan. Ia punya kekuatan sederhana seperti aplikasi PHP, sekaligus bisa memasukkan type system dan komponen klien interaktif berbasis state secara mulus di "level daun" pada view tree

  • Berkat Rails dan Hotwire, saya bisa lepas dari kekacauan ekosistem React. Ada terlalu banyak pilihan seperti library manajemen state, meta-framework, library data fetching, dan sebagainya. Tidak perlu membuat pekerjaan sederhana seperti menampilkan data dari server ke halaman menjadi rumit

  • Saya bekerja pada CMS yang menggunakan NextJS (PayloadCMS), dan NextJS adalah teknologi terburuk yang pernah saya pakai

  • Hampir semua proyek yang memakai framework/library frontend berat seperti Next.js, React, dan Vue akan lebih baik jika menggunakan library yang merender template di backend. Kadang rendering sisi klien lewat EJS memang masuk akal. Saya jadi bertanya-tanya kenapa framework semacam itu dipakai

  • Saya menggunakan Next.js untuk SEO dan optimasi crawling. Jika halaman tidak perlu dirayapi crawler (misalnya dashboard di balik login), Next.js tidak diperlukan dan React murni akan lebih sederhana

  • Saya heran Next.js bisa menjadi opsi awal standar. Rasanya seperti perubahan besar dibandingkan 2~3 tahun lalu

  • Saya sedang mencoba mengganti aplikasi NextJS dengan Vike, dan sejauh ini puas. Saya bisa membangun dengan cara yang saya inginkan tanpa banyak gangguan

 
aer0700 2025-01-03

k8s untuk aplikasi dengan 5 pengunjung... luar biasa sekali