Sie brauchen kein Next.js – warum wir von Next zu React migriert sind

 (comfydeploy.com)
23 Punkte von GN⁺ 2025-01-03 | 17 Kommentare | Auf WhatsApp teilen
  • Ergebnisse der Migration des ComfyDeploy-Dashboards von Next.js zu React:
    • Build-Zeit von 3 Minuten → 18 Sekunden verkürzt
    • Hot Reload auf unter 200 ms verbessert
    • Das Team ist deutlich zufriedener
  • Ursprünglich als Full-Stack-Anwendung mit Next.js gestartet und dank Drizzle und Server Actions mit Typsicherheit und sauberem Code gut funktionierend, traten jedoch folgende Probleme auf:
    • Hohe API-Kosten von 2.000 US-Dollar bei Vercel, verursacht durch einen bestimmten Nutzer
    • Zunehmende Komplexität beim Testen der APIs: Mischung aus Server Actions und API-Routen
    • Langsame Build-Zeiten und eine ineffiziente lokale Entwicklungsumgebung
    • Selbst kleine Änderungen führten zu einem vollständigen SSR-Reload
  • Probleme
    • Zunehmende Komplexität von Next.js: Der All-in-One-(Full-Stack-)Ansatz von Next.js verursachte mit dem Wachstum der App immer mehr Entwicklungsaufwand
    • Unser Dashboard basiert hauptsächlich auf React und benötigt die Server-Funktionen von Next.js nicht
  • Der Wechsel von Next.js zu React
    • Umstieg von Next.js auf React mit TanStack Router und Rspack
      • Start des Entwicklungsservers: unter 2 Sekunden
      • Vercel-Build-Zeit: 18 Sekunden
    • Verbesserte API-Konfiguration, Entfernen unnötiger Abhängigkeiten, Vereinfachung des Codes und höhere Produktivität
  • Leistungsvergleich
    • Next.js 15 (mit Turbo-Modus)
      • Erster Seiten-Build: 10,4 Sekunden
    • React + TanStack Router + Rspack
      • Routenberechnung: unter 200 ms
      • Initialer Bundle-Build: 1,67 Sekunden
  • Trade-offs
    • Verloren
      • Co-Location von Frontend- und Backend-Code: Durch die Trennung von Frontend und Backend wurden die Grenzen klarer
      • Caching-Funktionen von Next.js: Wegen vieler Daten mit Echtzeit-Updates durch maßgeschneidertes Caching ersetzt
      • Prerendering und initiales Laden: Statt Static Generation eine bessere UX umgesetzt – keine deaktivierten Buttons mehr
      • Server-Komponenten und Actions: Die „Magie“ der Server-Komponenten ging verloren, wurde aber durch bewusstere API-Entwürfe verbessert
    • Gewonnen
      • Stärkeres Design von API-Verträgen
      • Caching nur dort implementieren, wo es nötig ist
      • Datenfluss und State-Management sorgfältig entwerfen
  • Fazit
    • Next.js eignet sich für Landingpages und SEO-Aufgaben, verursacht aber für die meisten Produkte unnötige Komplexität
    • Für Landingpages und SEO wird weiterhin Next.js verwendet
    • Das Dashboard wurde auf Pure React + TanStack Router + Rspack umgestellt
    • Die API läuft als Python-FastAPI-Server auf Google Cloud Run und skaliert bei Bedarf automatisch
  • Die Wahl des richtigen Tools ist entscheidend, und für uns war Next.js eine überdimensionierte Lösung

Verwandte Beiträge

17 Kommentare

 
zerocyber 2025-01-04

In unserem Unternehmen sind wir gerade dabei, das Frontend mit Next.js zu vereinheitlichen bzw. die Migration vorzubereiten, und wenn man dann so einen Artikel liest, kommt man doch ziemlich ins Grübeln....
 
nemorize 2025-01-04

Wir betreiben nur Services, bei denen ein Mobile-"App"-first-Ansatz möglich ist.
Bereiche, in denen SEO nötig ist, halten wir sehr schlank, indem wir dort React (oder etwas Ähnliches) gar nicht erst einsetzen.
Das Web nutzen wir nur als SEO-Köder und leiten die Nutzer zur App ...
 
beenzinozino 2025-01-04

„Die Wahl des richtigen Werkzeugs ist wichtig, und für uns war Next.js eine überdimensionierte Lösung.“

Ich denke, genau der letzte Satz ist der Kernpunkt.

Um das passende Werkzeug auszuwählen, ist es wohl auch wichtig, viele verschiedene Fehlschläge und Erfahrungen selbst gemacht zu haben.
 
iolothebard 2025-01-03

Wenn SEO nötig ist, bedeutet das, dass Inhalte der Kern sind,
aber da UI-Komponenten(?) und State den Hauptteil einnehmen, entstehen … bizarre Kreaturen wie SSR, ISR, Hydrate …
 
schang124 2025-01-03

Dem kann ich ziemlich gut zustimmen.
Ich setze Next.js grundsätzlich nur dann ein, wenn SEO erforderlich ist.
Wie im obigen Artikel beschrieben, hat die Nutzung von reinem React viele Vorteile:

  • Die für Next.js typische unnötige Komplexität und die speziellen Muster entfallen.
    • Die Wartung wird schlanker
  • Man ist von unnötigen Ausgaben für SSR befreit
  • Bei Libraries für die FE-Infrastruktur wie Router oder Bundler hat man mehr Wahlfreiheit
 
jhj0517 2025-01-03

Ich weiß es nicht genau, aber offenbar gibt es einen großen Unterschied bei der Build-Zeit.
 
bichi 2025-01-03

Offenbar weiß man noch nicht, dass React im Vergleich zu anderen Frameworks in vielerlei Hinsicht deutlich langsamer ist.
 
slowandsnow 2025-01-03

Weil Geschwindigkeit nicht so wichtig ist. Wenn Geschwindigkeit wichtig wäre, würde expressjs heute wohl nicht mehr verwendet werden. Die Community und die Zahl der Bibliotheken sind überwältigend groß.
 
devheerim 2025-01-03

Es scheint, als liege der Fokus darauf, von Next zu React zu migrieren, haha.
 
bbulbum 2025-01-03

Die React-Community hat CRA bereits in der Anfangsphase hinter sich gelassen und ist zu Frameworks übergegangen, daher bin ich mir nicht sicher, ob es eine einfache Entscheidung ist, sich dem zu widersetzen.
 
sacru2red 2025-01-03

Wir sind größtenteils auf vite umgestiegen, und Frameworks setzen wir auch jetzt noch je nach Bedarf ein.
 
bbulbum 2025-01-06

Wenn Sie eine neue Anwendung oder eine komplette Website mit React erstellen, empfehlen wir die Verwendung eines Frameworks.

So steht es auf react.dev~
 
kandk 2025-01-03

Interessant. Ist Next im Vergleich zu React schwergewichtiger?
Ich habe mit Next bisher nur einmal ein Projekt aufgesetzt, aber der Projektaufbau war extrem einfach und die Entwicklung konnte sofort beginnen.
 
cichol 2025-01-03

„Einfach“ <= dahinter verbirgt sich Magie (?), die, um genau das zu erreichen, viele Trade-offs mit sich bringt.
 
beenzinozino 2025-01-04

Dem kann ich zustimmen. Unter der Haube von Next.js verstecken sich enorm viele Abhängigkeiten ...
 
GN⁺ 2025-01-03
Hacker-News-Kommentare

  • Viele Leute konzentrieren sich zu sehr darauf, ob sich eine Idee auf Milliarden von Nutzern skalieren lässt. Deshalb wird manchmal Kubernetes für eine Website eingesetzt, die nur 5 Besucher hat. Ich habe auch Studenten gesehen, die mit Next.js Websites bauen, die man einfach mit HTML + CSS schreiben könnte

  • Ich habe ein Projekt mit Next.js gebaut, fand es aber kompliziert in der Nutzung. Die APIs für den Zugriff auf Cookies sind auf Client und Server unterschiedlich, und auf Umgebungsvariablen muss man mit process.env.NEXT_PUBLIC_* zugreifen, was verwirrend ist. Ich wollte Code schreiben, der mit minimalen Änderungen sowohl auf Client als auch auf Server läuft, aber das war nicht der Fall. Der Lernaufwand und Overhead erschienen mir im Vergleich zu dem, was Next.js bietet, nicht lohnend

  • Die Codebasis wurde einfacher und das Rendering der Seiten schneller. Es ist schade, dass die Community unnötig in solche Frameworks gedrängt wird. Die meisten Leute brauchen nur npx rsbuild init. Mit rspack und rsbuild habe ich einen einfachen Router und eine schöne Einfachheit bekommen

  • Ich nutze es seit der Veröffentlichung von Next.js v14 und bin sehr zufrieden. Mit RSCs funktionieren viele Teile der App auch dann gut, wenn clientseitiges JS deaktiviert ist. Es hat die schlichte Stärke einer PHP-App und erlaubt es zugleich, Typsysteme und interaktive zustandsbasierte Client-Komponenten nahtlos auf der „Leaf-Ebene“ des View-Trees einzubinden

  • Dank Rails und Hotwire konnte ich dem Chaos des React-Ökosystems entkommen. Es gibt zu viele Optionen: State-Management-Bibliotheken, Meta-Frameworks, Data-Fetching-Bibliotheken und mehr. Eine einfache Aufgabe wie das Anzeigen von Daten vom Server auf einer Seite muss nicht unnötig kompliziert gemacht werden

  • Ich arbeite an einem CMS (PayloadCMS), das NextJS verwendet, und NextJS ist die schlimmste Technologie, mit der ich je gearbeitet habe

  • Bei fast jedem Projekt, das schwere Frontend-Frameworks/-Bibliotheken wie Next.js, React oder Vue verwendet, wäre es besser, eine Bibliothek zu nutzen, die Templates im Backend verarbeitet. Manchmal ist clientseitiges Rendering mit EJS sinnvoll. Ich frage mich, warum man überhaupt ein Framework verwendet

  • Ich nutze Next.js für SEO und die Optimierung fürs Crawling. Wenn Seiten nicht gecrawlt werden müssen, etwa ein Dashboard hinter einem Login, braucht man Next.js nicht, und pures React wäre einfacher

  • Ich bin überrascht, dass sich Next.js als Standard-Startoption etabliert hat. Im Vergleich zu vor 2–3 Jahren fühlt sich das wie eine große Veränderung an

  • Ich versuche, eine NextJS-App mit Vike zu ersetzen, und bin zufrieden. Man kann ohne Störungen so bauen, wie man es möchte
 
aer0700 2025-01-03

Kubernetes für eine App mit fünf Nutzern ... beeindruckend.