Memilih framework frontend bukan sekadar soal tren atau popularitas — ini soal kecocokan antara arsitektur framework dengan kebutuhan nyata proyek. Dua nama yang sering muncul berdampingan dalam diskusi ini adalah Astro dan Next.js. Keduanya modern, keduanya didukung komunitas besar, dan keduanya bisa menghasilkan situs yang cepat. Tapi filosofi di baliknya sangat berbeda.
Astro berangkat dari keyakinan bahwa sebagian besar web tidak butuh sebanyak itu JavaScript. Next.js justru memposisikan dirinya sebagai platform fullstack yang fleksibel — siap menangani apapun, dari blog sederhana sampai aplikasi enterprise dengan autentikasi kompleks. Dua perspektif yang sama-sama valid, tapi membawa konsekuensi teknis yang berbeda.
Artikel ini membahas perbedaan mendasar antara Astro dan Next.js dari sisi arsitektur, performa, dan kapan masing-masing lebih masuk akal untuk digunakan.
Filosofi yang Berbeda dari Dasarnya
Cara terbaik memahami dua framework ini adalah melihat masalah apa yang masing-masing coba selesaikan.
Astro lahir dari frustrasi terhadap JavaScript yang berlebihan di situs-situs konten. Blog, halaman dokumentasi, landing page, dan portal berita sebenarnya tidak perlu mengirim ratusan kilobyte JavaScript ke browser pengunjung — tapi framework berbasis React tradisional melakukan itu secara default karena seluruh halaman harus dihydrate di sisi klien.
Next.js berangkat dari sudut pandang yang berbeda. Framework ini ingin menjadi satu platform yang cukup untuk membangun apapun — dari static site sampai aplikasi SaaS dengan real-time data, autentikasi, dan backend terintegrasi. Fleksibilitas adalah prioritas utamanya.
Perbedaan filosofi ini bukan berarti salah satunya lebih baik. Ini soal konteks.
Islands Architecture: Cara Astro Mengelola JavaScript
Konsep paling penting yang perlu dipahami saat belajar Astro adalah Islands Architecture. Bayangkan sebuah halaman sebagai lautan HTML statis, dengan pulau-pulau kecil JavaScript yang tersebar hanya di bagian yang memang butuh interaktivitas.
Secara default, setiap komponen di Astro dirender menjadi HTML murni di server — tidak ada JavaScript yang dikirim ke browser. Ketika sebuah komponen butuh menjadi interaktif, kita menandainya dengan client directive secara eksplisit.
Astro menyediakan beberapa directive dengan perilaku yang berbeda:
| Directive | Kapan Komponen Dihydrate |
|---|---|
client:load | Langsung saat halaman dimuat |
client:idle | Setelah browser selesai loading awal (requestIdleCallback) |
client:visible | Hanya saat komponen masuk viewport |
client:media | Ketika media query terpenuhi |
Contoh penerapannya pada halaman blog dengan sidebar interaktif dan chart yang ada di bawah fold:
---
// src/pages/laporan.astro
import NavBar from '../components/NavBar.jsx';
import FilterPanel from '../components/FilterPanel.jsx';
import SalesChart from '../components/SalesChart.jsx';
import Footer from '../components/Footer.astro';
---
<html lang="id">
<body>
<!-- Hydrate langsung — navigasi butuh interaktif segera -->
<NavBar client:load />
<main>
<h1>Laporan Penjualan</h1>
<!-- Hydrate saat idle — filter tidak butuh langsung aktif -->
<FilterPanel client:idle />
<!-- Hydrate saat masuk viewport — chart ada di bawah fold -->
<SalesChart client:visible />
</main>
<!-- Footer Astro murni — tidak butuh JavaScript sama sekali -->
<Footer />
</body>
</html>
NavBar langsung aktif karena pengguna mungkin langsung klik menu. FilterPanel menunggu browser idle karena tidak kritis saat pertama kali halaman terbuka. SalesChart bahkan tidak dihydrate sama sekali kalau pengunjung tidak scroll ke bawah.
Hasilnya: JavaScript yang dikirim ke browser jauh lebih sedikit, dan setiap "pulau" diload secara independen tanpa memblokir yang lain.
Astro mendukung komponen dari berbagai framework dalam satu halaman — React, Vue, Svelte, bahkan Solid.js bisa hidup berdampingan. Kamu bisa pakai React hanya untuk komponen yang memang butuh ekosistemnya, sementara bagian lain tetap sebagai HTML statis.
React Server Components: Pendekatan Next.js
Next.js App Router membawa paradigma yang disebut React Server Components (RSC). Berbeda dari Astro yang memisahkan komponen secara eksplisit via directive, Next.js membagi komponen menjadi dua kategori berdasarkan di mana mereka dieksekusi.
Server Components dijalankan di server, bisa langsung mengakses database atau filesystem, dan tidak mengirim JavaScript apapun ke browser. Ini adalah default di App Router.
Client Components ditandai dengan 'use client' di baris pertama file, dan inilah yang dihydrate di browser untuk interaktivitas.
TSX// app/dashboard/page.tsx — Server Component (default)
// Komponen ini jalan di server, bisa query database langsung
import { db } from '@/lib/database';
import ActivityFeed from './ActivityFeed';
import StatsWidget from './StatsWidget';
export default async function DashboardPage() {
// Query langsung — tidak perlu fetch API terpisah
const recentActivities = await db.activity.findMany({
orderBy: { createdAt: 'desc' },
take: 10,
});
return (
<div className="dashboard-layout">
{/* Client Component untuk interaktivitas */}
<StatsWidget />
{/* Data diteruskan sebagai props ke komponen lain */}
<ActivityFeed activities={recentActivities} />
</div>
);
}
// app/dashboard/StatsWidget.tsx — Client Component
'use client';
import { useState, useEffect } from 'react';
export default function StatsWidget() {
const [activeUsers, setActiveUsers] = useState(0);
useEffect(() => {
// Fetch data real-time hanya di sisi klien
const interval = setInterval(async () => {
const res = await fetch('/api/stats/active-users');
const data = await res.json();
setActiveUsers(data.count);
}, 5000);
return () => clearInterval(interval);
}, []);
return (
<div className="stats-card">
<span className="label">Pengguna aktif sekarang</span>
<span className="value">{activeUsers}</span>
</div>
);
}
DashboardPage jalan di server, mengakses database tanpa API route perantara, dan hasilnya dikirim sebagai HTML. StatsWidget ditandai 'use client' karena butuh useState dan real-time polling.
Pendekatan ini berbeda dari Astro: di Next.js, batas server/client ditentukan per file komponen, bukan per directive di template.
Perbandingan Performa: Angka yang Perlu Diketahui
Perbedaan arsitektur berujung pada perbedaan performa yang terukur, terutama untuk situs yang berat konten.
Astro secara default tidak mengirim JavaScript runtime apapun — halaman yang seluruhnya statis benar-benar hanya HTML dan CSS. Untuk situs konten seperti blog atau dokumentasi, ini menghasilkan Largest Contentful Paint (LCP) dan Time to Interactive (TTI) yang jauh lebih cepat.
Next.js selalu menyertakan React runtime, yang menambah sekitar 80–120 KB (gzip) sebagai overhead minimum bahkan sebelum kode aplikasi. Untuk aplikasi interaktif yang memang butuh React di browser, overhead ini wajar. Untuk blog statis, ini berlebihan.
| Aspek | Astro | Next.js |
|---|---|---|
| Default JavaScript | 0 KB | ~80–120 KB (React runtime) |
| Rendering default | Static HTML | Server Components + hydration |
| Cocok untuk | Situs konten, dokumentasi, blog | Aplikasi interaktif, SaaS, dashboard |
| Learning curve | Rendah (familiar HTML/CSS) | Sedang (butuh paham RSC model) |
| Backend terintegrasi | Terbatas | Ya (API routes, middleware, auth) |
| Ekosistem | Berkembang | Sangat mature |
Angka performa di atas adalah gambaran umum. Hasil aktual bergantung pada seberapa banyak client directive yang digunakan di Astro, dan seberapa efektif penggunaan Server Components di Next.js. Next.js yang dikonfigurasi dengan baik bisa sangat cepat untuk use case yang tepat.
Kapan Memilih Astro
Astro adalah pilihan tepat ketika konten adalah inti dari produk, dan interaktivitas adalah fitur sekunder. Beberapa skenario yang cocok:
- Blog dan portal konten — artikel, berita, atau majalah digital yang mayoritas dibaca, bukan diinteraksikan
- Dokumentasi teknis — situs docs seperti yang dipakai banyak proyek open source
- Landing page dan marketing site — konversi bergantung pada kecepatan load, bukan fitur interaktif
- Portfolio — showcase karya yang lebih butuh visual daripada dinamisme aplikasi
Astro juga unggul ketika proyek melibatkan tim yang tidak semuanya React developer. Karena Astro bisa menerima komponen dari berbagai framework dan template-nya familiar bagi siapapun yang tahu HTML, onboarding lebih mudah.
Kapan Memilih Next.js
Next.js lebih masuk akal ketika aplikasi membutuhkan logika backend yang terintegrasi erat dengan frontend. Skenario yang cocok:
- Aplikasi dengan autentikasi — login, session management, protected routes
- Dashboard dengan data dinamis — data berubah sering, butuh real-time update atau polling
- SaaS dan aplikasi enterprise — butuh API routes, middleware, edge functions, dan skalabilitas tim
- E-commerce — cart, checkout, payment flow membutuhkan state management yang kuat
Ekosistem Next.js juga jauh lebih mature untuk kebutuhan enterprise — integrasi dengan layanan autentikasi, database ORM, payment gateway, dan tooling TypeScript sudah sangat baik.
Yang Sering Disalahpahami
Ada beberapa miskonsepsi yang sering muncul saat membandingkan keduanya.
Pertama, Astro bukan pengganti React. Astro adalah meta-framework yang bisa menggunakan React (atau framework lain) sebagai library komponen. Keduanya tidak bersaing secara langsung.
Kedua, Next.js bukan lambat. Next.js dengan App Router dan Server Components yang dikonfigurasi dengan benar bisa sangat performant. Masalah performa biasanya muncul ketika developer menambahkan 'use client' tanpa pertimbangan, atau tidak memanfaatkan caching yang tersedia.
Ketiga, keduanya bisa dipakai untuk blog. Astro memang lebih natural untuk ini, tapi banyak blog skala besar berjalan di atas Next.js karena ekosistemnya yang kaya — terutama integrasi dengan headless CMS seperti Contentful atau Sanity.
Kesimpulan
Astro dan Next.js bukan pesaing yang perlu diadu — mereka menjawab pertanyaan yang berbeda. Kalau pertanyaannya adalah "bagaimana cara mengirim halaman secepat mungkin ke pembaca?", Astro punya jawaban yang lebih elegan. Kalau pertanyaannya adalah "bagaimana cara membangun aplikasi web yang kompleks dengan tim besar?", Next.js sudah sangat terbukti. Pilih berdasarkan apa yang proyek benar-benar butuhkan, bukan berdasarkan mana yang lebih viral minggu ini.
