Wann Sie Next.js nicht einsetzen sollten

Wir bauen in einem Framework und nehmen nichts außerhalb davon an. Das macht diese Seite zu der, die Sie auf dieser Website am skeptischsten lesen sollten

• und zugleich zu der, die es am ehesten zu haben lohnt: Ein Unternehmen, das nicht benennen kann, wo sein Werkzeug falsch liegt, beschreibt ein Produkt, keine Haltung.

Fünf Fälle. In jedem davon würden wir es Ihnen sagen, statt das Projekt anzunehmen.

1. Eine Content-Website ohne Anwendung darin

Eine Broschürenseite, eine Dokumentation, eine Marketing-Website mit Blog. Wenn nichts daran über ein Kontaktformular und ein Navigationsmenü hinaus interaktiv ist, ist Next.js sehr viel Maschinerie für HTML.

Astro, Eleventy oder Hugo erzeugen dasselbe Ergebnis mit einem Bruchteil des JavaScripts und einem Build, den Sie jedem erklären können. Das React-Komponentenmodell fängt an, sich zu rechnen, wenn es Zustand zu verwalten und geteiltes Verhalten wiederzuverwenden gibt. Unterhalb dieser Grenze ist es Aufwand, den Sie dauerhaft pflegen.

Das ehrliche Gegenargument: Wenn die Website Teil eines Produkts ist, das ohnehin React einsetzt, ist ein Framework für beides etwas wert. Das ist ein organisatorischer Grund, kein technischer - und trotzdem ein echter.

Dahinter steht eine Zahl, kein Gefühl. Eine Next.js-Route liefert die React- und App-Router-Laufzeit aus, ob die Seite sie nutzt oder nicht - auf dieser Website, die auf keiner Route eigenen Client-Code ausliefert, sind das rund 186 KB gzip. Eine vergleichbare Astro-Seite liefert nichts aus, solange Sie nichts anfordern. Wenn die Seite keine Interaktivität hat, die diese Laufzeit rechtfertigt, zahlen Sie sie bei jedem Erstbesuch für ein Komponentenmodell, das Sie nicht verwenden. Der vollständige Vergleich hängt an einer Frage: wie viel Ihrer Seite nach dem Laden noch etwas tun muss.

2. Das Team schreibt kein React

Das ist der Punkt, den Menschen am ungernsten laut sagen.

Ein Framework, das Sie beherrschen, schlägt ein besseres, das Sie gerade lernen - bei jedem Projekt mit einer Frist. Ein Team, das Laravel oder Rails oder Django sicher ausliefert, wird darin eine bessere Anwendung bauen als eine kompetente Next.js-Anwendung, die nebenbei aus der Dokumentation entsteht, und wird sie jahrelang ohne Spezialisten pflegen können.

Sich für Next.js zu entscheiden heißt auch, sich für sein Änderungstempo zu entscheiden. App Router, Server Components und das Caching-Modell haben sich in drei Jahren erheblich bewegt, und 16 hat Middleware, Turbopack und Bild-Standards erneut verschoben. Dieses Tempo ist mit jemandem, der es verfolgt, beherrschbar - und ohne teuer.

Die Frage lautet nicht, ob Ihr Team es lernen kann. Sie lautet, wer in achtzehn Monaten die Release Notes liest - nachdem die Person, die begeistert war, weitergezogen ist. Wenn die Antwort niemand ist, driftet das Framework innerhalb Ihrer eigenen Codebasis aus der Wartung, während es außerhalb aktiv weitergepflegt wird. Das ist die schlechteste Kombination von beidem.

3. Die interessante Arbeit liegt komplett im Backend

Eine Zahlungs-Engine, eine Datenpipeline, ein Planungssystem, eine API mit einem Dutzend Konsumenten. Next.js hat Route Handler und Server Actions, und die sind gut in dem, wofür sie da sind: ein Frontend zu bedienen. Sie sind kein Ersatz für einen Anwendungsserver.

Wenn die Komplexität des Systems in Queues, Workern, langlaufenden Jobs, Transaktionen über Dienste hinweg oder irgendetwas liegt, das ein Deployment mitten im Flug überstehen muss, wollen Sie ein Backend-Framework und einen echten Job-Runner. Next.js kann dann das Frontend sein, das mit ihm spricht - eine völlig sinnvolle Anordnung und ein ganz anderes Projekt als „wir haben es in Next.js gebaut".

Die konkrete Lücke gehört benannt, weil Teams sie spät entdecken: Es gibt keinen überwachten Worker im Framework. Nichts besitzt einen Job, der um drei Uhr nachts fehlschlägt, ihn mit Backoff erneut versucht und ihn immer noch hält, wenn das Deployment durch ist. Sie können das um Next.js herum zusammenbauen - mit einem Queue-Dienst und einem separaten Prozess - und dann haben Sie ein Backend. Die ehrliche Version der Entscheidung lautet also, ob Sie eines bewusst wählen oder versehentlich bei einem ankommen. Gegen Laravel und gegen Express ist dasselbe Argument aus zwei Richtungen.

4. Sie brauchen die Edge und können sie nicht haben

Next.js hat sich bei Arbeit zur Request-Zeit in Richtung Node bewegt. In 16 läuft die proxy-Konvention, die middleware ersetzt, auf Node, und die Runtime ist nicht konfigurierbar.

Wenn Ihre Architektur davon abhängt, Logik an hundert Edge-Standorten auszuführen - Geo-Routing im großen Maßstab, Auth-Prüfungen, die kein Origin berühren dürfen, Request-Shaping für ein globales Publikum -, lohnt es sich, das gegen die aktuelle Richtung des Frameworks zu prüfen, statt es vorauszusetzen. Eine dedizierte Edge-Plattform passt womöglich besser als ein Framework, das diesen Teil zurückstellt.

Das ist der instabilste Punkt dieser Liste, und wir sagen das lieber, als ihn wie eine Dauerwahrheit klingen zu lassen. Er beschreibt, wohin sich das Framework gerade bewegt. Wenn Edge-Ausführung zentral für Ihre Architektur ist, prüfen Sie sie gegen die Version, die Sie einführen wollen, statt gegen diese Seite.

5. Ein einzelnes interaktives Widget auf fremder Seite

Ein Preisrechner in einer WordPress-Seite. Ein Buchungsformular, eingebettet in ein CMS, das Ihnen nicht gehört. Next.js ist ein Framework, um eine ganze Website zu besitzen; wenn Ihnen ein <div> gehört, liefern Sie ein kleines Bundle - reines JavaScript, Preact, ein Web Component - und sparen sich Routing, Rendering-Modell und Deployment-Ziel vollständig.

Woran Sie erkennen, in welchem Fall Sie sind

Drei Fragen, in dieser Reihenfolge. Die Reihenfolge ist wichtig, weil die erste mehr Projekte aussortiert als die anderen beiden zusammen.

1. Wie viel der Seite tut nach dem Laden noch etwas? Fast nichts - dann ist die Antwort ein Static-Site-Generator, kein React-Framework.
2. Wo liegt die eigentliche Schwierigkeit des Projekts? Wenn sie in Jobs, Transaktionen und Integrationen liegt statt im Render-Pfad, wählen Sie zuerst das Backend-Framework und behandeln das Frontend als zweite Entscheidung.
3. Wem gehört das in achtzehn Monaten? Nicht wer es baut. Wer es aktualisiert.

Die zweite Frage beantworten Teams zu schnell, denn eine Integration sieht nach einem Fetch-Aufruf aus, bis sie gebaut ist. Wo die Teile davon tatsächlich laufen lohnt sich, bevor man entscheidet, dass das Frontend alles davon halten kann.

Wenn Sie zwischen zwei konkreten Optionen wählen statt die allgemeine Frage zu stellen, ist der jeweilige Vergleich meist nützlicher als diese Seite: gegen Astro, wenn es darum geht, wie viel JavaScript eine Content-Website ausliefern sollte, gegen Remix, wenn Sie sich bereits für ein React-Framework entschieden haben, gegen Laravel, wenn hinter der Anwendung ein echtes Backoffice steht, und gegen Express, wenn Sie in Wahrheit eine API bauen.

Wo es tatsächlich die richtige Antwort ist

Der Vollständigkeit halber, denn die Liste oben ist kein Argument gegen das Framework:

• Eine Anwendung mit einer öffentlichen, indexierbaren Oberfläche und einer authentifizierten. Beides aus einer Codebasis gut zu rendern, ist das, was Next.js kann und Alternativen meist nicht.
• Commerce, wo der Katalog statisch und schnell sein muss und der Warenkorb nicht.
• Alles, wo Core Web Vitals eine kommerzielle Zahl sind und nicht eine Punktekarte, und wo Sie Kontrolle über den Render-Pfad brauchen, um sie zu bewegen.

Wenn Sie nicht sicher sind, auf welcher Seite dieser Linie Sie stehen, hat diese Frage eine günstige Antwort: ein Audit mit festem Umfang, das sagt, was der Stack Sie kostet - einschließlich der Möglichkeit, dass die Antwort „nichts, das passt so" lautet.

Einer dieser Fälle verdient eine eigene Seite, weil er der häufigste von allen ist: eine Site, die bereits auf WordPress läuft und funktioniert. Dieser Vergleich steht hier, und er argumentiert über weite Strecken gegen den Umzug.