Was ist das beste React Framework?

Die Entscheidung ist gefallen, du hast dich in die moderne Frontend-Welt eingelesen und raus kam dabei React. Der Arbeitsmarkt ist weitaus besser^[1], das Ökosystem ist groß genug, dass man Lösungen zu fast jedem Problem findet und es hat den Test der Zeit schon bestanden.

Um neue Entwickler zu finden willst du ein Job Posting vorbereiten und schaust dir an, was andere Firmen in ihren Ausschreibungen erwähnen. Remix, Vite, Next.js, Gatsby. Ah, Gatsby, den kennst du von dem Film. Aber ich dachte es geht hier um React?

Du bist nicht der einzige der bei dieser Vielzahl an verschiedenen React Frameworks verwirrt ist, aber was genau sind Remix, Vite, Next.js und Gatsby?
In diesem Blogpost geben wir dir einen groben Überblick über React Frameworks und zeigen dir, worauf du achten solltest (inklusive Empfehlung)

React ist nicht gleich React

Wie du bereits gemerkt hast, ist React nicht gleich React. Das liegt daran, dass React weniger ein Framework als eine Library ist. Es ist mehr ein einzelner Teil als eine All-In-One Lösung wie man es von z.B. Angular kennt.

Das ist natürlich für die Flexibilität super, man kann React auf viele verschiedene Arten und Weisen benutzen, aber immer wieder das Rad neu zu erfinden ist nicht nur zeitaufwändig, sondern auch fehleranfällig. Demnach haben sich inmitten des React Ökosystems Entwickler zusammengetan um gängige Probleme generell zu lösen.

Eines der ersten Frameworks war CRA. Nicht lange danach folgten Gatsby und Next.js mit mehr Features und in den letzten Jahren kam es erneut zu einer Welle von Next-Gen Tools wie Vite und Remix. Aber um zu verstehen, was genau die Frameworks tun, hilft es erstmal zu wissen, was genau die Probleme waren

Warum überhaupt ein Framework?

Als sich React rauskristallisiert hat als die neue innovative Art und Weise Frontends zu entwickeln, kamen immer öfter dieselben technische Probleme auf. Die User wollten nicht immer 10MB JavaScript downloaden und währenddessen auf einen weißen Bildschirm starren. Zusätzlich ist es für die SEO Performance kontraproduktiv, dass Google die Seiten nicht gut indexieren kann.

Diese Probleme haben die Frameworks versucht mit Konzepten wie Code-Splitting und SSG/SSR zu lösen. Und das ist denen auch gelungen, mal mehr oder mal weniger. Heutzutage bietet fast jedes Framework diese Features an.

Und welches ist nun das Beste?

Ohne tief in die technischen Details zu gehen^[2], ist es schwierig dieser Frage gerecht zu werden. Überhaupt ist es gar nicht möglich eines als "bestes" Framework zu krönen, da es zu viele subjektive Faktoren gibt, die nur für einen Entwickler relevant sind. Der eine mag Next.js mehr, der andere Remix. Manch einer mag auch ganz Low-Level mit Vite sein eigenes Framework zu bauen.

Für uns persönlich spielen da externe Faktoren eher eine Rolle. Wie schaut der Arbeitsmarkt jeweils aus? Springen mir meine Entwickler ab weil sie "keinen Spaß haben"? Gibt es ein besonderes Feature was ich brauche? Das sind aus unserer Erfahrung wichtigerere Faktoren die weitgehende Konsequenzen mit sich ziehen. Wenn du noch kein Team hast, kannst du die nächste Section überspringen, für alle anderen ist das Must-Read

Do you have fun?

Entwickler wählen sich ihre Jobs je nachdem aus, ob sie Spaß haben können. Das mag wie ein Klischee klingen, und Ausnahmen gibt es immer, aber wir haben das öfter miterlebt, dass ein Unternehmen immer mehr in eine Position gerutscht ist, wo die Entwicklung keinen Spaß mehr gemacht hat.

Bugs die schwer zu finden sind, Features die Monate dauern oder instabile Workarounds. Das tötet die Stimmung und führt zu einer Kettenreaktion der Unzufriedenheit. Sobald dann der Erste das Schiff verlässt, zieht der Zweite nach und irgendwann hat niemand mehr Lust dem Projekt beizutreten.

Bislang haben wir diese Situation nur in Projekten mit Gatsby gesehen. Dort hat der Schuh so sehr gedrückt, dass ein Code Freeze oder sogar ein kompletter Rewrite nötig war.

Persönlich würde ich kein neues Projekt mit Gatsby anfangen, da Next.js alle Features in besser anbietet und die Gatsby-spezifischen Features nicht ausschlaggebend sind.

Alle anderen Frameworks kriegen hier einen Daumen hoch 👍

Ich brauch React Entwickler, aber ganz schnell

Eines der größten Herausforderungen ist es Entwickler zu finden und vorallem gute Entwickler. Wie genau man "gute Entwickler" identifiziert, erläutern wir hier. Doch nur "gute Entwickler" zu identifizieren bringt nichts, wenn man keine Kandidaten findet.

Der einfache Weg wäre es, schlichtweg jeden Entwickler der React kann zu interviewen. Aus den Interviews die wir jedoch geführt haben stellt sich aber heraus, dass es einen großen Unterschied macht ob man einen "React Entwickler" oder einen "React Entwickler der Next.js kennt" hat.

Die Frameworks nehmen einem viel Arbeit ab, sind aber dennoch sehr eigen. Nicht jeder im Team muss die Framework-spezifische Knowledge haben, aber es macht Sinn, dass es mindestens einen mit viel Erfahrung darin gibt. Dieser Ansprechpartner sollte dann auch den groben Überblick über das Projekt haben, um gegebenenfalls Kernentscheidungen und Abstraktionen zu treffen.

Da Next.js schon länger existiert als Remix, gibt es deshalb einen deutlich größeren Pool an Kandidaten, die das Kriterium erfüllen. Das sehen wir auch an den Anfragen die wir bekommen. Remix ist in Deutschland weitaus weniger verbreitet.

Zu Vite: Vite ist einfach React, da ist jeder "React Entwickler" ein potentieller Kandidat. Jedoch sollte man dort auch eine Person als "Lead" designieren

Remix bekommt also leider einen 😕, Next.js und Vite sind noch im Rennen 🚀

Next.js vs. Vite - Die Features entscheiden

Jetzt liegt die Wahl nur noch zwischen Next.js und Vite. Ab hier kann man nicht mehr wirklich etwas falsch machen, da jeweils das ein oder andere eine gute Entscheidung ist. Hier geht es nur noch um die genauen Anforderungen.

Falls man einzelne Widgets in eine bestehende App in einer anderen Sprache (Java, Ruby, Python) integrieren muss, ist Vite die beste Wahl, da es mit Next.js nur mit Workarounds möglich ist.

Falls SSR und SEO wichtig sind, ist Next.js die bessere Wahl, da hier die Kernstärken liegen und es out of the box eine Komplettlösung bietet.

Alles andere ist mit beiden Tools abdeckbar, wir würden aber zu Next.js raten, da es durch die Konventionen schneller in der Entwicklung ist und man sich für die Zukunft nichts verbaut.

Vite wäre optional für interne Tools eine simplere Option, jedoch sehen wir einen Vorteil darin, die gleiche Lösung für alle Projekte zu benutzen, da die Unterschiede hier weniger wichtig sind als es ist, ein zweites Tool einzuführen.