Was man wissen sollte, bevor man sich für Next.js entscheidet

• Ein Beitrag über die Offenheits- und Governance-Probleme von Next.js: das Fehlen von Adaptern, mangelnde offizielle Serverless-Unterstützung, Vercel-spezifische Codepfade und Vercels Umgang mit Sicherheitsvorfällen
• Die Wahl des Technologie-Stacks ist eine wichtige Entscheidung, die sich langfristig auf Entwicklungsgeschwindigkeit, Qualität und Teamzusammensetzung eines Projekts auswirkt
• Open-Source-Software gibt Nutzern die Freiheit, Code zu erweitern und zu verändern, und bietet den Vorteil, Vendor Lock-in zu vermeiden
• Next.js wird zwar als Open Source bereitgestellt, ist aber eng mit der Infrastruktur von Vercel verflochten
• Es ist nicht problematisch, wenn Unternehmen mit selbst entwickelter Open-Source-Software Geld verdienen, aber die Grenze zwischen Open Source und Unternehmen muss klar sein, damit das Modell nachhaltig ist

Hintergrund und Interessenkonflikte des Autors

• Der Autor arbeitet seit mehr als vier Jahren bei Netlify, und Netlify steht in Konkurrenz zu Vercel
• Durch den direkten Aufbau von Infrastruktur und Tooling bei Netlify, um den vollen Funktionsumfang von Next.js zu unterstützen, hat er ein tiefes Verständnis der internen Struktur von Next.js gewonnen
• Lange Zeit hat er sich gescheut, die Probleme öffentlich anzusprechen, entschied sich aber nach Vercels jüngstem Umgang mit Sicherheitsproblemen zu diesem Beitrag, da er der Ansicht ist, dass dieser der Community geschadet hat

# Probleme bei Offenheit und Governance von Next.js

Fakt #1: Fehlende Adapter

• Die meisten modernen Frameworks lassen sich je nach Deployment-Ziel flexibel über Adapter konfigurieren
• Next.js unterstützt Adapter nicht offiziell, und das Ausgabeformat hat eine proprietäre, nicht öffentliche Struktur, die nur bei Vercel verwendet wird
• Vercel hat zwar die Build Output API geschaffen, doch Next.js unterstützt sie weiterhin nicht
• Dadurch müssen Anbieter außerhalb von Vercel auf Basis undokumentierter APIs entwickeln, was sie anfällig für unerwartete Änderungen macht
• Cloudflare und Netlify arbeiten über OpenNext gemeinsam an der Entwicklung von Adaptern für Next.js, und auch Vercel beteiligt sich inzwischen daran, aber einen konkreten Zeitplan gibt es noch nicht

Fakt #2: Mangelnde offizielle Serverless-Unterstützung

• Die offizielle Self-Hosting-Methode von Next.js basiert auf langlebigen Servern, wodurch sich flexible Skalierung und Kostensenkung in realen Produktionsumgebungen nur schwer umsetzen lassen
• Früher gab es einen Serverless-Modus, der jedoch im Oktober 2022 ohne besondere Erklärung entfernt wurde
• In der offiziellen React-Dokumentation wird erwähnt, dass Serverless-Deployments möglich sind, aber es gibt keine offizielle Dokumentation, wie man dies tatsächlich umsetzt
• Hosting-Anbieter, die Serverless-Umgebungen anbieten wollen, müssen Next.js per Reverse Engineering analysieren und selbst implementieren

Fakt #3: Vercel-spezifische Codepfade existieren

• Next.js enthält nicht öffentliche Codepfade, die nur bei einem Deployment auf Vercel funktionieren (zum Beispiel minimal mode)
• Über diesen Modus kann Vercel Leistungsoptimierungen umsetzen, etwa Middleware am Edge auszuführen
• Middleware ermöglicht es, Logik schnell vor dem Cache-Pfad auszuführen, aber diese Funktion steht nur Vercel zur Verfügung
• Netlify hat zur Unterstützung dieser Funktion ein eigenes dediziertes Engineering-Team eingesetzt und eine eigene Implementierung gebaut, doch das erfordert Ressourcen, die für kleinere Anbieter unrealistisch sind
• Dass nur Vercel offiziell die volle Funktionalität von Next.js bereitstellt, widerspricht dem Open-Source-Gedanken des Frameworks

Sicherheitsvorfall und Vercels Reaktion

• Am 21. März 2025 wurde in Next.js eine schwerwiegende Sicherheitslücke veröffentlicht, die eine Umgehung der Authentifizierung ermöglichte (CVE 9.1)
• Die Schwachstelle bestand darin, dass sich Middleware durch einen bestimmten Header in der Anfrage deaktivieren ließ, wodurch auf geschützte Ressourcen zugegriffen werden konnte
• Die Schwachstelle wurde am 27. Februar gemeldet, aber Vercel begann erst am 14. März mit der Untersuchung
• Nachdem das Problem erkannt war, wurde zwar schnell ein Patch ausgeliefert, doch es dauerte weitere acht Tage, bis andere Anbieter wie Netlify informiert wurden
• Im ursprünglichen Blogbeitrag wurde suggeriert, dass die Firewall von Vercel die Kunden geschützt habe, tatsächlich war das jedoch nicht der Fall
• Dadurch reagierten mehrere Anbieter und Entwickler auf Basis falscher Informationen oder gerieten in Verwirrung, und es ist möglich, dass noch immer viele Websites verwundbar sind

Vercels Eigentümerschaft an Next.js und Verantwortung gegenüber Open Source

• Dass Vercel Eigentümer von Next.js ist, lässt sich nicht bestreiten, und auch die Monetarisierung ist legitim
• Da es jedoch als Open Source angeboten wird, sollten auch andere Anbieter es unter gleichen Bedingungen nutzen können, und in diesem Punkt bleibt Vercel hinter den Erwartungen zurück
• Redis, Grafana und WordPress betreiben ebenfalls kommerzielle Services zusammen mit Open-Source-Projekten und bewahren dabei Offenheit und Interoperabilität

Fazit

• Für welches Framework man sich entscheidet, ist letztlich Sache des Nutzers, und wenn Next.js zur Lösung der eigenen Probleme optimal ist, kann man es selbstverständlich weiter verwenden
• Wichtig ist jedoch, die aktuellen strukturellen Probleme und Einschränkungen von Next.js zu kennen, bevor man sich dafür entscheidet

[GN⁺]

Hacker-News-Kommentare

• Ich habe Next.js verwendet, aber das Projekt aufgegeben, als ich vom Page Router zum App Router gewechselt bin. Die Erfahrung mit dem App Router war so schlecht, dass ich Next.js seitdem nicht mehr verwenden wollte.
  • Vercel tut so, als wäre es Open Source, baut aber Mauern auf, um Nutzer auf ihrer Hosting-Plattform einzusperren.
• Bei Vercel hatte ich schon immer ein leicht ungutes Gefühl. Als ich versucht habe, Next.js auf einem VPS selbst zu hosten, bin ich in kleine Fallen getappt, die sie eingebaut hatten.
  • Die Art, wie sie mit dieser Schwachstelle umgegangen sind, hat mich noch unruhiger gemacht.
  • Vercels anfängliche Erklärung, ihre Firewall habe Kunden "aktiv geschützt", hat einen schlechten Eindruck hinterlassen.
  • Es gab Verzögerungen bei der Benachrichtigung anderer Plattformen, was zeigt, dass Vercel weniger Anreiz hat, zu verhindern, dass Schwachstellen in Next.js eingebaut werden.
• Ich warne jeden davor, Next.js zu verwenden. V0 könnte die Verbreitung deutlich erhöhen.
  • Viele neue Entwickler wollen sich nicht mit Deployment und Systemadministration beschäftigen.
  • Wenn man nur React kennt, ist es ein Vorteil, dass man Dinge bekommen kann, ohne SSR lernen zu müssen.
• Ich habe Next.js aufgegeben, weil es bei einem kleinen Projekt 6 bis 7 Sekunden dauerte, bis Änderungen im Browser erschienen.
  • Jetzt nutze ich React SPA und Vite.
• Wir sind letztes Jahr von Next.js zu Vike migriert. Die Developer Experience hat sich stark verbessert.
  • Für die meisten Anforderungen reicht es aus, Seiten vorab zu rendern.
• Ich habe gemischte Gefühle zu Next.js. Einerseits ist es ein Unternehmen, das zusammen mit Investoren ein Framework aufbaut.
  • Da es unter der MIT-Lizenz steht, könnten Netlify oder andere Unternehmen es forken und eine bessere Alternative anbieten.
  • Wenn ich Investor von Vercel wäre, gäbe es keinen Grund, das Investitionsrisiko zu erhöhen, indem ich der Konkurrenz helfe.
  • Vercel unterstützt Open Source, versucht aber gleichzeitig Reibung aufrechtzuerhalten, damit ihre Hosting-Plattform die beste Wahl bleibt.
• Ich bin gerade dabei, den React-Stack für das Unternehmen auszuwählen, in dem ich arbeite. Ich kann mir keinen Grund vorstellen, Next.js gegenüber Alternativen zu wählen.
  • Remix, React Router v7 oder TanStack sind vernünftigere Entscheidungen, wenn man SSR will.
• Ich bin nicht überzeugt, dass ein serverloser Ansatz ein guter Standard ist. Er fügt unnötige Komplexität hinzu.
  • Ich nutze JavaScript im Backend nicht gern.
  • Der Fokus auf Server Components und Next.js wirkte auf mich wie Tunnelblick.
  • Der serverlose Ansatz war wahrscheinlich der Grund für die privilegierte Kommunikation über HTTP-Header.
• Die Entwicklungs-Build-Zeiten sind katastrophal, und es gibt seit Jahren viele Beschwerden, ohne dass das gelöst wurde.
• Vercel und NextJS sollten nicht existieren.
  • Als ich Next einmal ausprobiert habe, bin ich in der Produktion auf viele Hydration-Fehler gestoßen.
  • Das Framework macht alles komplizierter, wegen des potenziellen Vorteils, auf dem Server zu rendern.
  • Das gesamte Framework wirkt wie eine schöne Fassade, um ihre teuren Cloud-Services zu verkaufen.

[ahwjdekf]

Der Autor arbeitet bei Netlify und sagt selbst, dass sein Unternehmen in direkter Konkurrenz zu Vercel steht. Das wirkt nicht besonders objektiv.

[preserde]

Wenn man in letzter Zeit Vergleiche zwischen konkurrierenden Frameworks wie TanStack oder Remix gesehen hat, ist der Inhalt des Artikels im Großen wie im Kleinen im Grunde bereits bekannt. Noch ist der Marktanteil von Next.js einfach sehr groß, und da Vercel auch keine allzu offensichtlichen Schritte zeigt, ist das bislang nicht an die Oberfläche getreten.

[alpharoom]

Zu behaupten, die in dem Artikel vermittelten Informationen seien nicht objektiv, nur weil der Autor bei einem Konkurrenzunternehmen arbeitet, ist ein persönlicher Angriff. Wirkt der Text auch dann noch seltsam, wenn man den Hintergrund und die Interessenlage des Autors ausblendet? Ich halte ihn für nützliche Informationen.