- 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
- Beralih dari Next.js ke React menggunakan TanStack Router dan Rspack
- 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
- Next.js 15 (menggunakan mode Turbo)
- 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
- Yang hilang
- 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
Saat perusahaan kami sedang bersiap menyatukan/memigrasikan frontend ke Next.js, membaca tulisan seperti ini benar-benar membuat saya banyak berpikir....
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...
"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.
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…
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:
Saya kurang paham, tapi sepertinya ada perbedaan waktu build yang cukup besar.
Sepertinya Anda masih belum tahu bahwa React dalam banyak hal masih lebih lambat dibanding framework lain.
Karena kecepatan tidak terlalu penting. Kalau kecepatan penting,
expressjsmungkin tidak akan masih digunakan. Komunitas dan pustakanya jauh lebih banyak.Sepertinya fokusnya memang pada migrasi dari Next ke React, ya haha
Karena komunitas React meninggalkan CRA di tahap awal dan beralih ke framework, saya tidak yakin apakah menentang arus ini merupakan pilihan yang mudah.
Kebanyakan sudah pindah ke Vite, dan framework masih kami gunakan sesuai kebutuhan bahkan sampai sekarang
Begitulah yang dikatakan di react.dev~
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.
"Sederhana" <= untuk mencapai ini, ada keajaiban(?) tersembunyi yang memicu banyak trade-off.
Saya setuju. Ada banyak sekali dependensi besar yang tersembunyi di balik Next.js...
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.jsCodebase 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 indahSaya 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
k8s untuk aplikasi dengan 5 pengunjung... luar biasa sekali