- Das Middleware-System von Next.js bietet nur eingeschränkte Logging-Konfigurationsmöglichkeiten, und das Standard-Logging ist nur in der Entwicklungsumgebung aktiviert, wodurch sich Probleme in Produktion nur schwer nachverfolgen lassen
- In der Middleware können praktisch nur Header weitergegeben werden, und ein Chaining mehrerer Middlewares wird nicht unterstützt, was komplexere Logging-Implementierungen einschränkt
- Logging mit AsyncLocalStorage zeigt in der Edge-Runtime unerwartetes Verhalten, und das Teilen von Kontext zwischen Seiten und Middleware funktioniert nicht zuverlässig
- Auch mit einem Custom Server lassen sich die Logging-Probleme kaum lösen, und die Designbeschränkungen von Next.js zwingen Entwickler zu einer bestimmten Arbeitsweise
- SvelteKit von Vercel bietet flexible Middleware und Mechanismen zur Datenweitergabe und zeigt damit ein entwicklerfreundlicheres Design als Next.js
Hintergrund der Logging-Probleme in Next.js
- Beim Betrieb eines Next.js-Dienstes und dem Versuch, Produktionslogs zu erfassen, stellte sich heraus, dass die eingebaute Logging-Funktion nur in der Entwicklungsumgebung aktiv ist
- Wer ein für den Betrieb geeignetes Logging-System implementieren will, stößt dabei schnell an die Grenzen von Next.js
Grenzen der Middleware
- Laut offizieller Dokumentation wird Middleware vor dem Routing ausgeführt und eignet sich für Funktionen wie Authentifizierung, Logging und Redirects
- In der Praxis ist die Zahl übergebbarer Parameter auf vier begrenzt, und tatsächlich lassen sich nur Header sinnvoll weiterreichen
- Eine Struktur zum Verketten mehrerer Middlewares oder zu deren Kombination wird nicht unterstützt
- In Node.js gibt es mit Express und anderen Frameworks etablierte Middleware-Praktiken, doch in Next.js lassen sie sich nicht vernünftig anwenden
Umgehungsversuch mit AsyncLocalStorage
- Es wurde versucht, mit pino und AsyncLocalStorage Logging-Instanzen auf Middleware-Ebene zu verwalten
- Zwar lassen sich in der Middleware Logs pro Request in einem eigenen Kontext speichern, doch dieses Verhalten funktioniert nur zuverlässig in der Browser-Umgebung
- Der Grund dafür ist, dass Next.js-Middleware standardmäßig die Edge-Runtime verwendet; selbst bei Konfiguration auf die nodejs-Runtime bleibt das je nach Projekt instabil
Probleme in Seitenkomponenten
- Wird die Logging-Funktion in echten Seiten- oder Layout-Komponenten aufgerufen, liefert
logger() null zurück
- Es gibt ein strukturelles Problem, bei dem der in der Middleware erzeugte Logger-Kontext nicht in den asynchronen Rendering-Kontext weitergereicht wird
- Als Ausweg bleibt nur, Logging-Informationen wie
requestId per Header zu übertragen; dadurch wird der Code komplizierter und auch die Import-Struktur unübersichtlicher
- Auch in Client Components ist eine ähnliche zusätzliche strukturelle Trennung nötig
Versuch mit einem Custom Server
- Nach dem Beispiel aus der offiziellen Dokumentation wurde mit
http.createServer und app.getRequestHandler von next.js experimentiert
- In dieser Umgebung sollte AsyncLocalStorage erneut genutzt werden, doch auch hier zeigte sich wieder, dass kein Kontextabgleich zwischen Middleware, Seite und Custom Server möglich ist
- Grundsätzlich verwendet nur das Innere von Next.js AsyncLocalStorage korrekt; Entwicklern wird dieselbe Möglichkeit nicht gegeben
- Praktisch bleiben für die Übergabe von Middleware an Seiten nur Response-Header (Änderungen) sowie Redirects oder Rewrites des Pfads
- Aus Sicht der Nutzer ist damit eine flexible Erweiterung oder die Übergabe eigener Kontexte äußerst schwierig
Vergleich mit SvelteKit
- SvelteKit von Vercel bietet ein flexibleres Middleware-System als Next.js
- Über das Objekt
event.locals können Request-Daten frei weitergegeben werden
- Mehrere
handle-Funktionen lassen sich definieren und verketten, wodurch komplexe Logik leichter umsetzbar ist
- SvelteKit zeigt ein entwicklerfreundliches Design und steht damit im deutlichen Kontrast zu den Beschränkungen von Next.js
- Obwohl SvelteKit ebenfalls ein Produkt von Vercel ist und als Nebenprojekt gegenüber Next.js gelten könnte, bietet es die bessere Erfahrung
Kritik am Issue-Tracker und an der Ökosystem-Kultur
- Der offizielle GitHub-Issue-Tracker von Next.js reagiert offenbar kaum auf Nutzerfeedback
- Selbst populäre Issues oder Bugs bleiben oft lange ohne Antwort oder Lösung liegen
- Auch wenn man ein minimales Reproduktionsbeispiel vorbereitet und ein Issue einreicht, folgt oft keine echte Rückmeldung oder weitere Maßnahme
Fazit und Selbstkritik
- Die in Next.js auftretenden Bugs und strukturellen Begrenzungen beeinträchtigen wiederholt die Produktivität von Entwicklern und deuten auf grundlegenden Verbesserungsbedarf hin
- Im Vergleich zu anderen Frameworks wie SvelteKit fällt Next.js trotz seiner Rolle als Hauptprodukt bei der Nutzbarkeit zurück
- Ein sofortiger Ersatz von Next.js ist zwar schwierig, doch für zukünftige Projekte möchte man andere Optionen stärker in Betracht ziehen
7 Kommentare
Offenbar hat man noch nicht darüber nachgedacht, dass React die Produktivität beeinträchtigt.
Diesmal habe ich aus rein persönlichem Interesse einmal Webentwicklung ausprobiert, also ein Bereich, der überhaupt nichts mit dem Feld zu tun hat, in dem ich ursprünglich entwickelt habe. Ich habe mit dem Next.js v15 App Router ein Board gebaut ... aber jedes Mal, wenn ich solche Beiträge sehe, verliere ich irgendwie die Motivation, im Web-Bereich etwas Neues auszuprobieren. Warum ist dieses Ökosystem nur so instabil? Und wenn dann wieder etwas Neues erscheint, stürzen sich alle darauf, nutzen es eine Weile und schimpfen dann wieder, während sie nach etwas anderem suchen? Webentwicklung scheint wirklich nicht leicht zu sein.
Die schnelle Veränderung ist in dieser Branche zwar sowohl ein Vorteil als auch ein Nachteil, haha. Aber die Ursache des im Artikel beschriebenen Problems ist letztlich Vercels Störfeuer. Wenn ihr Frontend macht, solltet ihr bei Vercel etwas vorsichtig sein T_T
Vielleicht liegt es daran, dass ich meine Karriere im Web begonnen habe, aber im Web entwickelt man ursprünglich genau mit diesem gewissen Flair(?) (vor allem im Frontend) haha
So ein rasanter, ständig wechselnder Stil ...
Bei JS ist das irgendwie oft so. Es gibt einen ganzen Haufen Dinge, die angeblich gut sind, aber jedes davon hat ein bisschen seine Probleme und ändert sich dem Trend folgend ständig schnell ...
Vielleicht empfinde ich das auch so, weil ich früher vor allem mit Java, EJB und Struts gearbeitet habe.
Hacker-News-Kommentare
Ich stimme zu 100 % zu, ich hatte genau dieselben Probleme und werde Next.js nie wieder verwenden und künftig auch allen Teams im Unternehmen empfehlen, Alternativen zu nutzen.
Next.js hat eine riesige Abstraktionsschicht, die für 99,9999 % aller Projekte unnötig ist; und in den wenigen Fällen, in denen man so etwas wirklich braucht, ist es meiner Meinung nach besser, lieber mit Komponenten auf niedrigerer Ebene eine maßgeschneiderte Lösung zu bauen.
Von allen Technologien, die ich verwendet habe, war Next.js mit Abstand die schlechteste.
Ich bin wirklich erleichtert, dass ich mit dieser Meinung nicht allein bin.
Ich habe mit Next.js eine mittelkomplexe, umsatzgenerierende Produktions-App gebaut, anfangs mit Vercel und Google Firebase, später dann auf Self-Hosting umgestellt und zu Pocketbase gewechselt.
Pocketbase war die einzige Erfahrung, die okay war, alles andere war wirklich furchtbar.
Endlose Komplexität, ständige Breaking Changes, schwer zugängliche Dokumentation – nichts davon war einfach.
Ich bin überzeugt, dass wir heute besser dastünden, wenn man die Frontend-Trends der letzten fünf Jahre zurückgedreht und sich darauf konzentriert hätte, die damals vorhandenen Technologien vernünftig zu lehren.
Ich habe auch einige komplexe React-Frontends gebaut; React mag ich ebenfalls nicht besonders, aber Next.js war noch schlimmer.
Ich habe auch ein CMS mit Go und Vanilla JS gebaut; vielleicht war die DX etwas schwächer, aber ich hatte zumindest das Gefühl, tatsächlich zu wissen, was passiert.
Ich verstehe nicht, warum ich bei React und Next.js auch nach sechs Jahren immer noch raten muss, was eigentlich passiert.
Ich habe zwar genug Erfahrung gesammelt, um die Verwicklungen des Frameworks irgendwie zu entknoten, aber insgesamt wirkt es einfach viel zu chaotisch und schlecht entworfen.
Bei Go gab es nach den ersten sechs Monaten kaum noch Überraschungen, und auch alte Codebases sind immer noch solide.
Schade, dass man so eine Erfahrung im Frontend offenbar nicht hinbekommt.
Meiner Erfahrung nach sind die rauen Kanten von Next.js keine Bugs, sondern Features.
Es fühlt sich so an, als wäre alles absichtlich darauf ausgelegt, Nutzer zur Aufgabe zu treiben und sie an das Hosting von Vercel zu binden.
Ich glaube, dass es künftig noch schlimmer wird.
Sogar Online-Kurse wie bei PluralSight pushen bei React-bezogenen Kursen inzwischen nur noch Next.js.
Ich weiß nicht, warum es so weit gekommen ist, aber hier sind wir nun.
In meinem Fall ist Sharepoint die noch schlimmere schlechte Erinnerung, deshalb ist Next.js für mich nur das zweitschlechteste.
Das Frustrierendste an Next.js ist, dass es so tut, als wäre es ein Full-Stack-Framework wie Rails, Wordpress oder Meteor, das alles mitbringt, aber tatsächlich nur bei den unerquicklichsten und am stärksten eingeschränkten Teilen eine Meinung hat – Middleware, Bildskalierung, SSR usw. –, während es wirklich wertvolle Entscheidungen wie Datenbank, ORM oder Kommunikationsprotokolle den Nutzern überlässt.
In Wirklichkeit unterscheidet es sich stark von Rails/Wordpress/Meteor; eigentlich sollte ein Framework die Infrastruktur definieren, aber hier ist es eher so, dass die Infrastruktur das Framework dominiert.
In meinem Dashboard sind „Fluid Active CPU“ und „ISR Writes“ die größten Verbrauchsposten, und ich zahle jedes Mal 20 Dollar und hoffe einfach, nicht über 100 % zu kommen.
Die Bezeichnungen der Posten sind voller Star-Trek-artiger Fachbegriffe, und ich habe nicht einmal Lust, sie zu lernen, weil sie in der nächsten Major-Version sowieso wieder anders heißen werden.
Erstaunlich viele Leute aus meinem Bekanntenkreis, die früher von Zeit begeistert waren, haben ihre Projekte und Kunden am Ende doch woandershin migriert.
Wenn Vercel mich fragen würde, was im nächsten Major-Release geändert werden sollte, könnte ich nur sagen: „Alles ab dem App Router war eine Fehlentscheidung.“
Ich weiß nicht, wie man sich davon wieder erholen soll.
Ich denke, viele Probleme von Next.js kommen daher, dass man oft nicht genau weiß, wo der Code tatsächlich ausgeführt wird.
Browser, Middleware, Edge und Node, SSR – alles wird vermischt, und daraus entsteht enorme Komplexität.
Sinnvoll ist so etwas in kniffligen Fällen wie diesen:
wenn man einen globalen B2C-Dienst betreibt und mit Edge-Semantik die Latenz reduzieren möchte
wenn man bereit ist, das teure Hosting von Vercel zu bezahlen
wenn man nur eine nicht allzu komplexe Architektur ohne Background Jobs braucht
Ansonsten sind ein react-vite-SPA oder traditionelles SSR mit Rails viel unkomplizierter.
Ich stimme selbst diesen Bedingungen nicht zu.
Selbst wenn Next.js in so einen Fall passen würde, scheint mir der Verlust an Produktivität und Wartbarkeit den Preis überhaupt nicht wert zu sein.
Ich nutze derzeit Lustre von Gleam und werde nicht zurückblicken.
Auch die Keynote des Elm-Gründers ist für mich ein Gegenbeispiel zu Next.js.
https://www.youtube.com/watch?v=sl1UQXgtepE
Vercel wird als Krebsgeschwür des modernen Webs bezeichnet.
Das Unternehmen dringt in jedes Framework-Ökosystem ein und missbraucht es zur Vermarktung kostenpflichtiger Pläne, während es nur so tut, als gehe es ihm um Open Source, Wettbewerb und die Weiterentwicklung des Webs.
Selbst im ersten Fall glaube ich nicht, dass der Einsatz von Vercel und SSR die Performance-Engpässe tatsächlich beseitigt.
Die meisten Performance-Probleme kommen aus ganz grundlegenden Ursachen wie zu großen Bundle-Größen oder unzähligen langsamen API-Aufrufen.
Grundlegendes Profiling, Optimierung und Vereinfachung bringen viel mehr als zusätzliche Architekturkomplexität.
Ich kann mich mit dem Punkt „das Problem, nicht zu wissen, wo der Code läuft“ sehr identifizieren.
Früher hielt ich den JavaScript-Universalismus für einen Vorteil, inzwischen fühlt sich genau das wie das Problem an.
Wir nutzen in unserer Firma Inertia.js + Vue, und insgesamt ist der Aufbau viel einfacher: die Stärke des Frontend-Renderings bleibt erhalten, aber das Routing läuft zu 100 % auf dem Server, und eine separate API braucht man auch nicht.
Man kann Inertia auch mit React oder Svelte nutzen.
Anfangs hatten wir Nuxt im Einsatz, aber das war so komplex, dass wir gleichzeitig einen Backend-Server und einen Frontend-Server betreiben mussten, und es war schwer zu verstehen, wo der Code eigentlich läuft.
Jetzt ist die Trennung klar: PHP ist Server, JS ist Browser, und wir müssen darüber gar nicht mehr nachdenken.
Das ist für uns ein riesiger Vorteil.
Ich finde, damit ist der Kern gut zusammengefasst.
Vercel strebt Performance-Optimierungen über React Server Components, Partial Pre-rendering, Edge-Server, Streaming usw. an.
Alle ungewöhnlichen Design- und API-Entscheidungen stammen letztlich daher.
In manchen Fällen kann das hilfreich sein, aber schon ein sinnvoll eingesetztes SSR in einigen Edge Functions kann vieles verbessern.
Danke für das Feedback.
Wir kennen die DX-Probleme bei Middleware und haben mit Version 15.5 einen großen Fortschritt geliefert, indem wir Node-Runtime-Support eingeführt haben[1].
Wenn wir zurückgehen könnten, hätten wir es vermutlich eher in etwas wie Routing Middleware oder Routing Handler umbenannt – als fortgeschrittene Escape Hatch auf Routing-Ebene, die an die CDN-Edge weitergereicht werden kann.
Wenn Logging benötigt wird, kann man dafür OpenTelemetry nutzen und es gemäß dem
instrumentation.ts-Muster[2] umsetzen.[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation
Danke für die Antwort.
Aber wenn du mit Instrumentation und Observability antwortest, klingt das so, als würde ein simples Logging-Problem wieder mit einer weiteren komplexen Schicht gelöst werden.
Nicht jede App braucht OpenTelemetry.
Ich verstehe nicht, warum etwas Normales wie
logger().info()nicht einfach funktioniert.Das gibt es in jeder anderen Sprache und jedem anderen Framework – ich verstehe nicht, warum das hier so schwierig sein muss.
Weil die Stimmung hier eher negativ ist, möchte ich zuerst klarstellen: Next.js ist eine hervorragende Software, wenn es zum tatsächlichen Einsatzzweck passt.
Ich denke, es ist gut gemachte Software, die Millionen von Websites trägt.
Das Problem liegt in fehlenden detaillierten Referenzen und mangelnder Dokumentation: Die Dokumentation sagt einem zwar, was es gibt, aber kaum, wie man es konkret nutzt, wann etwas ausgeführt wird oder welche typischen Fallstricke es gibt.
Für Einsteiger ist sie freundlich, aber bei komplexen Runtime-Kontexten oder abgeleiteter Komplexität fehlt die Führung.
Das ist ein Trend, den man derzeit in vielen Projekten sieht.
Die Balance zwischen User-Friendliness und ausführlicher Erklärung ist extrem schwer.
Ich hoffe, das Projekt entwickelt sich weiter.
Noch einmal in einem Satz gesagt:
Der Autor dieses Beitrags hat versucht, Funktionen überall gleich aufzurufen, ohne die Unterschiede zwischen den Domänen zu verstehen.
Die Fehler in Next.js entstehen daraus, dass man Domains mit grundsätzlich unterschiedlichem Charakter gewaltsam zusammenführen wollte.
Wenn man Edge, SSR, Node und Client so miteinander vermischt, wächst die Komplexität zwangsläufig.
Das lässt sich auch nicht durch Dokumentation lösen – sie stiftet eher noch mehr Verwirrung.
Mir wurde in einem Reddit-Kommentar einmal Instrumentation empfohlen.
Wenn ich ungefähr zur gleichen Zeit OpenTelemetry in Next eingerichtet hätte und die Dokumentation damals anders gewesen wäre, hätte ich nach so einer Erfahrung vermutlich auch einen Blogpost geschrieben.
Dafür könnt ihr nichts, aber fast alle OpenTelemetry-Pakete sind als experimentell gekennzeichnet, weshalb sie für Produktion nicht vertrauenserweckend wirken.
Auch das Einrichten der pino-Instrumentation war extrem schwierig.
Damit pino korrekt funktioniert, muss man es zu
serverExternalPackageshinzufügen.Die Auto-Instrumentierung war zudem extrem empfindlich gegenüber der Import-Reihenfolge, und nur der Default-Export von pino wurde instrumentiert.
Auch modul-lokale Variablen funktionierten nicht wie erwartet, sodass ich
globalThisverwenden musste.Und trotzdem bin ich am Ende noch auf https://github.com/vercel/next.js/issues/80445 gestoßen.
Am Ende hat es zwar funktioniert, aber die Einrichtung war wirklich unerquicklich.
Diese Erfahrung hatte ich wegen eines manuellen Routers (= ohne
vercel/otel).Wenn man sich schon dazu entschieden hat, serverseitige Middleware zu unterstützen, verstehe ich nicht, warum es immer noch keine Middleware-Kette gibt, also das Verknüpfen mehrerer Funktionen, sondern nur genau eine unterstützt wird.
Das ist eine Funktion, die praktisch jedes andere Server-Framework bietet.
Ich kann kaum glauben, dass es wirklich stimmt, dass man „keine mehreren Middleware-Komponenten verketten“ kann.
https://nextjs.org/docs/messages/nested-middleware
Dass mehrere Stücke in einer Datei zusammengeführt und dann ausgeführt werden müssen, ist kaum zu glauben.
Wenn ich das richtig lese, behauptet Next.js also ernsthaft, man solle nicht mit mehreren Dateien strukturieren, sondern alles in eine Datei zusammenführen?
Liegt das an Scoping-Problemen, die mehrere Dateien erschweren? Für ein Framework ist das eine völlig absurde Forderung.
Ich kann den Verdacht nicht loswerden, dass die meisten dieser absurden Entscheidungen nicht im Interesse des Frameworks getroffen wurden, sondern weil sie für Vercel günstiger sind.
Als ich Next.js zum ersten Mal sah, musste ich sofort an Meteor.js denken.
Ich habe einiges an Zeit investiert, um es in einem privaten Projekt zu lernen, aber wegen der übermäßigen Abstraktion und Starrheit war es schwer, damit über den Prototypenstatus hinauszukommen.
Solche „Batteries included“-Lösungen tauchen immer wieder auf, weil das Setup bequem ist.
Auch auf Hacker News gab es kürzlich beim Vergleich Laravel vs. Symphony Diskussionen darüber, dass solche Dinge auseinanderfallen, sobald es komplex wird.
Vergleicht man diesen Ansatz mit dem modularen Zusammenstecken wie früher bei NodeJS/React-SPAs, sind dort die einzelnen Teile als Low-Level-Abstraktionen unabhängiger, flexibler und leichter austauschbar.
Es gibt auch Nachteile, aber insgesamt wirkt es geschmeidiger als Overengineering, also aufgeschichtete Komplexität.
Dass „Batteries included“ beliebt ist, kann ich völlig nachvollziehen.
Es ist wirklich lästig, eine Menge Tools und Bibliotheken zusammenzubringen und kompatibel zu halten.
Damit dieser modulare Ansatz gut funktioniert, braucht man eher erfahrene Leute, die das Setup sauber aufsetzen.
Ich komme aus der asp.net-Welt, und obwohl es in Startup-Entwickler-Communities oft einen schlechten Ruf hat, ist es in Wirklichkeit ein sehr gut entworfenes Framework.
Es ist zwar „Batteries included“, aber ich konnte mich jederzeit aus dem Framework herauslösen und Dinge überschreiben, und ich hatte nie das Gefühl, gegen das Framework kämpfen zu müssen.
Mit Blazor Server und Blazor Webasm kann man das Frontend komplett in C# schreiben, und beide eignen sich jeweils gut für interne Panels oder SaaS-Apps.
Vor allem kann man aber auch einfach alles mit traditionellem serverseitigem Rendering lösen.
Wer unzufrieden mit Web-Frameworks ist, sollte es meiner Meinung nach unbedingt einmal ausprobieren.
Mittlerweile unterstützt es Cross-Platform gut, ist schnell und leicht zu lernen.
Es gibt eine Lernkurve, aber sobald man die Modulstruktur verstanden hatte, konnte ich alles direkt nach Belieben überschreiben.
Im Vergleich zu anderen Frameworks bin ich damit auch nur sehr selten an Grenzen gestoßen.
Für Leute aus der NodeJS/React-SPA-Welt ist der modulare Einsatz einzelner Bausteine in Angular eher ungewohnt.
Angular ist keine Bibliothek, sondern ein Framework, daher ist das meiste, was man braucht, bereits gut integriert.
(RxJS hat zwar eine gewisse Lernkurve, aber wenn man die Grundlagen beherrscht, ist es sehr leistungsfähig.)
Normalerweise hatte ich bei SPAs nur selten das Gefühl, mit dem Framework zu ringen.
Auch die Dokumentation und Tutorials – einschließlich Tour of Heroes – sind ausgezeichnet.
https://v17.angular.io/tutorial/tour-of-heroes
Die aktuelle Dokumentation findet man unter https://angular.dev/.
Laravel ist ein Erfolgsbeispiel für overengineerte Abstraktion.
Mit Laravel habe ich den Einsatz in Produktion nie bereut.
Etwas anderes Thema, aber mein ganzer Job besteht praktisch darin, immer wieder kleine inkompatible Tools und Bibliotheken miteinander zu verheiraten.
Unser Team ist klein, daher verbringen wir ständig enorme Mengen an Zeit mit Aktualisierung und Wartung, und Probleme mit lange nicht mehr unterstützten Paketen treten häufig auf.
Nicht nur die Erfahrung, auch die anfängliche Zeit für den Systemaufbau und die Wartungskosten sind viel größer, als man denkt.
Als ich es selbst gemacht habe, hatte ich das Gefühl, dass Rails im Vergleich zum Zusammenschustern einzelner Bibliotheken unter Node etwa zehnmal produktiver ist.
Probleme entstehen nur, wenn man mit den Grundpfeilern und der Philosophie des Frameworks unzufrieden ist – zum Beispiel wenn man ActiveRecord nicht mag.
Die Behauptung „wenn die Komplexität steigt, bricht alles zusammen“ ist eher ein Zeichen mangelnder technischer Kompetenz.
Ich bin eigentlich ein großer Verteidiger von React und mochte auch den Wechsel von Class Components zu Hooks.
Aber jedes Mal, wenn ich Next.js verwende, habe ich keine Ahnung, wo es eigentlich falsch abbiegt.
Ich mag viele Frameworks und exotische Sprachen, aber nur bei Next.js habe ich die Erfahrung gemacht, dass ich nicht einmal die Hälfte der Fehlermeldungen verstehe.
Vor allem seltsame Hydration-Probleme haben mich unheimlich viel Zeit gekostet.
Ich verwende weder React noch Next.js.
Persönlich bevorzuge ich HTML+CSS mit etwas Vanilla JS dazu.
Ich habe auch erlebt, dass eine einfache Next.js-Landingpage in Firefox kaputtging.
Noch schlimmer war die Form des Scheiterns: Über allen Inhalten lag nur ein schwarzer Bildschirm mit weißer Schrift und der Meldung „An application client side error has occurred“.
Es hat mich überrascht, dass nicht einmal eine einfache Landingpage rendern konnte, und als ich herausfand, dass ein JS-Frontend-Framework dahintersteckte, dachte ich nur: „Ja, das ergibt irgendwie Sinn.“
Für Leute, die Nutzer überzeugen wollen, mag das hinnehmbar sein, aber außerhalb der Branche kann so etwas ziemlich befremdlich wirken.
Ich denke, Next hat sich inzwischen selbst ruiniert.
So läuft es nun einmal bei allem, was den VC-Zyklus durchläuft.
Ich kann es jetzt nicht mehr verwenden, und Vite ist für mich die Standardoption.
Ich bevorzuge grundsätzlich leichtere Lösungen.
Der Begriff „middleware“ in Next.js ist leicht missverständlich.
Tatsächlich handelt es sich eher um eine leichtgewichtige Edge Function, die vor Erreichen der App ausgeführt wird – für Header-Prüfungen, Routing, einfache Guards usw.
Sie läuft in der Edge-Runtime und damit in einer anderen Umgebung als der App-Server.
Auch der Autor scheint Edge- und Server-Runtime zu verwechseln.
Mir selbst waren diese Grenzen anfangs auch unklar, und weil alles so stark auf JavaScript zentriert ist, verschwimmt die Trennung.
Man braucht dafür ein klares mentales Modell.
Die Komplexität von Next.js zu kritisieren, fühlt sich ein wenig so an, als würde man sich darüber beschweren, dass in einem Werkzeugkasten außer dem Hammer noch andere Werkzeuge liegen.
Das Problem ist, dass die Komplexität von Next.js selbst verschuldet ist.
Der Begriff Middleware hat in praktisch jedem Framework bereits eine klar etablierte Bedeutung.
Normalerweise ist Middleware eine Kette von Funktionen, die vor der Anfrageverarbeitung innerhalb derselben Runtime und desselben Prozesses aufgerufen werden.
Next.js platziert das stattdessen auf der Edge und erlaubt nur genau eine Instanz.
Die meisten Apps brauchen diese Edge-Funktionen gar nicht; man sollte nur dann per Opt-in darauf zugreifen, wenn man sie wirklich braucht.
In der Werkzeugkasten-Analogie würde man die Werkzeuge hinzufügen, die man tatsächlich benötigt.
Den Begriff „middleware“ sollte Next.js in diesem Kontext nicht verwenden.
Das ist nicht nur Fehlgebrauch, sondern Begriffsmissbrauch.
Middleware hat in der Web-App-Branche seit Langem eine feste Definition; wenn man etwas völlig anderes meint, hätte man den Begriff nicht verwenden dürfen.
Ich nutze den App Router von Next.js und bin damit zufrieden.
Mit Next.js ist es sehr einfach, zwischen Frontend und Backend hin- und herzuwechseln, und ich glaube, genau deshalb denken viele Leute, dass dieser Teil irgendwie ebenfalls abstrahiert sei.
Tatsächlich ist es aber ein sehr komplexes System, und man muss diese Komplexität selbst tragen.
Mehr Komplexität bedeutet nicht automatisch, dass etwas langsamer oder unproduktiver ist.
Ein getrenntes Frontend- und Backend-System ist oft viel leichter zu handhaben, aber dafür eben auch lästiger.
Selbst wenn man React kennt, fühlt sich Next.js wie etwas an, das man komplett neu lernen muss, und vieles daran versteht man erst, wenn man es selbst durchlebt hat.
Wenn man sich aber einigermaßen eingearbeitet hat, ist es ein sehr bequemes System, mit dem man mühelos zwischen Frontend und Backend wechseln kann.
Viele haben meinen Kommentar heruntergevotet; ich würde gern wissen, warum.
Ich möchte jederzeit dazulernen.
Ich würde mir wünschen, dass in solchen Diskussionen nicht nur blind negativ reagiert wird, sondern dass man sich ernsthaft damit auseinandersetzt.
Endlich lese ich einmal eine vernünftige Meinung.
Es ist etwa so, als würde man gedankenlos das Paket-/Modulkonzept von Python mit dem Modulbegriff von Go verwechseln und sich dann darüber beschweren, dass Go schlecht sei.
Ein grundlegendes Verständnis der verwendeten Technologie braucht man immer.
Seit Next.js auf den App Router umgestellt hat, fühlt es sich an, als hätte man die Verbesserung einer Express-API Bootcamp-Absolventen überlassen.
Gemessen daran, dass praktisch alle Server-Schnittstellen – Servlet, rack, plug usw. – über Jahre hinweg auf dieses russische-Puppen-artige Design hinausgelaufen sind, war selbst die Express-API noch ein vergleichsweise reifer Ansatz.
Nicht nur die miserable Middleware-API, sondern auch die Entscheidung, Request-Parameter abzuschaffen und durch globale Funktionen wie
cookies()oderheaders()zu ersetzen, war äußerst seltsam.Vermutlich stecken irgendwelche grundlegenden Design-Beschränkungen dahinter, aber von außen sieht es so aus, als würde man sämtliche bisherigen Lehren wegwerfen und alte Fehler erneut machen.
Dazu kommt noch die Unterstützung für eine Lowest-Common-Denominator-Edge-Runtime, was die Beschränkungen weiter verschärft.
Ich versuche bei neuen Projekten immer, verschiedene Stacks auszuprobieren.
Ich habe Frontend und Backend mit express+react, angular, vue, next, nuxt, go, .net, node, php und mehr verwendet.
Bei den meisten Frameworks entdecke ich Vor- und Nachteile und habe auch Spaß daran, etwas Neues zu lernen.
Next.js ist die einzige Ausnahme: Während ich eine ziemlich große App gebaut habe, fühlte sich vom Anfang bis zum Ende alles einzeln betrachtet seltsam oder langsam oder unbequem oder grotesk schlecht entworfen an.
Ich pflege sie immer noch, und es ist das einzige „Ding“, das ich regelrecht hasse.
Das Ökosystem soll okay sein und es ist populär, aber meine reale Erfahrung damit war so negativ, dass sie sich nicht mehr umkehren lässt.
Seltsam, aber so ist es.
Kennt zufällig jemand die Postanschrift von Vercel?
Dieser Issue ist nächstes Jahr alt genug für die Einschulung, und ich würde der Firma gern eine Karte schicken mit „Viel Erfolg in der Schule!“
https://github.com/vercel/next.js/issues/10084
Das, was in dem Hacker-News-Kommentar darunter steht, trifft es genau.
„Next.js hat in 99,9999 % der Projekte eine riesige Abstraktionsschicht, die man nicht braucht; und in den wenigen Fällen, in denen man so etwas wirklich braucht, ist es meiner Meinung nach besser, stattdessen mit Low-Level-Bausteinen eine maßgeschneiderte Lösung zu bauen.“
Eine unnötig überkomplexe API, instabil und unvollständig, aber trotzdem dreist als production ready beworben, und wegen der enormen Abhängigkeit von Vercel ist ein ernsthafter Betrieb außerhalb von Vercel kaum möglich.