Astro, c’est le retour aux fondamentaux du web

« Astro est le meilleur framework pour les développeurs »

• Astro est un nouveau type de framework web optimisé pour les sites centrés sur le contenu, avec par défaut une politique de Zero JavaScript, d’excellentes performances et une expérience de développement simple
• Avec son approche unique appelée Island Architecture, JavaScript n’est appliqué qu’aux parties nécessaires, tandis que le reste est servi en HTML statique rapide
• Les sites Astro affichent des temps de chargement supérieurs de plus de 40 % à ceux des sites basés sur React traditionnels, ce qui apporte des bénéfices concrets en SEO, expérience utilisateur et taux de conversion
• Contrairement à d’autres frameworks, la logique de données et les composants frontend y sont clairement séparés, et il est possible de le combiner avec divers frameworks comme React ou Vue
• En revanche, pour les cas nécessitant une SPA, une gestion d’état complexe ou un routage à grande échelle, des frameworks classiques comme Next.js peuvent être plus adaptés

---

Qu’est-ce qu’Astro ?

• Astro est un framework web apparu en 2021 ; contrairement aux frameworks JS existants conçus pour des applications complexes, il a été pensé pour les sites centrés sur le contenu
• Sa philosophie de base est « content first, server first, Zero JavaScript par défaut », avec un outillage intuitif et facile à prendre en main

Island Architecture

• Astro introduit le concept d’« Island Architecture », qui applique JavaScript uniquement à certaines parties nécessaires au lieu de l’ensemble de la page
• Sur une page comme un article de blog, composée majoritairement de texte, le rendu se fait uniquement en HTML, et seules les zones interactives comme les commentaires ou un carrousel chargent du JS
• Résultat : des pages extrêmement rapides et légères

Performances et effets concrets

• Les sites construits avec Astro enregistrent des chargements de plus de 40 % plus rapides que les frameworks React traditionnels
• Ces gains de performance se traduisent par des résultats business sur le classement dans les moteurs de recherche, la satisfaction utilisateur et le taux de conversion
• Sur des appareils lents ou des réseaux à faible débit, l’écart de vitesse est encore plus perceptible

Expérience développeur (Developer Experience)

• Le setup du projet est simple, et un assistant convivial nommé Houston guide l’installation
• Les composants Astro permettent d’exécuter une logique uniquement au moment du build (par exemple : récupération de données, appels API, etc.)
• Sans avoir à se soucier d’une gestion d’état complexe, des cycles de vie ou des hooks, il est possible de n’utiliser du JS côté client que lorsque c’est nécessaire

Compatibilité avec différents frameworks

• Il est possible de mélanger librement Astro avec les principaux frameworks comme React ou Vue
• Exemple : un dashboard d’administration en React, la visualisation de données en Vue, et le reste en Astro

Des fonctionnalités pratiques qui « fonctionnent »

• Il est possible d’importer directement du Markdown comme s’il s’agissait d’un composant
• Prise en charge d’un pipeline de build moderne : TypeScript, Sass, optimisation d’images, hot module replacement, etc.
• Site statique / SSR / rendu hybride : tout est possible, avec une mise en œuvre flexible selon la nature du projet

Là où Astro brille

• Sites marketing, blogs, catalogues e-commerce, portfolios : Astro offre d’excellentes performances pour les sites centrés sur le contenu
• Il est idéal dans les environnements ne nécessitant pas de gestion d’état client complexe

Les compromis

• Pour les projets où SPA, routage complexe et partage d’état entre composants sont essentiels, d’autres frameworks comme Next.js sont plus adaptés
• Son écosystème reste encore modeste, et le routage basé sur les fichiers peut sembler limité sur de très gros projets

Démarrage rapide

• npm create astro@latest my-site
• Si besoin, ajouter un framework avec npx astro add react
• Ajouter des pages dans src/pages/ et des composants dans src/components/, puis commencer le développement

Pourquoi Astro compte

• Alors que les frameworks JS récents deviennent de plus en plus complexes, Astro revient aux fondamentaux du web — une expérience centrée sur le contenu, rapide et accessible — tout en préservant le confort de développement
• Sa philosophie de conception — « un site rapide par défaut, de l’interactivité seulement là où il en faut, et la liberté d’utiliser le framework de son choix » — séduit les développeurs
• Des blogs à l’e-commerce, Astro est fortement recommandé pour les projets centrés sur le contenu

[GN⁺]

Commentaires sur Hacker News

• Les frameworks web traditionnels ont toujours « hydraté » la page entière en JavaScript : même s’il n’y avait qu’un seul widget interactif dans un simple billet de blog, tout passait par JavaScript. Astro, lui, utilise par défaut du HTML statique et n’active uniquement les parties nécessaires sous forme de « JavaScript islands ». Avant, on appelait ça du « progressive enhancement » ou simplement une « page web », et c’était la norme pour créer des sites web. Puis les SPA sont arrivées et le progressive enhancement est devenu de moins en moins utilisé. Aujourd’hui on parle de « JavaScript islands », mais au fond on revient juste à l’ancienne manière de faire. Je recommande le concept de progressive enhancement aux nouveaux développeurs web que ça intéresse

  • On entend souvent quelqu’un décrire une nouvelle fonctionnalité d’outil et penser à tort que c’est la même chose que ce qu’on faisait déjà. Mais la vraie valeur d’Astro, c’est son intégration avec différents frameworks JavaScript, qui permet à chacun de gérer seulement une sous-partie du HTML. L’état initial est rendu sous forme de chaîne puis hydraté côté client avec des données préchargées. C’est utile si l’on veut utiliser des frameworks comme React/Svelte/Solid/Vue uniquement sur certaines parties d’une page et précharger les données côté serveur. En revanche, ce n’est pas du « progressive enhancement » : le HTML avant hydratation n’a pas besoin de fonctionner correctement. Par exemple, un <form> peut très bien ne pas fonctionner sans JavaScript. Ce sont justement ces détails qu’on ne voit qu’en restant curieux au lieu d’être cynique

  • Tout à fait d’accord. Astro est un super outil, mais le plus difficile a été de comprendre tout le vocabulaire inventé après 2010 par des développeurs pour expliquer le fonctionnement du web

  • Ce n’est pas un concept nouveau, mais la façon actuelle paraît bien plus raffinée. Avant, on faisait des sites interactifs avec PHP et jQuery, avant l’arrivée de React et des SPA. Avec le recul, l’ancienne approche était plus élégante sur le plan architectural, mais à l’époque le debugging et la DX étaient vraiment mauvais. Je n’ai aucune envie de revivre le temps passé à déboguer du frontend en PHP. Les SPA gardent leur utilité pour les dashboards complexes ou les applications très interactives. Astro améliore fortement la DX en permettant de gérer le code serveur et client au même endroit, avec une séparation claire, sans devoir parser des données en PHP pour les transmettre à du JS

  • Je me souviens de l’époque où on appelait ça AJAX. J’ai vraiment l’impression d’avoir complètement perdu le fil

  • Je pense que les premiers frameworks web avaient vraiment la bonne approche sur les sites sans état et le rendu côté serveur

• Personnellement, je recommande vivement Astro. Au début, je voyais ça comme « un outil qui ajoute juste des includes à HTML et CSS », puis je l’ai utilisé pour mon site personnel et pour la refonte du site de Matrix Conference, et c’était vraiment agréable à utiliser sans prise de tête
  Principaux avantages d’Astro :

  • ça reste centré sur HTML et CSS
  • après le build, il n’y a pas besoin de JS par défaut
  • on peut ajouter du JS de manière sélective uniquement là où il faut de l’interactivité
  • la fonctionnalité de collections de contenu est propre
  • l’optimisation de la vitesse est extrêmement bien pensée, et les mainteneurs savent ce qu’ils font
  • il y a une Devbar pour le développement qui montre visuellement ce qui peut encore accélérer le site (par ex. le lazy load des images en bas de page)
  • le minifieur CSS inline une partie du CSS pour réduire les requêtes supplémentaires
  • le composant d’image définit automatiquement les attributs width/height pour éviter le content layout shift, et fournit aussi des images responsives

  • Si Astro consiste à rester centré sur HTML et CSS et à n’ajouter du JS qu’en cas de besoin, on peut obtenir la même expérience en créant directement des fichiers .html, .css et .js dans un dossier et en les déployant. On peut même se demander si ce n’est pas plus rapide, sans surcharge au développement ni bloat inutile. De plus, l’inlining du CSS n’a jamais vraiment été un gros sujet de performance dans mon expérience : sur des centaines de sites, le CSS a rarement été le goulot d’étranglement, le vrai problème était le réseau

  • Mon seul vrai regret, c’est que plus le routing devient complexe, plus les abstractions se multiplient rapidement jusqu’à devenir confuses. Comme la complexité entraîne toujours de la friction, j’ai fini par choisir une autre approche

  • Si ce qu’il faut, c’est juste des « includes pour HTML et CSS », alors il suffit d’activer les Server Side Includes sur un serveur web classique comme nginx. C’est une solution stable depuis plus de 20 ans qui ne demande quasiment aucune maintenance. Pas de risque de sécurité supplémentaire comme avec un moteur de templates, et on peut éviter la redondance tout en faisant de simples includes sans se soucier de vulnérabilités backend

  • Après 20 ans passés uniquement sur la donnée et le backend, je suis revenu au frontend à cause d’un projet, et après avoir galéré avec React, passer à Astro+Svelte a été une vraie réussite. Comme tout reste centré sur HTML/CSS, la structure du code est prévisible et propre, et même quand j’ai confié le frontend à un développeur expérimenté en React, il s’est presque immédiatement adapté

• Voir l’expression « framework traditionnel » utilisée pour parler des frameworks SPA/Virtual DOM me fait sentir un décalage générationnel. Les vrais frameworks web traditionnels, c’étaient Backbone, jQuery, etc., et ce sont justement eux qui fonctionnaient comme dans la description du billet

  • Le « traditionnel » dépend finalement de l’époque où l’on est né. Pour moi, l’internet traditionnel, c’est le modem 56k, les forums vbulletin, les mods GTA:VC, l’IRC, etc. Pour une génération plus ancienne, ce sera les BBS, et pour les plus jeunes, Discord sera peut-être « l’internet traditionnel ». On voit un phénomène similaire en politique : tout le monde a tendance à penser que l’époque de sa jeunesse était meilleure

  • Il me semble que Backbone visait du pur SPA avec une approche MVC côté client

• Je me demande pourquoi des frameworks SSR comme Astro ou NextJS ne prennent pas en charge les pages statiques avec routes dynamiques comme SvelteKit. Par exemple, une page comme /todos/[todoId] ne peut pas du tout être incluse dans un bundle statique avec NextJS, alors que SvelteKit utilise 404.html pour faire en sorte que cela fonctionne parfaitement, même si c’est techniquement une 404, notamment sur Cloudflare ou dans des webviews mobiles. Cette fonctionnalité est particulièrement utile pour packager des webviews mobiles

  • Je suis partiellement d’accord, mais cette conception a aussi des inconvénients. Si on fait un rechargement complet d’une URL comme /todos/123 dans une SPA, le navigateur demande au vrai serveur si le fichier existe. S’il n’existe pas, on reçoit une 404. Il faut alors que la page 404 recharge les données via le routing client pour traiter le cas, ce qui impose une configuration spécifique du serveur HTTP comme nginx. Donc ce n’est pas possible avec de simples fichiers statiques purs. De plus, selon la spécification HTTP, le cache navigateur ne stocke jamais une réponse 404. Résultat : lors d’un hard reload ou via un bookmark, on ne peut jamais profiter du cache. Si cette configuration est trop lourde, je pense qu’il vaut mieux utiliser des query parameters du type /todo?id=123

  • Je me trompe peut-être, mais j’ai déjà implémenté des routes/pages dynamiques dans des builds statiques de Next ou Astro. En utilisant Contentful ou Storyblok comme CMS, on laissait les éditeurs créer librement des routes et des composants, et le pattern [...slug] couvrait toutes les routes. La fonction getStaticPaths servait à pré-générer toutes les pages. Avec ISR/ISP activé, même les pages inconnues au moment du build étaient pré-rendues dynamiquement. Dans Next on parle de dynamic routes, et dans Astro de dynamic pages
    Référence : Next dynamic routes, Astro dynamic pages

  • Je me trompe peut-être aussi, mais la fonction getStaticPaths d’Astro semble prendre en charge exactement ce que tu veux
    Référence

  • J’aime aussi les déploiements statiques, donc pour information, NextJS prend également en charge la génération de paramètres statiques

  • Je n’ai pas une compréhension complète d’Astro ni de tous ces frameworks, mais tu peux peut-être regarder si les server islands d’Astro correspondent à ce que tu cherches

• J’ai l’impression que les discussions frontend sont en elles-mêmes beaucoup trop confuses. Au fond, ce dont parle l’article revient à « utiliser le navigateur comme HMI ou comme runtime applicatif ». Pourtant, la plupart des débats se résument à des affirmations vagues du type « c’est frais » ou « ça charge vite ». J’ai l’impression que cette façon de promouvoir les frameworks comme des marques ressemble énormément à l’industrie de la mode

  • L’industrie de la mode est probablement la meilleure analogie pour expliquer les discussions autour des frameworks frontend. On examine rarement avec rigueur technique des slogans comme « content-driven » ou « server-first »

  • Je ne vois pas en quoi « ça charge vite » serait une illusion : c’est un élément réellement important

• J’ai récemment créé le site d’un établissement de santé avec Astro, et c’était bien plus facile qu’autrefois avec WordPress. En plus, on peut l’héberger gratuitement sur des services comme Netlify sans avoir à s’inquiéter du piratage. J’ai même fait un petit CMS simple basé sur git pour que le client puisse modifier lui-même le contenu. J’ai vraiment l’impression que le développement web a énormément progressé

  • C’était pour rendre service à une connaissance, ou comment trouves-tu des contrats pour faire des sites d’établissements de santé ?

  • Attention : Netlify facture plus cher la bande passante que Vercel

• Le plus grand avantage d’Astro, c’est qu’il permet de travailler uniquement avec du HTML ou des Web Components, sans dépendre d’autres frameworks comme React ou Vue. Mais Astro prend aussi en charge SSR, ISR, SSG et les middlewares, tout comme Next ou Nuxt
  Sa vraie différence, c’est l’architecture en îlots, qui permet de mettre en place des micro-frontends
  Par exemple, dans une même entreprise, plusieurs équipes peuvent chacune développer le paiement, le panier ou les pages produit, puis tout intégrer sur une seule page. On peut contrôler directement le mode de rendu, et même partager un état global, ce qui permet à chaque équipe de garder une responsabilité complète et de développer/déployer sa partie indépendamment
  Cela dit, c’est une solution surtout utile sur de très gros projets. Si chaque équipe utilise React à sa manière, on se retrouve avec des versions variées partout, alors qu’une séparation architecturale comme Astro permet de résoudre ce problème
  Je ne suis pas certain que cela transforme complètement le web. J’ai plutôt l’impression qu’on prend Next/Nuxt, qu’on retire la dépendance forte au framework et qu’on y ajoute l’architecture en îlots. Mais je recommande quand même d’essayer
  Si l’objectif est de sortir de React/Vue pour migrer vers des web-components ou de remplacer Next/Nuxt, Astro est une bonne solution progressive

• Pour moi, Astro n’est pas parfait dans tous les cas. Parfois, si l’on a seulement besoin de rendu offline, il n’y a aucune raison de se forcer à utiliser du JavaScript
  L’architecture en îlots a aussi ses limites, et le résultat buildé tend souvent à devenir excessivement inliné
  Honnêtement, je pense que le hype autour d’Astro doit beaucoup plus à Vite qu’autre chose. Vite est vraiment excellent

  • J’aimerais savoir à quel moment « l’architecture en îlots atteint ses limites »

• J’aimerais qu’on arrête de recommander Next.js comme framework standard de React. Le frontend a besoin de davantage d’esprit critique. Remix (React Router v7) ou TanStack sont de bien meilleures alternatives

  • Je suis d’accord. Next.js avait du potentiel, mais j’ai l’impression qu’il a beaucoup régressé depuis l’implication de Vercel. Je l’utilise depuis la v10, et après avoir traversé le chaos de la v13 jusqu’à la v15, j’ai été très déçu. React et Next.js changent trop vite, au point qu’il devient impossible de suivre. J’ai souvent l’impression qu’il y a plus de changement pour le changement que de changement réellement nécessaire

  • J’aimerais même qu’on arrête de recommander React lui-même comme framework par défaut. Pour le développement frontend, je trouve que HTML/CSS/JS sont bien meilleurs

  • Je pense que Remix/React Router v7 va dans la bonne direction. En particulier, si Remix s’appuie sur preact et reste centré sur les standards du web, on pourra peut-être revenir à une manière plus robuste de créer des sites web. En revanche, la transition de Remix vers RR7 n’a pas été fluide, et j’ai dû réécrire le projet

• Je pense que les principes fondamentaux du web restent toujours valables. Quand on travaille avec PHP, Spring, Quarkus ou ASP.NET MVC, on ne se rend pas forcément compte à quel point l’environnement de développement web basé sur les frameworks JS est devenu pénible. À cause de cette industrie guidée par les modes, j’ai l’impression qu’il n’est pas facile de revenir aux bases du web