Contexte et méthodologie

Pour contrer les affirmations non étayées qui circulent dans la communauté front‑end, l’auteur a conçu un benchmark où des agents LLM (Opus 5.5) construisent une petite application Pokémon à partir de la PokéAPI. Chaque agent utilise la version la plus récente d’un framework ou méta‑framework JavaScript (Next.js, Nuxt, SvelteKit, Angular, Hono+htmx, Gracile+Lit, TanStack Start, React Router). Le processus comprend : la génération du code, la vérification de conformité via une suite de tests basée sur l’arbre d’accessibilité, puis l’évaluation avec Lighthouse (scores de performance et d’accessibilité). Les métriques collectées sont le temps de développement, le nombre de tokens consommés, le coût API (exprimé en dollars selon les tarifs Claude Code), le nombre de lignes de code et les scores Lighthouse.

Coût de construction

Le coût est mesuré en dollars d’API : le React Router affiche un median de 2,82 $, soit environ 1 $ de plus que Hono+htmx, dont le coût le plus élevé atteint 3,19 $. Malgré cette différence, les écarts restent modestes. En revanche, SvelteKit, Gracile+Lit et Angular sont nettement plus onéreux. L’auteur explique que les agents doivent consulter la SvelteKit v3 migration guide à chaque itération, ce qui augmente le nombre de tokens, et que Gracile est peu présent dans le corpus d’entraînement d’Opus 5.5, obligeant les agents à cloner le dépôt ou à lire le code compilé. Angular, quant à lui, montre un coût élevé lié à la taille totale du code généré.

Qualité, performance et maintenabilité

Les scores Lighthouse varient selon les frameworks, mais aucune tendance claire n’émerge au‑delà du coût. Les mesures de Largest Contentful Paint (LCP) sont parfois incohérentes : un même rendu peut être considéré comme le plus grand élément lors d’une exécution et non lors de la suivante. Le nombre de lignes de code suit également le même schéma que le coût : les projets Angular et SvelteKit génèrent davantage de lignes, reflétant une complexité accrue. La maintenabilité est évaluée qualitativement ; les agents qui n’ont pas exploité les compétences MCP/Claude Code (ex. : TanStack Start n’a découvert les fichiers de skill que dans 2 / 5 runs, Nuxt jamais) ont produit des bases de code moins structurées, ce qui suggère que la disponibilité d’un plugin dédié influence la qualité finale.

Limitations et variabilité

Le benchmark comporte plusieurs sources de stochasticité. Les LLM sont des générateurs de texte aléatoires ; un « bad roll » peut entraîner une consommation excessive de tokens sans lien avec le framework. De plus, Lighthouse lui‑même montre une variance intrinsèque, notamment sur le LCP. Angular a échoué à créer une application fonctionnelle lors de deux des cinq essais, ce qui a conduit à ne retenir que trois itérations pour ce framework. Enfin, le test repose sur une seule application de type « contenu », comparable à une page Wikipédia, et ne couvre pas des scénarios d’interactivité lourde (ex. : éditeur de texte en ligne). Ces limites doivent être prises en compte avant de généraliser les conclusions à d’autres projets front‑end.