Next.js vs. Remix: Die Entscheidung ist eine über Caching
Beide rendern serverseitig, beide können verschachteltes Routing, beide sind gut. Der Unterschied, der sich in einer Codebasis zeigt, ist der Umgang mit zwischengespeicherten Daten.
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:
| Remix | Next.js | |
|---|---|---|
| Standard | Frisch, zur Request-Zeit | Zwischengespeichert, zur Build-Zeit |
| Typischer Fehler | Langsam, weil ein Loader zu viel tut | Veraltet, weil eine Cache-Schicht vergessen wurde |
| Was Sie justieren | Caching hinzufügen | Unbeabsichtigte Dynamik entfernen |
| Debugging | Den Loader lesen | Herausfinden, welcher der vier Caches geantwortet hat |
Keines ist besser. Sie scheitern in unterschiedliche Richtungen, und Sie sollten die Richtung wählen, die Ihr Team bemerkt.
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.
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.
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.