Next.js vs. Remix: Die Entscheidung ist eine über Caching

Diese beiden werden ständig verglichen, und die Vergleiche sind meist eine Feature-Tabelle. So geht diese Entscheidung in der Praxis aber nicht schief.

Der Unterschied, der sich nach achtzehn Monaten zeigt, liegt darin, was jedes Framework über Ihre Daten annimmt.

Remix nimmt an, dass Ihre Daten frisch sind

Das Remix-Modell ist ein Loader pro Route, der bei jedem Request läuft. Daten werden geholt, die Seite rendert, die Antwort geht raus. Caching ist etwas, das Sie bewusst hinzufügen - HTTP-Header, ein CDN davor, eine eigene Schicht.

Die Folge: Remix-Anwendungen sind tendenziell standardmäßig korrekt und standardmäßig langsamer. Nichts ist veraltet, weil nichts zwischengespeichert wird, bevor Sie es zwischenspeichern. Wenn etwas langsam ist, ist der Grund meist sichtbar: Ein Loader tut zu viel.

Next.js nimmt an, dass Ihre Daten cachebar sind

Das Next.js-Modell ist das Gegenteil. Routen sind statisch, solange nichts sie dynamisch macht, fetch trägt Caching-Semantik, und es arbeiten vier verschiedene Caching-Schichten gleichzeitig.

Die Folge: Next.js-Anwendungen sind tendenziell standardmäßig schnell und gelegentlich falsch. Der häufigste Produktionsfehler, den wir finden, ist nicht Langsamkeit - es ist eine Seite, die Daten aus einer Schicht ausliefert, an die sich niemand erinnert hat.

Das ist der Handel, klar benannt:

Keines ist besser. Sie scheitern in unterschiedliche Richtungen, und Sie sollten die Richtung wählen, die Ihr Team bemerkt.

Dieser letzte Halbsatz ist die ganze Empfehlung. Eine langsame Seite wird von Nutzern gemeldet, taucht im Monitoring auf und ist niemandes Schuld, die man zugeben müsste. Eine veraltete Seite meldet ein einzelner Kunde, sie lässt sich von der Entwicklerin, die zehn Minuten später nachsieht, nicht reproduzieren, und sie wird zweimal als „bei mir geht es" geschlossen, bevor jemand den Cache findet. Wenn Ihr Team klein ist und kein Performance-Monitoring hat, ist der Fehler, den Sie tatsächlich sehen können, mehr wert als der, den Sie nicht sehen.

Der zweite echte Unterschied: wo die Grenze liegt

Remix zieht die Server-Client-Trennung auf Routenebene: Loader und Actions auf dem Server, Komponenten im Client. Eine einfache Linie, die man im Kopf behält.

Next.js zieht sie mit Server Components pro Komponente - mächtiger und subtiler. Gut gemacht heißt das, dass das Bundle nur Interaktives enthält. Unachtsam gemacht schickt ein einziges 'use client' den halben Baum in den Browser, und die Kosten sind unsichtbar, bis jemand misst.

Wenn Ihr Team in React erfahren ist und diese Linie halten will, gewinnt das Next.js-Modell bei dem, was Nutzer herunterladen. Wenn nicht, ergibt Remix' einfachere Trennung die bessere Anwendung - denn ein Modell, das Menschen korrekt anwenden, schlägt ein besseres, das nachlässig angewendet wird.

Mutationen, wo sich die Modelle am unterschiedlichsten anfühlen

Die Antwort von Remix ist ein Formular, das an eine Action derselben Route postet. Das ist der Mechanismus der Plattform mit einem Framework darum, was bedeutet: es funktioniert, bevor JavaScript geladen ist, und es funktioniert weiter, wenn JavaScript scheitert. Für ein Team, dem das wichtig ist, ist das kein Detail, sondern der Grund, Remix zu wählen.

Die Antwort von Next.js ist eine Server Action: eine Funktion, die als serverseitig markiert und wie jede andere Funktion aufgerufen wird. Weniger Zeremonie, weniger bewegliche Teile - und eine schwächere Geschichte ohne JavaScript: ein Formular an einer Action funktioniert unhydratisiert in einfachen Fällen und hört damit auf, sobald die Verarbeitung interessant wird.

Für die meisten Anwendungen enden beide am selben Punkt. Der Unterschied ist, was Sie geschenkt bekommen, wenn auf dem Client etwas schiefgeht - und ob Ihnen das etwas bedeutet.

Was nicht entscheiden sollte

Benchmarks. Beide sind schnell genug, dass Ihre Datenbank und Ihre Bilder dominieren.

Was beliebter ist. Next.js ist es, und Beliebtheit zählt nur insofern, als sie mehr Leute zum Einstellen und mehr Antworten zum Suchen bedeutet. Ein echtes Argument, nur kein technisches.

Wer die bessere Deployment-Story hat. Beide laufen auf Node überall. Die Plattformbindung, um die man sich sorgt, ist eine Konfigurationsentscheidung, keine Framework-Eigenschaft - Next.js selbst zu hosten funktioniert, und Bestimmtes hört auf zu funktionieren, was für die Alternative ebenso gilt.

Verschachteltes Routing. Beide haben es, beide machen es gut, und es ist das Feature, das in Vergleichen am prominentesten auftaucht, weil es sich am leichtesten in eine Tabelle schreiben lässt. Es war noch nie das, was ein Projekt schwierig gemacht hat.

Die ehrliche Zusammenfassung

Nehmen Sie Remix, wenn Sie ein einfaches Modell zur Request-Zeit wollen und lieber Geschwindigkeit hinzufügen als Veraltetes entfernen.

Nehmen Sie Next.js, wenn Ihre Inhalte cachebar sind und Sie das umsonst wollen - und wenn jemand da ist, der die Client-Grenze ehrlich hält.

Und wenn keines davon Ihr Projekt beschreibt, ist womöglich nicht das Framework die Frage.