Der aktuelle Stand von React und der Community im Jahr 2025

• React ist weiterhin das am weitesten verbreitete UI-Framework, doch in den vergangenen Jahren haben Verwirrung, Kontroversen und Misstrauen in der Community zugenommen. Fehlende Kommunikation zwischen dem offiziellen Team und externen Entwicklern sowie missglücktes Marketing haben die Sorgen zusätzlich verstärkt
• React 19 ist offiziell veröffentlicht worden und bringt große Funktionen wie Server Components, den neuen use-Hook und Formular-Integration mit. Die Politik „nur Frameworks empfohlen“ und die Next.js-zentrierte Ausrichtung haben jedoch bei vielen Nutzern Unmut ausgelöst
• Missverständnisse und FUD wie „React kann man jetzt nur noch richtig mit Next.js nutzen“ oder „die Unterstützung für reine Client-Apps wird bald eingestellt“ haben sich verbreitet. Tatsächlich aber wird die Client-Rendering-Funktionalität keinesfalls verschwinden, und auch RSC sowie Server-Features sind ausdrücklich optional
• Die Framework-zentrierte Politik des React-Teams soll Performance und Struktur standardisieren und die User Experience verbessern, doch mangelnder Respekt für SPAs und verschiedene Architekturen sowie inoffizielle bzw. wenig hilfreiche Dokumentation haben die Verwirrung in der Community verstärkt
• Erst seit Kurzem sind verschiedene Wege wie Vite- oder Parcel-basierte SPAs in der offiziellen Dokumentation enthalten, doch es fehlt weiterhin an offizieller Erklärung zu Server Components (RSC) und an ausreichender Kommunikation

---

Einleitung und Ziel

• Stand 2025 befindet sich die React-Community in einer komplexen Lage aus Erfolg, Misstrauen und Kontroversen
• Das Ziel dieses Artikels ist es, die Entwicklung von React, die Entwicklungsrichtung und die Hintergründe wichtiger Entscheidungen einzuordnen und FUD sowie Verwirrung aufzulösen

Hintergrund des Autors und Beteiligung an der Community

• Kein Mitglied des React-Teams, aber seit 2015 tief im React-Ökosystem engagiert
• Maintainer von Bibliotheken der Redux-Familie, insbesondere Redux Toolkit, sowie wichtiger Community-Akteur
• Beteiligung an zahlreichen React-/Redux-Tutorials, Blogposts, Vorträgen und Podcasts
• Administrator und Moderator in wichtigen Communitys wie Reactiflux Discord und dem Subreddit /r/reactjs
• Erfahrung in der Zusammenarbeit mit dem React-Team, etwa als Alpha-Tester für den Hook useSyncExternalStore, sowie Teilnahme an verschiedenen internen Feedback-Gruppen
• Verschiedene technische Beiträge zu React DevTools, Sourcemaps, Replay DevTools usw.

• Hinweis zu Bias und Grenzen

  • Ich kann nicht immer richtig liegen und erkenne an, dass es wegen begrenzter Informationen, Missverständnissen oder Verdichtung im Einzelfall zu ungenauen Darstellungen kommen kann
  • Ich pflege Redux, und meine React-Erfahrung ist ebenfalls vor allem auf interne Tools und SPA-Formen ausgerichtet
  • Praktische Erfahrung mit SSR, RSC, sehr hohem Traffic, i18n usw. ist begrenzt
  • Mit Themen, die tief in der Community diskutiert werden, bin ich vertraut, aber das kann teilweise von der Alltagsrealität gewöhnlicher App-Entwickler abweichen
  • Sowohl positive als auch negative persönliche Erfahrungen mit dem React-Team beeinflussen meine Perspektive
  • Ich bemühe mich, bei historischen und strukturellen Hintergründen die Fakten so gewissenhaft wie möglich wiederzugeben

Eine kurze Geschichte von React

• 2011–2012 intern bei Facebook (heute Meta) entwickelt, 2013 als Open Source veröffentlicht
• Bis vor Kurzem wurde die gesamte Kernentwicklung vom React-Team bei Facebook/Meta geführt
• Die Kernkonzepte (Komponenten, Props, State, Data Flow) blieben erhalten, während Implementierung, APIs und Einsatzbereich kontinuierlich erweitert und verändert wurden
  • createClass → ES6-Klassen → funktionale Komponenten (mit Hooks)
  • Mit React Native auf Mobile sowie mit react-reconciler auf weitere Plattformen wie WebGL (react-three-fiber), CLI (ink) usw. ausgeweitet
  • Intern vollständiges Refactoring zur „Fiber“-Architektur (Innovationen bei Performance und Struktur)
  • 2018 Einführung von Hooks, um funktionalen Komponenten State und Effekte zu geben
• Mit der Strategie einer „minimalen UI-Bibliothek (das V in MVC)“ wurden Architektur, übergeordnete Frameworks, Build-Tools und State-Management der Community überlassen
  • Dadurch entstanden zahlreiche Third-Party-Bibliotheken und Build-Tools wie Redux/Mobx/Zustand (State), Styled-Components/Emotion/CSS Modules (Styling), React Query/Apollo/SWR(RTK Query) (Daten), Webpack/Vite/Parcel usw.
• Die Flexibilität ist ein Vorteil, aber die Auswahl der benötigten Bibliotheken war für jedes Projekt Pflicht → verbunden mit vielfältigen Codebasen, Ermüdung und fehlenden Standards

• Build-Tools und CRA

  • Anfangs waren komplexe Konfigurationen mit Webpack/Babel usw. zwingend nötig
  • Create React App (CRA): ein auf Webpack+Babel basierendes CLI, das Komplexität verbarg und die Projekterstellung mit einem einzigen Befehl ermöglichte (Blackbox-Ansatz)
  • Für Data Fetching und State-Management war man weiterhin auf separate Third-Party-Tools angewiesen
  • SSR (Server-Side Rendering) war von Anfang an möglich, musste aber manuell implementiert werden
  • Später kamen Frameworks wie Next.js (SSR/dateisystembasiertes Routing, Data Fetching), Gatsby (statische Sites, GraphQL) und Remix (serverseitige Data Loader) hinzu

• React Server Components (RSC) und die Verlagerung zu Frameworks

  • Ende 2020 wurde ein Prototyp von React Server Components (RSC) vorgestellt, eine architektonische Veränderung, um asynchrone Komponenten und serverseitiges Data Fetching in React zu standardisieren
  • Während der Entwicklung wechselten einige Mitglieder des React-Teams zu Vercel und arbeiteten mit Next.js an der ersten Implementierung von App Router und RSC
  • 2020–2023 wurden die offiziellen React-Dokumente (react.dev) grundlegend überarbeitet, mit stärkeren interaktiven Tutorials und API-Referenzen

• Wandel der offiziell empfohlenen Nutzung

  • In der früheren offiziellen Dokumentation wurde der Einstieg mit CRA-basierten SPAs empfohlen, mit Hinweisen auf Alternativen wie Next oder Gatsby bei Bedarf für SSR oder statische Sites
  • In der neuen Dokumentation (react.dev) wird die Nutzung von Frameworks stark empfohlen (Routing, Data Fetching, Build-Integration), und als RSC-Implementierung wird nur Next.js genannt
  • CRA wurde ab etwa 2022 faktisch nicht mehr weiter gepflegt (offiziell nicht deprecated, in der Community aber schrittweise ersetzt)
  • Sowohl in den offiziellen Dokumenten als auch in der Community wurde die starke Verknüpfung mit Next.js betont, etwa in Aussagen wie „Next.js ist das eigentliche React 18“

React und das Eigentümerunternehmen (Sponsor)

• Meta (Facebook)

  • React war von Anfang an ein Projekt, das Facebook/Meta gehörte und von dort geführt wurde
  • Obwohl Open Source, lag die tatsächliche Entwicklung beim React-Team von Meta; zentrale Meetings und die Roadmap waren vollständig intern geprägt
  • Neue Funktionen wurden vor der externen Veröffentlichung in verschiedenen internen App-Teams bei Meta real validiert und getestet
  • Das React-Team hatte einen hohen Freiheitsgrad in der Entwicklung und prägte Roadmap und Vision weitgehend selbstständig
  • Intern musste nachvollziehbar sein, wie Ergebnisse und Projekte zum Geschäft von Meta beitragen
  • Meta nutzt aktiv die eigene Server-Infrastruktur sowie eigene Technologien wie GraphQL und Relay und verwendet React bei Routing und State-Management daher anders als große Teile der Community
  • Entsprechend werden intern seltener externe Third-Party-Bibliotheken eingesetzt

• Vercel, Next.js und React

  • Vercel ist eine Hosting-Plattform für Web-Apps und das Unternehmen hinter dem Framework Next.js
  • Das Geschäftsmodell lautet im Kern: Verbreitung von Frameworks wie Next → Hosting auf der Vercel-Plattform fördern
  • CEO Guillermo Rauch hatte von Anfang an großes Vertrauen in die React-Rendering-Philosophie und investierte früh darin
  • 2021 wechselte der React-Teamleiter Sebastian Markbage von Meta zu Vercel, später kamen wichtige Personen wie Andrew Clark und Tom Occhino hinzu
  • Die zu Vercel gewechselten Mitglieder implementierten Kernfunktionen wie React Server Components (RSC) und den Next.js App Router sowohl in React als auch in Next.js
  • Auch Ingenieure bei Vercel leisteten substanzielle Beiträge zum React-Kern und zu Server-Rendering-Funktionen
  • Stand 2025 arbeitet das React-Team verteilt zwischen Meta und Vercel (der Schwerpunkt liegt bei Meta, wesentliche Core-Implementierungen kommen aber auch von Vercel), ergänzt durch einige externe Mitwirkende

Nutzungsmuster von React

• Standardarchitekturen

  • React selbst unterstützt verschiedene Ansätze wie SPA, SSR, SSG und Hybridmodelle
    • SPA: Der gesamte React-Baum wird im Client in ein leeres HTML gerendert
    • SSR: Der Server erzeugt für jede Anfrage dynamisches HTML
    • SSG: Statisches HTML wird bereits zur Build-Zeit erzeugt
    • Kombinierbar mit verschiedenen Sprachen oder Frameworks wie Python/Django, Ruby/Rails, PHP/WordPress usw.
  • Seit etwa 2015 galt SPA (Client-Rendering) als Standard, hatte aber Trade-offs wie anfängliche Ladezeit, Größe des JS-Bundles und Unterschiede zum nativen Browser-Verhalten
  • Data Fetching wurde ursprünglich direkt in Redux usw. umgesetzt, später aber durch spezialisierte Hooks/Bibliotheken wie React Query, Apollo, SWR oder RTK Query vereinfacht
  • Frameworks wie Next.js und Remix haben den Einsatzbereich von React verbreitert, indem sie SSR, SSG und dateisystembasiertes Routing standardisierten und das Data Fetching strukturierten
  • Es gibt einen Trend hin zu SSR-basierten Architekturen (Server-Rendering, Prefetching, Code-Splitting usw.)
  • Das React-Team möchte „Data-Fetching-Waterfalls“ vermeiden und empfiehlt Performance-Muster wie routebasiertes Prefetching

• Aktueller Einsatz von Build-Tools und Frameworks

  • Wichtige Tools/Frameworks:
    • Next.js (SSR/SSG/RSC/SPA)
    • Remix / React-Router v7 (SSR/SSG/SPA)
    • Vite (SPA, Build-Tool, unterstützt Plugins für verschiedene Frameworks)
    • Create React App (SPA)
  • Vite stammt aus dem Vue-Ökosystem, unterstützt heute aber viele Systeme wie React und Svelte → offizielles React-Plugin, Standard-Build-Tool für Frameworks
  • Auch Remix/React-Router wechseln zuletzt zu einer Vite-basierten Struktur mit SSR-/SSG-Unterstützung
  • Zusammenfassung der Download-Statistiken:
    • Next.js ist bei der Nutzung mit großem Abstand auf Platz 1
    • Das React-Plugin von Vite wächst rasant und ist die zweithäufigste Wahl
    • CRA (react-scripts) ist seit 2023 rückläufig, hat aber weiterhin beträchtliche Nutzung
    • Remix hat starkes Word-of-Mouth, bleibt insgesamt aber begrenzt; React Router vollzieht den Wechsel in den Framework Mode nur langsam
    • Gatsby liegt deutlich hinter Next/Vite/CRA zurück und wurde zuletzt sogar von Astro (statische Sites für mehrere Frameworks) überholt
    • Astro ist nicht auf React spezialisiert, hat aber eine ähnliche Größenordnung wie Remix
    • Addiert man die Nutzung von Vite und CRA, liegt sie auf Augenhöhe mit Next → die Nachfrage nach dem SPA-Ansatz ist weiterhin hoch

React Server Components (RSC) intern und ihre Beziehung zu Frameworks

• Hintergrund der RSC-Entwicklung und Zusammenarbeit mit Vercel

  • Die interne Infrastruktur bei Meta war bereits stark auf eigene Serverstrukturen zugeschnitten, wodurch es Grenzen bei Entwicklung und Test von RSC (React Server Components) gab
  • RSC ist ein vom React-Team selbst vorangetriebenes, zukunftsorientiertes Design, nicht das Ergebnis von Anweisungen oder Anforderungen seitens Meta oder Vercel, sondern aus der eigenständigen Vision des React-Teams entstanden
  • Das React-Team stellte Vercel seine RSC-Vision vor, woraufhin Vercel als Experimentierfeld und Unterstützer einstieg
  • React-Core-Mitglieder wie Sebastian Markbage und Andrew Clark wechselten von Meta zu Vercel, und das Next.js-Team baute mit dem App Router den ersten realen Anwendungsfall für RSC
  • In diesem Prozess wurde Next.js nahezu von Grund auf neu entworfen und implementiert
  • Andere Frameworks wie Shopify (Hydrogen) oder Remix führten zwar frühe Tests und Kooperationsversuche durch, beteiligten sich aber nicht umfassend
  • In der Folge etablierte sich nur der Next.js App Router als tatsächliche „Production-grade“-Implementierung von RSC; andere Frameworks (React Router, Parcel, Waku usw.) arbeiten aktuell an der Integration, doch in der breiten Nutzung dominiert Next

• Integrationsstruktur von RSC mit Frameworks/Bundlern

  • Die Frage „Warum braucht RSC unbedingt ein Framework oder einen Bundler?“ wird oft gestellt
  • Klassisches SSR (renderToString, renderToPipeableStream) konnte überall ausgeführt werden, doch RSC ist strukturell deutlich komplexer
    • Interpretation der Direktiven 'use client' und 'use server' im Code
    • Automatisierte Trennung und Registrierung von Client- und Server-Komponenten erforderlich
    • Enge Integration mit einem Bundler, der den gesamten Modulgraphen analysiert und kompiliert (z. B. Webpack, Vite usw.), ist zwingend nötig
  • React Core liefert nur die Kernlogik von RSC und die APIs zur Datenserialisierung; das tatsächliche Verhalten, Routing und Endpoint-Aufrufe liegen in der Verantwortung des Frameworks
  • Jedes Framework nutzt, strukturiert und implementiert RSC anders
    • Der Next.js App Router wendet eigene Regeln für Layouts, Routing usw. an
    • Parcel, Waku, React Router usw. führen jeweils andere Konzepte ein
  • Zusammengefasst:
    • RSC ist eine im React-Kern eingebaute Hybrid-Funktion, die in der Praxis jedoch zwingend die Integration durch Bundler/Framework erfordert
    • Die Vorteile von RSC lassen sich nur dann real nutzen, wenn das Framework sie unterstützt

Sorgen und Verwirrung in der Community

• 1. Die Sorge: „Vercel hat React übernommen“

  • Weil Vercel wichtige React-Teammitglieder beschäftigt und Next.js in Dokus und Beispielen hervorgehoben wird, verbreitete sich der Verdacht, Vercel steuere die React-Entwicklung
  • Tatsächlich hat das React-Team die RSC-Vision und die Struktur des Next App Router vorangetrieben, während Vercel eher als Unterstützer und Experimentierfeld fungierte
  • Eher als dass Vercel React „übernommen“ hätte, wechselte ein Teil des React-Core-Teams zu Vercel, um die eigene Vision umzusetzen

• 2. Das Missverständnis: „React läuft jetzt nur noch mit Next“

  • Weil nur Next.js als produktionsreife RSC-Implementierung stark herausgestellt wurde, entstand dieser Eindruck
  • Die offizielle React-Dokumentation erwähnt neben Next auch verschiedene andere Frameworks sowie die Nutzung ohne Framework
  • Next ist nur ein auf React basierendes Framework; React kann weiterhin allein oder mit anderen Tools verwendet werden

• 3. Die Angst: „React könnte aus Client-Apps verschwinden“

  • Durch die starke Betonung von Server-Features (RSC, SSR usw.) gab es Sorgen, dass die Unterstützung für clientseitige SPAs eingestellt werden könnte
  • Die Client-Rendering-Funktionalität von React wird niemals verschwinden
    • Auch große Codebasen wie bei Meta setzen in großem Umfang auf Client-Ansätze
    • Das React-Team achtet sehr auf Kompatibilität und Migrationsunterstützung

• 4. „Warum zwingt React zur Nutzung von Frameworks?“

  • Das React-Team empfiehlt Frameworks standardmäßig wegen der Produktivitäts- und Performance-Vorteile, etwa durch integriertes Data Fetching, Routing und SSR
  • Der Standpunkt lautet: eigene Konfigurationen (maßgeschneiderte SPAs) sind langfristig ineffizient, Frameworks sind der Industriestandard
  • In der Praxis gibt es jedoch viele unterschiedliche Nutzungsmuster, die Empfehlung wirkte daher zu pauschal
    • SPAs bleiben aus realen Gründen weiterhin relevant: Einstiegshürden für Anfänger, Unternehmen mit Einschränkungen beim Server-Hosting, einfache Bereitstellung von SPAs usw.
  • Dass die offizielle Dokumentation den „nicht-Framework“-Ansatz nur nachrangig behandelte, erzeugte in der Community ein Gefühl des Ausgeschlossenseins

• 5. Grenzen der offiziellen Dokumentation und Debatten um Verbesserungen

  • CRA (react-scripts) wurde offiziell deprecated, und die späte Erwähnung von Alternativen wie Vite verschärfte die Verwirrung
  • Auch „nicht-Framework“-Ansätze wie SPAs werden inzwischen offiziell anerkannt und mit Guides versehen (aktuelle Dokumentation 2025)
  • Dass wichtige Build-Tools wie Vite so spät offiziell erwähnt wurden, wurde sowohl von der Community als auch von Persönlichkeiten des Ökosystems (z. B. Evan You) kritisiert
  • In der verbesserten aktuellen Dokumentation werden inzwischen auch SPA, Vite/Parcel/RSPack usw. empfohlen und Auswahlhilfen für Router und Data Fetching gegeben

• 6. Fehlende offizielle Dokumentation und Erklärung zu RSC

  • Im Vergleich zu externen Materialien von Next.js, Vercel usw. fehlt in der offiziellen React-Dokumentation eine ausreichende Erklärung und Einführung zu RSC
  • In der API-Referenz finden sich nur fragmentarische Informationen; eine umfassende konzeptionelle und praktische Anleitung fehlt
  • Zwar liefern die Community und wichtige Personen (wie Dan Abramov) aktiv ergänzende Erklärungen, doch das Fehlen offizieller Aufbereitung sorgt weiterhin für Verwirrung
  • Es wird gefordert, Dokumentationsabschnitte zu Konzept, Architektur, Einsatzbeispielen und FAQ zu RSC hinzuzufügen

Einordnung der wichtigsten Punkte

• Das Missverständnis, die Betonung von Frameworks und Server-Features geschehe „im Interesse von Vercel“, hat sich in Teilen der Community festgesetzt, entspricht aber nicht den Tatsachen
  • Allerdings haben Kommunikation und Formulierungen in der offiziellen Dokumentation seitens des React-Teams zu diesem Missverständnis beigetragen
• Die Client-Rendering-Funktionalität von React bleibt auch künftig erhalten; Server-Funktionen (RSC/SSR usw.) sind lediglich Optionen, und etablierte Ansätze wie SPAs können weiter genutzt werden
• Die Sorgen und Verwirrung in der Community haben auch mit mangelnder Kommunikation des React-Teams und unzureichender DevRel-Arbeit zu tun
  • Nötig sind klarere offizielle Stellungnahmen, die Auflösung von Missverständnissen sowie Anerkennung und Orientierung für verschiedene Muster
• Die Empfehlung zur „Nutzung von Frameworks“ war gut gemeint, wirkte in der Praxis aber zu einheitlich und hat Kritik ausgelöst, weil verschiedene reale Nutzungsmuster an den Rand gedrängt wurden
• Zwar wurde die offizielle Dokumentation ab 2025 verbessert und erkennt nun auch SPA-/Custom-Build-Ansätze an, doch die Berücksichtigung des Community-Feedbacks dauerte sehr lange
• Die offizielle Dokumentation sollte um zentrale Inhalte zu RSC (React Server Components), ihren Konzepten und Trade-offs ergänzt werden
  • Das würde zum richtigen Verständnis in der Community beitragen und unnötige Kontroversen vermeiden

Schlusswort

• Der Text beantwortet verschiedene Fragen dazu, wie sich React entwickelt hat, unter welchen Einflüssen und Zielen es weiterentwickelt wird und wie sich aktuelle Nutzungsmuster im Ökosystem etabliert haben
• Ziel war es, die Verwirrung und das FUD (Fear, Uncertainty and Doubt) rund um die Ausrichtung und die Veränderungen im React-Team aufzulösen
  • Auch wenn man die technische Richtung nicht teilt oder keinen Bedarf für RSC bzw. große Frameworks sieht, sind die Absichten und die Richtung des React-Teams grundsätzlich nachvollziehbar
• Die Politik des React-Teams entspringt guten Absichten wie der Standardisierung von Performance und der Verbesserung der UX in der Community, hat aber durch wenig hilfreiche Kommunikation und Dokumentation unnötige Verwirrung verstärkt
• Mehr Respekt für die Vielfalt realer Nutzungsmuster – SPAs, Frameworks und unterschiedliche Build-Tools – sowie Verbesserungen an der offiziellen Dokumentation werden immer wichtiger
• Für die gesunde Weiterentwicklung von React werden künftig eine offenere Kommunikation, eine stärkere Berücksichtigung von Community-Feedback und Dokumentation, die verschiedene Architekturen einschließt, entscheidend sein

[ahwjdekf]

React wirkt irgendwie wie eine unfertige Library, bei der ein paar Schrauben fehlen ... Wenn man sich zum Beispiel ansieht, was alles in der offiziellen useEffect-Dokumentation steht, kann man nur den Kopf schütteln ... Erst werden überall solche Rabbit Holes geschaffen, und dann ist die Haltung: Nutzt es halt richtig ... Ich habe oft den Eindruck, dass vieles ohne großes Nachdenken eher als Flickwerk gelöst wird.

[ahwjdekf]

Wenn man zusieht, wie es bei AWS kracht, denkt man sich wieder mal: natürlich ...

[geek12356]

Wenn du keine Verbesserungsvorschläge machen kannst, bist du ein Junior.

[woonki]

Bei React Native herrscht eine ähnliche Stimmung. Wenn React gleich Next.js ist, dann ist React Native gleich Expo. Auch die offizielle Dokumentation empfiehlt die Nutzung des Expo-Frameworks, und die bisherige CLI-Methode ist inzwischen nur noch schwer zu finden.

[preserde]

Eigentlich werden hier ziemlich wenige Themen zur Web-Frontend-Entwicklung gepostet ... Trotzdem wirkt es nicht gerade unbedeutend, dass Next.js in letzter Zeit so oft erwähnt wird.
Es fühlt sich ein bisschen so an wie: Nur Server Components sind das Problem, der Rest ist schon okay~

[ahwjdekf]

In dem JS-/Frontend-Bereich sollte das gesamte Ökosystem bitte einmal komplett untergehen und zurückgesetzt werden. Und bitte baut gleich ein Framework, das Dinge wie State-Management von Grund auf mit abdeckt. Übermäßig viele Optionen? Das ist keine Freiheit, sondern einfach nur Verantwortungslosigkeit.

[passerby]

Dass Frameworks praktisch sind und dass React selbst CRA aufgibt, sind meiner Meinung nach zwei völlig unterschiedliche Ebenen. Als in der neuen React-Dokumentation plötzlich einfach dazu geraten wurde, Next zu installieren, hat sich das für mich etwas befremdlich angefühlt – offenbar war ich mit diesem Eindruck nicht allein.

[dohyun682]

Ich dachte, Vercel und das React-Entwicklungsteam seien getrennt, aber tatsächlich sind sie wohl enger miteinander verbunden.

[quilt8703]

Ich prototypisiere gerade ein Spiel mit React, bei dem nur UI-Interaktionen, interne Zustandsberechnungen und die Darstellung des Status nötig sind. Im Vergleich zu der Zeit vor ein paar Jahren, als create-react-app gerade dabei war, aus der offiziellen Dokumentation zu verschwinden, hatte ich zuletzt den Eindruck, dass das Setup anhand der offiziellen Doku etwas schwieriger geworden ist. Der Artikel, den ich damals geschrieben habe, dürfte ein wenig dazu passen.

• https://guji.jjme.me/wiki/prototyping-game-with-react/

[click]

Die Tatsache an sich, dass RSC von Anfang an auf Basis von Next.js entwickelt wurde, scheint wohl unverändert zu sein.
Wenn man dazu noch berücksichtigt, dass Next.js außerhalb von Vercel-Umgebungen zunehmend ins Stocken gerät,
weiß ich zwar nicht, wie das React-Team intern darüber denkt, aber am Ende läuft es auf die Logik hinaus: RSC ist die Zukunft! Aber um RSC zu betreiben, wird Next.js empfohlen, und Next.js soll man auf Vercel nutzen. Wenn man dann fragt, ob das nichts mit den Interessen von Vercel zu tun hat, dann hm ...
Egal wie sehr man behauptet, es sei ein Missverständnis, am Ende können die Leute nur das Gefühl bekommen, dass Vercel React vereinnahmt hat, und man hat doch auch nicht besonders schnell reagiert, um dieses Missverständnis auszuräumen, oder?

[spp00]

Schon jetzt läuft die offizielle React-Website nicht auf Servern von Meta, sondern auf Vercel.

[moderna]

Ich stimme zu.

[click]

Obwohl Svelte, in das Vercel ebenfalls investiert, wohl einfach kleiner ist, hatte ich nicht das Gefühl, dass es dort zu so einer Art Vendor Lock-in kommt; mich würden die Unterschiede auch interessieren.

[spp00]

Svelte wird von Vercel nur unterstützt; Vercel führt das Projekt nicht. Next hingegen wird tatsächlich von Vercel selbst geführt.

Auch bei den GitHub-Repositories ist es so, dass Next der Vercel-Organisation untersteht, Svelte hingegen nicht.

Und bei Next.js erscheint Vercel im Copyright-Hinweis im Footer der offiziellen Website, bei Svelte hingegen nicht.

[click]

Dass Vercel Rich Harris eingestellt hat, hatte also den Charakter eines Sponsorings.

[spp00]

https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte Ja, das ist eine Anstellung mit starkem Fördercharakter. Im Grunde zahlt man ihm ein Gehalt, damit er sich in Vollzeit der Entwicklung von Svelte widmen kann. Vercel hat außerdem klar gemacht, dass Svelte weiterhin ein unabhängiges Projekt ist.