Astro vs Next.js : quel framework pour un blog ?

Quand j’ai décidé de créer ce blog, j’ai hésité entre deux frameworks : Astro et Next.js. Les deux sont excellents, mais pour des raisons très différentes.

Le contexte

Mon besoin était simple :

• Un blog avec des articles en Markdown
• Du syntax highlighting pour les blocs de code
• Des embeds audio/vidéo
• Zéro JS inutile côté client
• Facile à déployer sur un hébergement classique

Next.js : le couteau suisse

Next.js est incroyable pour les applications web dynamiques. Server-side rendering, API routes, middleware — la totale.

// pages/blog/[slug].js (Next.js)
import { getPostBySlug, getAllPosts } from '../../lib/api';
import markdownToHtml from '../../lib/markdown';

export default function Post({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

export async function getStaticPaths() {
  const posts = getAllPosts();
  return {
    paths: posts.map((post) => ({ params: { slug: post.slug } })),
    fallback: false,
  };
}

Le problème ? Pour un blog statique, c’est overkill. Le bundle JS est plus lourd qu’il ne devrait l’être, et la config peut vite devenir complexe.

Astro : le bon outil

Astro a été conçu pour le contenu. Il génère du HTML statique par défaut et n’envoie du JavaScript que quand c’est nécessaire.

---
// src/pages/blog/[slug].astro
const { slug } = Astro.params;
const post = await getPost(slug);
---

<article>
  <h1>{post.title}</h1>
  <Content />
</article>

Zéro JavaScript envoyé au navigateur pour afficher un article. Les performances sont imbattables.

Le verdict

Critère	Astro	Next.js
Contenu statique	⭐⭐⭐	⭐⭐
Apps dynamiques	⭐	⭐⭐⭐
Taille du bundle	~0 KB JS	~80+ KB JS
Markdown natif	✅	❌ (plugin)
Courbe d’apprentissage	Facile	Moyenne

Pour un blog/portfolio : Astro sans hésitation. Pour une SaaS ou une app complexe : Next.js.

“The best framework is the one that lets you ship.” — Moi, probablement.