nextjs.org

Next.js adalah framework React untuk membangun aplikasi web full-stack. React menyediakan model komponen untuk antarmuka pengguna; Next.js menambahkan perutean, rendering, konvensi akses data, kemampuan server, kompilasi, bundling, caching, dan tooling yang berorientasi pada produksi.

Subjek utamanya adalah framework tersebut, bukan domainnya. nextjs.org adalah situs web resmi tempat pengunjung dapat menemukan dokumentasi yang dipelihara, panduan, tautan komunitas, dan informasi tentang proyek tersebut.

Next.js paling relevan ketika sebuah tim ingin membangun dengan React sekaligus mendukung lebih dari sekadar antarmuka yang hanya berjalan di browser. Satu proyek dapat memuat halaman yang telah di-prerender, respons pada waktu permintaan, akses data sisi server, endpoint bergaya API, dan komponen interaktif yang berjalan di browser.

Apa yang ditambahkan Next.js ke React

React membantu pengembang mendeskripsikan antarmuka sebagai komponen, tetapi tidak menetapkan arsitektur aplikasi yang lengkap. Next.js menyediakan konvensi untuk memetakan file ke rute, menentukan tempat kode dijalankan, memuat data, menghasilkan respons, dan mempersiapkan aplikasi untuk deployment.

Karena itu, nilainya lebih luas daripada rendering sisi server. Aplikasi Next.js dapat menggunakan beberapa metode rendering dan penyajian, terkadang dalam proyek yang sama. Framework ini mengoordinasikan metode-metode tersebut di sekitar React, alih-alih memaksa setiap rute menggunakan satu model.

Ringkasan pembagian yang berguna adalah:

• React mendefinisikan komponen, state, props, dan komposisi antarmuka.
• Next.js mendefinisikan rute, layout, pilihan rendering, titik masuk server, dan perilaku build.
• Aplikasi mendefinisikan aturan data, batas klien, kebijakan cache, dan persyaratan deployment-nya.
• Lingkungan hosting menentukan fitur runtime yang tersedia dan cara fitur tersebut beroperasi.

Pemisahan ini penting ketika membandingkan Next.js dengan aplikasi klien React, generator situs statis, atau framework web lainnya. Framework ini menawarkan beragam kemampuan, tetapi sebuah proyek hanya memperoleh manfaat dari kemampuan yang digunakan dengan baik.

Server dan Client Components

Dalam App Router, layout dan halaman secara default merupakan Server Components. Server Components dijalankan di lingkungan server dan dapat melakukan pekerjaan data sisi server tanpa mengirim implementasi komponennya ke browser.

Client Components digunakan ketika sebagian antarmuka membutuhkan state browser, event handler, effect, atau API khusus browser. Pengembang menandai batas klien dengan direktif use client, dan komponen di bawah batas tersebut menjadi bagian dari grafik modul sisi klien.

Pertanyaan	Server Component	Client Component
Di mana logika komponennya dijalankan?	Di lingkungan rendering server	Di browser setelah disertakan dalam bundle klien
Dapatkah menggunakan state browser atau handler klik?	Tidak	Ya
Dapatkah langsung menggunakan API khusus browser?	Tidak	Ya
Apakah kode komponennya dikirim ke browser?	Tidak sebagai kode komponen klien	Ya
Peran umum	Konten berbasis data, layout, dan komposisi sisi server	Formulir, menu, editor, filter, dan kontrol interaktif lainnya

Sebuah rute tidak harus memilih satu jenis saja secara eksklusif. Server Component dapat merender konten dan menyusun Client Components tertentu untuk bagian halaman yang interaktif. Hal ini memungkinkan tim menempatkan JavaScript browser di sekitar kebutuhan tertentu, alih-alih memperlakukan seluruh rute sebagai aplikasi klien.

Batas tersebut tetap memerlukan kehati-hatian. Memindahkan subtree komponen yang besar ke balik use client dapat mengirim lebih banyak JavaScript ke browser, sedangkan memisahkan setiap kontrol kecil menjadi batas tersendiri dapat membuat kode lebih sulit dipahami. Halaman yang representatif sebaiknya diukur, bukan dinilai hanya berdasarkan label framework.

Server Components juga berbeda dari strategi penyajian sebuah rute. Server Component dapat berkontribusi pada output yang telah di-prerender atau berpartisipasi dalam rendering dinamis. Menyebut sebuah komponen sebagai sisi server tidak dengan sendirinya menjelaskan apakah rute tersebut dibuat selama build, diperbarui kemudian, atau dihasilkan untuk setiap permintaan.

App Router dan Pages Router

Next.js saat ini mendokumentasikan dua sistem perutean. App Router adalah sistem yang lebih baru dan menggabungkan fitur React seperti Server Components. Pages Router adalah sistem yang lebih lama dan tetap didukung.

Area	App Router	Pages Router
Struktur rute utama	Direktori app	Direktori pages
Model komponen default	Layout dan halaman merupakan Server Components	Menggunakan model halaman Next.js yang lebih lama
UI bersama	Layout bertingkat merupakan konvensi utama	Umumnya disusun melalui pola aplikasi dan halaman
Titik awal terbaik	Pekerjaan baru yang mengadopsi arsitektur saat ini	Aplikasi atau dependensi yang sudah ada dan dibangun di sekitar API Pages Router

Migrasi bukan sekadar mengganti nama folder. Kode App Router memperkenalkan model komponen yang mengutamakan server serta pola yang berbeda untuk layout, akses data, status pemuatan, dan perilaku rute. Tim sebaiknya mengidentifikasi perubahan konseptual tersebut sebelum mengonversi aplikasi yang telah matang.

Proyek baru biasanya sebaiknya mempelajari dokumentasi App Router terlebih dahulu karena dokumentasi tersebut menjelaskan model framework saat ini. Aplikasi Pages Router yang sudah ada sebaiknya mengevaluasi migrasi berdasarkan manfaat nyata, dependensi, upaya pengujian, dan biaya pemeliharaan, bukan menganggap dukungan yang berkelanjutan sebagai sebuah kekurangan.

Dokumentasi dan contoh mungkin hanya ditujukan untuk satu router. Sebelum menyalin implementasi, pengembang sebaiknya memastikan router yang digunakan dan apakah API yang dirujuk berlaku untuk proyek mereka.

Rendering, caching, dan revalidasi

Next.js tidak merender setiap halaman dengan cara yang sama. Sebuah rute dapat dipersiapkan sebelum pengunjung tiba, dibuat menggunakan informasi khusus permintaan, disimpan dalam cache, atau diperbarui sesuai kebijakan revalidasi.

Kebutuhan rute	Pendekatan penyajian yang mungkin	Pertanyaan yang perlu diverifikasi
Input telah diketahui sebelumnya	Output yang di-prerender	Peristiwa apa yang seharusnya menyebabkan output berubah?
Output bergantung pada cookie, header, atau data permintaan	Rendering dinamis	Apakah sebagian pekerjaan masih dapat disimpan dalam cache dengan aman?
Konten berubah menurut jadwal yang terkendali	Output yang di-cache dengan revalidasi	Seberapa usang respons tersebut boleh menjadi?
Tidak memerlukan fitur khusus server	Ekspor statis mungkin cocok	Apakah semua rute dan aset kompatibel dengan batasan ekspor?

Caching bukanlah satu sakelar yang dapat dipahami secara terpisah dari akses data. Tim perlu mengetahui operasi mana yang di-cache, rute mana yang menjadi dinamis, serta bagaimana invalidasi atau revalidasi terjadi. Aturan tersebut sebaiknya diuji dengan perubahan konten yang realistis.

Hal ini sangat penting untuk halaman terautentikasi, harga, inventaris, dasbor, dan informasi lain yang memiliki persyaratan kesegaran eksplisit. Menyajikan output yang di-cache dapat bermanfaat, tetapi hanya jika aturan ketepatan aplikasi mengizinkannya.

Performa dan visibilitas pencarian tidak seharusnya disimpulkan hanya dari label rendering. Prerendering dapat mengurangi pekerjaan pada waktu permintaan, dan rendering server dapat menyediakan HTML awal yang bermakna, tetapi hasil sebenarnya bergantung pada struktur halaman, aset, latensi data, JavaScript browser, caching, dan perilaku deployment.

Ekspor statis dan persyaratan runtime

Next.js dapat menghasilkan ekspor statis ketika proyek tidak bergantung pada fitur framework khusus server. HTML, CSS, JavaScript, dan aset yang dihasilkan dapat disajikan oleh infrastruktur yang mendukung file statis biasa.

Output statis tetap dapat menyertakan Client Components. Penyajian statis menjelaskan cara hasil build di-host; ini tidak berarti bahwa setiap antarmuka harus noninteraktif. Kode sisi browser tetap dapat menyediakan state, event, dan perilaku klien lainnya.

Sebelum memilih ekspor statis, pastikan proyek tidak memerlukan:

• Respons yang dihasilkan dari data server khusus permintaan.
• Perilaku rute yang bergantung pada runtime Next.js yang aktif.
• Fitur gambar, perutean, atau server yang tidak didukung.
• Aturan kesegaran yang tidak dapat dipenuhi melalui build ulang atau proses pembaruan lain yang didukung.
• Endpoint server yang harus dijalankan bersama aplikasi.

Ketika kemampuan tersebut diperlukan, aplikasi membutuhkan runtime yang kompatibel. Hal ini tidak mengharuskan deployment ke Vercel: panduan deployment resmi mendokumentasikan self-hosting dan adapter platform. Dukungan berbeda-beda menurut platform, sehingga kompatibilitas sebaiknya diperiksa berdasarkan fitur tertentu yang digunakan.

Route Handlers dan endpoint sisi server

Dalam App Router, Route Handlers memungkinkan aplikasi mendefinisikan handler permintaan HTTP menggunakan konsep permintaan dan respons standar. Route Handlers berguna untuk endpoint yang berada bersama aplikasi, termasuk pemrosesan formulir, webhook, respons data, atau callback integrasi.

Route Handler tidak secara otomatis menjadi tempat yang tepat untuk setiap sistem backend. Tim tetap perlu menentukan cara autentikasi, otorisasi, validasi, pembatasan laju, pekerjaan yang tahan lama, dan penanganan kesalahan dikelola. Layanan yang berjalan lama atau diskalakan secara independen mungkin lebih baik dipisahkan dari aplikasi web.

Tinjauan praktis mengajukan pertanyaan berikut:

1. Apakah endpoint memerlukan akses ke kode aplikasi atau tipe bersama?
2. Apakah endpoint memerlukan secret pada waktu permintaan atau dependensi khusus server?
3. Dapatkah target deployment menjalankan handler sebagaimana didokumentasikan?
4. Perilaku caching apa yang tepat untuk setiap metode dan respons HTTP?
5. Apakah layanan terpisah akan memberikan kepemilikan atau penskalaan yang lebih jelas?

Route Handlers memudahkan komposisi full-stack, tetapi kemudahan tersebut tidak menghapus tanggung jawab normal terkait desain dan keamanan API.

Kondisi ketika Next.js menjadi pilihan praktis

Next.js merupakan kandidat kuat bagi tim yang sudah terbiasa dengan React dan membutuhkan perutean aplikasi serta kemampuan server dalam codebase yang sama. Framework ini juga cocok untuk produk yang memiliki kebutuhan penyajian yang sangat berbeda di antara rutenya.

Kecocokan umum meliputi:

• Area akun dan dasbor dengan data server serta kontrol interaktif.
• Pengalaman perdagangan atau katalog yang memadukan konten stabil dengan informasi yang bergantung pada permintaan.
• Situs dokumentasi atau pemasaran yang juga memuat alur kerja aplikasi.
• Produk yang membutuhkan respons HTML, interaksi klien, dan endpoint server secara bersamaan.
• Aplikasi React yang rutenya memperoleh manfaat dari kebijakan caching dan rendering yang terpisah.

Framework ini mungkin memiliki lebih banyak mekanisme daripada yang dibutuhkan situs konten sederhana. Tim yang terutama menerbitkan artikel statis sebaiknya membandingkan kebutuhannya dengan alat yang berfokus pada penyajian konten, terutama jika hanya sebagian kecil situs yang memerlukan interaksi React.

Next.js juga dapat menjadi pilihan yang kurang sesuai ketika tim tidak dapat mendukung persyaratan runtime-nya, tidak menginginkan konsep rendering khusus framework, atau akan kesulitan mempertahankan batas server dan klien yang jelas. Fleksibilitas hanya bernilai ketika arsitekturnya tetap dapat dipahami.

Membandingkan Next.js dengan Astro dan opsi lainnya

Next.js dan Astro sering dievaluasi untuk proyek yang menggabungkan konten dengan elemen interaktif, tetapi default dan model mental keduanya berbeda. Pilihan yang tepat bergantung pada rute yang sebenarnya, bukan klaim umum bahwa salah satu framework lebih cepat atau lebih baik.

Untuk perbandingan yang berguna, bangun halaman representatif yang sama pada setiap kandidat dan catat:

• Berapa banyak JavaScript yang mencapai browser sebelum dan setelah interaksi.
• Bagaimana data dimuat dan bagaimana kesegarannya dikendalikan.
• Apakah fitur runtime server diperlukan.
• Bagaimana perutean, layout, formulir, dan status kesalahan diimplementasikan.
• Apakah host target mendukung setiap fitur yang diperlukan.
• Seberapa mudah tim dapat menguji dan menjelaskan arsitektur yang dihasilkan.

Astro layak dipertimbangkan secara khusus untuk situs yang berfokus pada konten, ketika sebagian besar output dapat tetap statis dan pulau interaktif terbatas. Next.js menjadi lebih menarik ketika React merupakan model aplikasi utama dan fitur server serta klien perlu disusun di seluruh produk.

Tidak satu pun perbandingan tersebut dapat memprediksi skor performa. Gambar, font, skrip pihak ketiga, pilihan komponen, latensi data, dan batas klien dapat memiliki pengaruh yang lebih besar daripada default framework.

Asal-usul, tata kelola, dan komunitas

Halaman tata kelola resmi menyatakan bahwa tim Vercel membuat Next.js pada 2016. Halaman tersebut juga menyatakan bahwa tim inti di Vercel memimpin penelitian dan pengembangan proyek. Ini merupakan pernyataan asal-usul dan tata kelola pada tingkat tim; pernyataan ini tidak boleh diganti dengan klaim yang tidak didukung tentang seorang pendiri individu.

Sebagaimana didokumentasikan pada halaman tata kelola dan dokumentasi yang tersedia pada 27 Agustus 2026, jalur partisipasi publik proyek mencakup:

• Repositori GitHub resmi untuk kode sumber, issue, dan aktivitas proyek.
• GitHub Discussions untuk pertanyaan dan diskusi RFC komunitas.
• Discord Next.js untuk dukungan komunitas gratis.
• Dokumentasi yang dipelihara untuk App Router dan Pages Router.

Saluran-saluran ini menawarkan jenis bantuan yang berbeda. Dokumentasi sebaiknya menjadi referensi pertama untuk perilaku framework, Discussions dapat menampilkan proposal dan pertanyaan bersama, dan Discord dapat mendukung percakapan komunitas. Tidak ada satu pun yang menggantikan pengujian khusus proyek atau proses dukungan produksi milik tim sendiri.

Checklist pengambilan keputusan

Sebelum mengadopsi Next.js, tim sebaiknya menjawab pertanyaan berikut dengan prototipe yang berfungsi:

• Rute mana yang statis, dinamis, di-cache, atau direvalidasi?
• Komponen mana yang benar-benar memerlukan state, effect, event, atau API browser?
• Berapa banyak JavaScript klien yang dikirim oleh setiap rute representatif?
• Endpoint mana yang seharusnya berada di Route Handlers, dan mana yang seharusnya berada di tempat lain?
• Dapatkah platform target menjalankan setiap fitur Next.js yang diperlukan?
• Bagaimana kesegaran cache, kegagalan, log, dan deployment akan dikelola?
• Apakah tim memahami perbedaan antara router pilihannya dan contoh yang ditulis untuk router lainnya?

Next.js berfokus pada penerapan React di seluruh aplikasi web lengkap sembari secara sadar memilih tempat pekerjaan berlangsung dan cara setiap rute disajikan. Fleksibilitas yang didokumentasikan cukup luas, tetapi tidak menjamin performa, hasil pencarian, biaya operasional rendah, atau kesederhanaan arsitektur. Hasil tersebut harus dibuktikan melalui implementasi dan pengukuran.