Ce site tourne sur Fresh 2 et Deno. J'ai choisi cette pile délibérément, je l'ai livrée, et je ne m'en servirais pas pour la majorité du travail qui me paie. Les deux affirmations sont vraies en même temps, et c'est l'écart entre les deux qui fait tout l'intérêt de cet article.
Ce que Fresh réussit
Travailler dans Fresh est un plaisir. Le routage, c'est le système de fichiers. Le serveur rend d'abord et n'envoie presque aucun JavaScript. Aucune étape de compilation ne s'interpose entre vous et la page. Vous écrivez quelque chose, vous rafraîchissez, c'est là.
Il y a là une nostalgie dont ses défenseurs ne parlent pas assez honnêtement. On retrouve le web d'avant, celui qu'on a enterré sous l'hydratation, les bundlers et un routeur côté client pour une page qui compte quatre liens. Ce sentiment est réel, et il vaut quelque chose. Il ne vaut pas autant qu'on le prétend.
Là où ça bloque
Le modèle des îlots est un pari. Le pari, c'est que la majorité de votre page est statique et que seuls quelques morceaux sont interactifs : vous n'envoyez donc du JavaScript que pour ces morceaux, et rien d'autre.
Quand le pari tient, Fresh est excellent. Quand il ne tient pas, vous travaillez menottes aux poignets.
L'état est le premier mur. Un îlot est une racine isolée. Deux îlots qui doivent s'entendre sur quelque chose sont deux applications distinctes qui partagent une page, et chaque solution est un contournement : un store hors de l'arbre de composants, un événement personnalisé, un signal qu'on fait passer à la main. Rien de difficile. Mais c'est de la friction qu'une application React ou Vue normale ne vous facture jamais.
Le sondage périodique est le deuxième mur. Tout ce qui est vivant — une file d'attente qui se met à jour, une tâche qui rapporte sa progression, un tableau de bord qui se rafraîchit — veut un client de longue durée avec un vrai état. C'est exactement la forme que le modèle des îlots est conçu pour éviter.
La manipulation lourde du DOM est le troisième. Le glisser-déposer, un canvas, un éditeur de texte enrichi, un tableau virtualisé de dix mille lignes. Ce ne sont pas des besoins exotiques. C'est un mardi ordinaire. Et chacun traîne un îlot de plus en plus gros sur une page censée rester statique, jusqu'à ce que vous livriez une application monopage avec des étapes en plus.
Les portes de sortie coûtent plus qu'elles ne rapportent
Les équipes de Fresh et de Deno savent tout cela, et leur réponse est la souplesse : utilisez des paquets npm, utilisez des bibliothèques compatibles React dans vos îlots, utilisez d'autres environnements d'exécution.
Je me suis servi de ces portes de sortie. Elles fonctionnent, jusqu'au moment où elles ne fonctionnent plus, et l'échec est rarement un message d'erreur propre. C'est une dépendance pair qui se résout vers une version que personne n'avait prévue. C'est une bibliothèque qui suppose un bundler que vous n'exécutez pas. C'est quelque chose qui marche en local et qui meurt au déploiement, parce que le graphe de modules s'y est résolu autrement.
Quand vous écrivez du code pour gagner votre vie, c'est la pire catégorie de problème. Pas parce qu'il est insoluble : parce qu'il est impossible à budgéter. Un client ne vous paie pas pour passer une journée à découvrir qu'un sélecteur de date suppose CommonJS. La dernière chose sur laquelle vous voulez dépenser du temps et de l'argent, c'est intégrer une dépendance qui aurait pris cinq minutes ailleurs.
C'est là ma véritable objection à Fresh en contexte commercial. Non pas qu'il soit mauvais, mais qu'il vous demande de vous engager envers sa manière de livrer du code — et l'entreprise est précisément l'endroit où l'on veut le moins être engagé envers quoi que ce soit. La souplesse et l'ajustement, c'est comme ça que l'argent se fait.
Deno lui-même
Deno est excellent sur papier. Le modèle de sécurité est la bonne idée. TypeScript sans chaîne d'outils est réellement agréable. La bibliothèque standard est cohérente d'une façon que l'écosystème de Node n'a jamais atteinte.
Mais je reviens toujours à la même question, sans jamais trouver de réponse : pourquoi celui-ci plutôt que Node ou Bun ?
Node a tout, tourne partout, et chaque développeur que vous pourriez embaucher le connaît déjà. Bun offre l'essentiel de l'ergonomie de Deno — TypeScript, une bonne bibliothèque standard, une installation rapide — tout en restant compatible avec l'écosystème qui existe déjà. Bun ne m'a rien demandé d'abandonner. Deno, oui, et je n'arrive pas à nommer ce que je reçois en échange qui vaudrait le troc.
Est-ce que tout le projet est un fantasme de remplacement de Node ? Je ne crois pas que les gens qui le construisent soient naïfs, et je trouve l'objectif légitime : Node traîne dix ans de décisions que son propre auteur regrette, et quelqu'un devrait essayer de faire mieux. Mais le remplacement n'aura pas lieu. Node n'est plus une technologie, c'est une infrastructure — et une infrastructure ne se remplace pas parce qu'il existe plus récent et plus agréable. Elle se remplace quand elle cesse de fonctionner, et Node fonctionne.
Astro exécute mieux l'idée des îlots
Si vous voulez le modèle des îlots, Astro l'exécute mieux que Fresh. Il est plus abstrait et bien plus agnostique : amenez React, amenez Svelte, amenez Vue, n'amenez rien. C'est l'architecture qui est le produit, pas l'environnement d'exécution ni le modèle de composants du cadriciel.
Voilà la différence. Fresh vous demande d'adopter une philosophie. Astro vous vend une technique et vous laisse vos outils.
Alors, est-ce que ça en vaut la peine en 2026 ?
Pour un site de contenu — un blogue, un portfolio, de la documentation, des pages marketing — Fresh est réellement bon et la performance est au rendez-vous. Ce site a exactement cette forme, et c'est pour ça qu'il est bâti ainsi, et que je ne l'ai pas regretté une seule fois.
Pour un produit avec de l'état, des données en direct, de la vraie interactivité et une liste de dépendances que vous n'avez pas auditée vous-même, je ne le choisirais pas, et je n'y engagerais pas le budget d'un client.
Fresh n'est ni un jouet ni un fantasme. C'est un outil de spécialiste vendu comme un outil généraliste. Savoir lequel des deux vous tenez entre les mains, c'est déjà l'essentiel du travail.