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.

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.

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".

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.

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.

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.