Zwölf Frameworks, eine App: Ein Agent baute sie für 2,67 bis 4,97 Dollar
Serguey Asael Shinder2 Min. LesezeitNolan Lawson, der seit Langem fordert, Behauptungen über Frontend-Technik zu messen statt sie zu wiederholen, veröffentlichte am 28. Oktober einen Benchmark zu einer Frage, die Framework-Debatten inzwischen prägt: Ist ein bestimmtes Framework „besser für Agenten“? Er schrieb die Spezifikation einer kleinen Pokémon-Anwendung auf Basis der PokéAPI, ließ einen Agenten (Opus 5.5 mit hohem Aufwand, jeweils mit dem offiziellen MCP-Server oder den Skills des Frameworks) sie mit zwölf Frameworks in je fünf Durchläufen bauen und prüfte jedes Ergebnis gegen eine Konformitätssuite, die auf dem Accessibility-Baum aufsetzt.
Die Baukosten, als Median aus fünf Läufen zu API-Preisen, reichten von 2,67 Dollar für Hono mit htmx, 2,76 Dollar für Astro und 2,82 Dollar für Nuxt bis zu 4,28 Dollar für SvelteKit, 4,65 Dollar für Gracile mit Lit und 4,97 Dollar für Angular, das zweimal keine messbare App lieferte. Einen Teil der SvelteKit-Kosten führt Lawson darauf zurück, dass die Agenten in jedem Lauf den Migrationsleitfaden zu v3 lasen, die Gracile-Kosten darauf, dass sie das Framework nicht kannten und das Repository klonten oder kompilierte Quellen lasen.
Lighthouse trennte die Ergebnisse kaum: Performance lag zwischen 97 und 100, Barrierefreiheit überall bei 100. Beim ausgelieferten JavaScript zeigten sich Unterschiede: Astro schickte auf der Startseite im Median 0 KiB, die Vanilla-Variante 7 KiB, Hono mit htmx 18 KiB, SvelteKit 36 KiB, Nuxt 84 KiB, React Router 115 KiB, TanStack Start 118 KiB und Next.js 142 KiB.
Was das bedeutet
Wertvoll ist eher die Methode als die Rangliste. Lawson weist darauf hin, dass die Messungen streuen (der günstigste React-Router-Lauf schlug den teuersten Hono-Lauf), die App nur ein kleiner, inhaltslastiger Fall ist und Lighthouse Multi-Page-Apps bevorzugt. In diesen Grenzen sind zwei Befunde belastbar. Erstens schlägt sich direkt in Tokens nieder, wie gut ein Modell ein Framework schon kennt, denn unbekannte oder sehr neue Versionen schicken den Agenten zum Lesen von Dokumentation oder Quellcode. Zweitens hat der Agent die bekannten Größenunterschiede zwischen Frameworks nicht aufgehoben: Die JavaScript-Kosten tragen die Nutzer, egal wer den Code geschrieben hat. Ein Team, das einen Umbau „für Agenten“ erwägt, hat nun eine Vorlage, um den Vergleich an der eigenen App durchzuführen.