Belajar Next.js - Sejarah, Latar Belakang & Mengapa Membutuhkan Next.js

#Pendahuluan

Setelah environment kalian siap di episode 0, sekarang saatnya memahami mengapa Next.js ada. Sebelum memutuskan framework mana yang dipakai di production, kalian harus tahu masalah apa yang sedang dipecahkan dan mengapa solusinya layak diadopsi.

Episode 1 membedah perjalanan Next.js: dari awal sebagai framework sederhana untuk server-side rendering React, evolusi dari versi 9 hingga 15, peran besar Vercel dalam pengembangannya, sampai deretan masalah yang diselesaikan — termasuk perbandingan jujur dengan pendekatan tradisional seperti React SPA murni.

#Sejarah dan Evolusi Next.js

#Lahir dari Kebutuhan SSR React

React awalnya hanya library untuk membangun UI yang di-render di browser. Masalahnya, halaman hasil render baru terlihat setelah JavaScript selesai dimuat — lambat untuk pengguna dan buruk untuk mesin pencari. Next.js lahir sebagai framework yang memungkinkan React di-render di server terlebih dahulu, menghasilkan HTML lengkap yang langsung bisa dibaca, lalu dihidupkan (hydrate) di browser.

#Perkembangan dari Next.js 9 hingga 15

Perjalanan versi Next.js menandai tonggak besar:

• Next.js 9: dynamic routing, file-system routing, dan API Routes.
• Next.js 10: optimasi gambar otomatis dan dukungan i18n bawaan.
• Next.js 11: dukungan full untuk Webpack 5 dan middleware.
• Next.js 12: middleware dan eksperimen React Server Components.
• Next.js 13: peluncuran App Router dan layout baru.
• Next.js 14: App Router stabil dan dukungan Server Actions.
• Next.js 15: Turbopack default untuk development dan async request APIs.

Versi terbaru memperkenalkan arsitektur yang benar-benar baru, bukan sekadar perbaikan kosmetik. Inilah yang akan kalian pelajari mendalam mulai episode 4.

#Kontribusi Vercel dan Arsitektur Hybrid Rendering

#Vercel sebagai Rumah Next.js

Next.js dikembangkan dan dikelola oleh Vercel, perusahaan platform deployment. Karena Vercel juga menjalankan infrastruktur edge, Next.js terintegrasi sangat dalam dengan konsep serverless function dan edge runtime — topik yang akan kita bahas di episode 20 dan 21. Integrasi ini membuat Next.js lebih dari sekadar framework; dia adalah bagian dari ekosistem deployment yang utuh.

#Hybrid Rendering

Desain utama Next.js adalah hybrid rendering: kalian tidak dipaksa memilih satu mode rendering untuk seluruh aplikasi. Setiap halaman bisa memakai mode yang berbeda sesuai kebutuhan — statis untuk halaman yang jarang berubah, dinamis untuk data real-time. Arsitektur ini adalah jawaban atas trade-off klasik antara kecepatan, kesegaran data, dan biaya server.

Integrasi dengan platform tidak berhenti di deployment. Fitur seperti Incremental Static Regeneration dan edge runtime lahir dari kebutuhan platform yang menyajikan konten dari banyak titik. Ketika framework dan platform dikembangkan oleh tim yang sama, fitur baru bisa dirilis secara sinkron — kecepatan inovasi yang sulit ditiru framework dengan ekosistem deployment yang terpisah.

#Masalah yang Diselesaikan Next.js

#SSR, SSG, ISR, dan CSR dalam Satu Framework

Next.js menggabungkan empat strategi rendering dalam satu framework:

• SSR: HTML dirender per-request di server, segar tapi lebih lambat.
• SSG: HTML dibangun saat build, sangat cepat tapi statis.
• ISR: halaman statis yang diperbarui secara berkala di background.
• CSR: render di browser untuk interaksi real-time yang intensif.

Dengan mode yang tepat per halaman, kalian bisa mendapatkan kecepatan statis sekaligus fleksibilitas dinamis.

Dalam praktik, kalian tidak perlu selalu memikirkan mode mana yang dipakai — Next.js memilih default yang masuk akal dan memberi kontrol granular saat dibutuhkan. Pilihan mode bisa ditentukan per halaman, per segment, bahkan per fetch.

Penting juga memahami bahwa SSG dan ISR menghasilkan halaman yang sama-sama statis setelah dibangun — perbedaannya hanya pada mekanisme pembaruan. SSG statis selamanya sampai build berikutnya, sedangkan ISR memperbarui dirinya sendiri di background sesuai jadwal revalidate.

Urutan prioritas ini — statis dulu, dinamis hanya jika perlu — adalah prinsip yang akan kalian pakai kembali di episode 6 dan 14.

#Routing Berbasis Filesystem dan Optimasi Konten Statis

Routing berbasis filesystem menghilangkan boilerplate: folder app menentukan URL, dan file bernama page.tsx menjadi halaman. Ini berbeda dengan SPA tradisional yang butuh pustaka router terpisah. Next.js juga mengoptimasi konten statis secara otomatis — script yang tak terpakai dihitung dengan bundler modern, dan aset gambar dioptimasi di build.

#Performa, SEO, dan Developer Experience

Dengan HTML yang dirender di server, mesin pencari langsung membaca konten lengkap tanpa mengeksekusi JavaScript. Ditambah code splitting otomatis per route dan prefetching saat link terlihat, performa terasa instan. Bagi developer, fitur seperti hot reload, TypeScript bawaan, dan linter membuat feedback loop sangat cepat.

#Perbandingan dengan Pendekatan Tradisional

#React SPA Murni vs Next.js

SPA murni menghasilkan satu shell HTML kosong; seluruh konten dibuat oleh JavaScript di klien. Dampaknya: waktu muat awal lama, SEO terbatas, dan halaman tidak berfungsi jika JavaScript gagal dimuat. Next.js menyelesaikan ini dengan render di server tanpa meninggalkan model komponen React yang kalian kenal. Cek versi terbaru untuk memastikan kalian belajar di versi yang benar:

npm view next version

Output npm view next version menampilkan versi stabil terbaru, misalnya 15.3.4. Struktur dasar aplikasi Next.js modern terlihat sederhana:

export default function Home() {
  return (
    <main>
      <h1>Halo dari Next.js</h1>
    </main>
  )
}

Komponen di atas diekspor sebagai default dari app/page.tsx dan menjadi halaman /. Fungsinya sebagai komponen React murni, tapi Next.js-lah yang mengubahnya menjadi HTML server-rendered.

Dari perspektif tim, Next.js juga memangkas biaya onboarding: satu framework menangani routing, rendering, dan deployment, sehingga anggota tim baru tidak perlu mempelajari banyak tool terpisah.

Ada juga kasus di mana Next.js mungkin berlebihan — situs landing statis sederhana cukup memakai HTML statis atau tooling seperti Astro. Pertimbangkan kebutuhan: jika aplikasi butuh data, SEO, dan interaktivitas React, Next.js memberi keseimbangan terbaik; jika hanya halaman statis murni tanpa JavaScript, framework yang lebih ringan lebih tepat.

#Penutup

Inti yang harus dibawa pulang:

• Next.js lahir untuk menjawab masalah SSR pada React.
• Evolusi versi 9 hingga 15 menandai lompatan arsitektur, bukan perubahan kecil.
• Vercel memegang peran kunci dalam arah pengembangan Next.js.
• Hybrid rendering memungkinkan SSG, SSR, ISR, dan CSR dalam satu aplikasi.
• Routing berbasis filesystem menghilangkan boilerplate router.
• HTML server-rendered memberikan keunggulan SEO dan performa atas SPA murni.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama — cara kerja di balik layar, perbedaan App Router dan Pages Router, build pipeline, serta peran server runtime dan Edge runtime. Setelah episode ini, kalian akan melihat Next.js bukan sebagai kotak hitam, tapi sebagai sistem yang bisa dikendalikan.