Vanilla JS vs. Next.js: Kein Framework nötig

Ein frisches create-next-app installiert 311 npm-Pakete und erzeugt einen node_modules-Ordner von 187 MB. Verifiziert im Februar 2026. In der Realität liegt der Median-Bundle bei Next.js-Sites bei über 1 MB ab der fünften Dezile. Extreme von 56 MB JavaScript in einer einzigen SPA wurden dokumentiert.

Vanilla HTML/CSS/JS hat null externe Abhängigkeiten. Was du schreibst ist was der Browser lädt. Kein Hydration-Overhead, kein Webpack-Long-Task, kein Dev-Server der 1.247 MB RAM frisst. Das Vanilla JS Briefing erklärt was der Browser 2026 kostenlos mitbringt.

Die Zahlen im Vergleich

MetrikVanilla HTML/CSS/JSNext.js (Standard) Installierte Pakete0311 npm-Pakete node_modules-Grösseexistiert nicht~187 MB Baseline Dev-Server RAMkeiner1.247 MB Build-Config-Dateien05-8 (next.config, tsconfig, postcss...) Client JS bei Auslieferung18 KB (E-Commerce-Test)421-497 kB raw First Contentful Paint0,6-0,9s0,8-1,2s Time to Interactive1,0-1,5s1,5-2,5s Lighthouse Performance95-100 erreichbar70-90 ohne Optimierung Deploy auf Vercelgit push → liveBuild-Step: First 67s, Prod 5m12s Hydration-OverheadkeinerReact-Hydration auf Client Vibe-Coding-IterationBrowser Reload (sofort)Hot Reload (2-5s)

Die Quellen: catchmetrics.io analysierte 300.000 Next.js-Domains. Ein Hacker-News-Benchmark verglich 10 Frameworks, Next.js lieferte 497,8 kB raw gegenüber Marko mit 12,6 kB: ein 39-facher Unterschied in Rohgrösse, spürbar auf jedem Mobilfunknetz. Blake Crosley dokumentierte den No-Build-Stack mit perfektem Lighthouse-Score. Ein Hacker-News-Benchmark verglich 10 Frameworks, Next.js lieferte 497,8 kB raw gegenüber 12,6 kB bei Marko.

Wann Vanilla gewinnt

Landingpages. Portfolios. MVP-Showcases. Content-Sites. Blogs. Widgets. Alles wo der Content beim Laden komplett steht und sich nicht dynamisch verändert.

Ein konkretes Praxisbeispiel: Eine Website mit 37 Blog-Posts, 20 interaktiven JS-Komponenten und 10 Sprachübersetzungen erzielt 100/100/100/100 auf Lighthouse, ohne einen einzigen Build-Step. Kein Tailwind, kein Bootstrap, nur semantisches HTML und CSS Custom Properties.

Wann Next.js trotzdem Sinn ergibt

Große Teams mit geteilten Component Libraries. E-Commerce-Plattformen mit Server-Side-Rendering. Apps mit vielen dynamischen Routen. Projekte die API Routes ohne separates Backend brauchen. Wenn du User-Authentication, Echtzeit-State und Datenbankzugriff brauchst, ist ein Framework die richtige Wahl.

Die Faustregel: Wenn du keine Datenbank brauchst, brauchst du kein Framework. Und für alles dazwischen lohnt sich ein Blick auf HTMX oder Alpine.js bevor du die volle React-Maschinerie startest.

Wie du mit Vanilla JS Lighthouse 100 erreichst und was der komplette Vibe-Coding-Workflow ist, steht in den verlinkten Artikeln.

Quellen

• Crosley, Blake, "The No-Build Manifesto" (blakecrosley.com, 2025)
• dev.to/clevertech88, "The Hidden Cost of JavaScript Frameworks" (E-Commerce-Benchmark, 2026)
• catchmetrics.io, "Next.js Bundle Sizes: Insights from 300,000 Domains"
• plavecstudio.com, "Next.js 15 Performance: Real Benchmarks" (FCP/TTI/LCP Ranges)
• Hacker News, "I built the same app 10 times" (Framework-Benchmark, 2026)
• dev.to/nyloodzz, "Why I Ditched WordPress for Vanilla JS + Edge" (Lighthouse 100)
• DistantJob, "VanillaJS vs React: Which Requires Less Code?"
• dev.to/clevertech88, "The Hidden Cost of JavaScript Frameworks" (Build-Zeiten, RAM-Vergleich)
• Plavec Studio, "Next.js 15 Performance: Real Benchmarks" (FCP/TTI-Daten)

Weiter lesen: Vanilla JS Checkliste · Next.js Checkliste · Vanilla JS Briefing · Code-Kommentare · Software-Architektur