Wann braucht ein Projekt React? Das ist die Frage, der sich Chris Coyier in einem aktuellen Blogbeitrag gewidmet hat. Ich bin ein großer Fan von Chris' Schreibstil, daher war ich neugierig, was er zu sagen hatte.
Kurz gesagt, Chris stellt eine Reihe von guten und schlechten Gründen vor, warum man React (oder andere ähnliche moderne JavaScript-Bibliotheken) für ein Projekt verwenden könnte. Doch während ich seinen Argumenten nicht widerspreche, komme ich dennoch zu einer anderen Schlussfolgerung.
Deshalb bin ich heute hier, um zu argumentieren, dass die Antwort auf die Frage "Wann braucht ein Projekt React?" nicht "es kommt darauf an" ist. Sondern "jedes Mal".
React vs Vue vs Angular vs…
Zuerst einmal eine Klarstellung: In seinem Artikel wählte Chris React als Platzhalter für "Front-End-Bibliotheken" im Allgemeinen, und das werde ich hier auch tun. Außerdem ist React das, womit ich aus meiner laufenden Arbeit an VulcanJS, einem React- und GraphQL-Framework, am vertrautesten bin.
Das gesagt, sollten meine Argumente gleichermaßen für jede andere Bibliothek gelten, die die gleichen Funktionen wie React bietet.
Die Macht des Hammers
Wenn man nur einen Hammer hat, sieht alles wie ein Nagel aus.
Dieses Sprichwort wird seit langem verwendet, um jeden zu verurteilen, der versucht, einen systematischen Einheitsansatz auf jedes Problem anzuwenden.
Aber nehmen wir für einen Moment an, Sie würden in einer Welt voller Nägel leben (auch wenn das unangenehm klingt) und Ihr treuer Hammer könnte sich um alle Probleme kümmern, denen Sie begegnen.
Denken Sie nur an die Vorteile, **jedes Mal dasselbe Werkzeug wiederverwenden** zu können.
- Keine Zeit wird darauf verwendet, zu entscheiden, welches Werkzeug verwendet werden soll.
- Weniger Zeit wird darauf verwendet, neue Werkzeuge lernen zu müssen.
- Mehr Zeit, um besser im Umgang mit Ihrem gewählten Werkzeug zu werden.
Ist React also dieses Werkzeug? Ich glaube, es könnte es sein!
Das Komplexitätsspektrum
Zuerst gehen wir auf das häufigste Argument gegen den "React-alles"-Ansatz ein. Ich zitiere Chris direkt:
Ein Blog hat zum Beispiel *wahrscheinlich* keine der Probleme und passt in keine der Szenarien, die React zu einer guten Wahl machen würden. Und weil es keine gute Wahl ist, ist es wahrscheinlich eine *schlechte*, da es komplizierte Technologie und Abhängigkeiten für etwas einführt, das es nicht erfordert.
Das ist fair. Ein einfacher Blog braucht *wahrscheinlich* kein React. Selbst wenn man ein wenig JavaScript benötigt, um ein Anmeldeformular für einen Newsletter zu verknüpfen, kann man einfach jQuery verwenden.
Was ist das? Sie müssen dieses Formular an mehreren Stellen auf verschiedenen Seiten verwenden? Und es nur unter bestimmten Bedingungen anzeigen? Und es auch animieren? Moment mal...
Der Punkt, den ich mit diesem kleinen Szenario machen möchte, ist, dass Komplexität keine Alles-oder-Nichts-Entscheidung ist. Stattdessen leben moderne Websites in einem kontinuierlichen Spektrum, das von einer statischen Seite bis hin zu einer reichhaltigen Single-Page-Anwendung reicht.
Vielleicht ist Ihr Projekt *jetzt* bequem am "einfachen" Ende des Spektrums angesiedelt, aber was ist in sechs Monaten? Ist es nicht besser, eine Technologie zu wählen, die Ihnen Raum zum Wachsen lässt, anstatt eine, die Sie in schlechte Praktiken drängt?
Die Vorteile von React
Vorzeitige Optimierung ist die Wurzel allen Übels.
Eine weitere beliebte Redewendung unter Programmierern. Wer braucht schon einen Hammer und Nägel, wenn Isolierband auch gut funktioniert!
Aber das setzt voraus, dass "vorzeitige Optimierung" ein langer, mühsamer Prozess mit wenigen Vorteilen ist. Und ich glaube nicht, dass das auf React zutrifft.
Auch wenn es einige Zeit dauern kann, sich an React zu gewöhnen, sobald Sie seine Grundkonzepte verstanden haben, werden Sie genauso produktiv sein wie mit klassischen Front-End-Werkzeugen.
Vielleicht sogar mehr, denn React nutzt das extrem leistungsfähige Konzept von **Komponenten**. So wie CSS Sie ermutigt, in wiederverwendbaren Klassen und Stilen zu denken, drängt Sie React zu einer flexiblen, modularen Front-End-Architektur, die Vorteile für jeden Anwendungsfall hat, vom einfachen statischen Homepage bis hin zum interaktiven Back-End-Dashboard.
JavaScript, JavaScript überall
Wir leben in einer JavaScript-Welt. Oder, wie Chris es ausdrückt:
Sie haben Node.js auf der Serverseite. Es gibt unzählige Projekte, die CSS aus dem Mix herausreißen und Stile über JavaScript handhaben. Und mit React ist auch Ihr HTML in JavaScript.
Alles JavaScript! Lang lebe JavaScript!
Chris ist nicht ganz überzeugt, aber ich bin es. JavaScript an sich ist nicht unbedingt perfekt, aber der Zugriff auf das gesamte moderne NPM-Ökosystem ist erstaunlich.
Die Installation eines jQuery-Plugins bedeutete früher, die Homepage zu finden, es herunterzuladen, es in Ihr Projektverzeichnis zu kopieren, einen `<script>`-Tag hinzuzufügen und dann hoffentlich alle paar Monate nach neuen Versionen zu schauen. Heutzutage ist die Installation desselben Plugins als React-Paket nur noch eine einzige npm install-Befehlszeile.
Und mit neuen Bibliotheken wie styled-components wird sogar CSS jetzt widerwillig in die Zukunft gezogen.
Glauben Sie mir, wenn man sich an diese Welt gewöhnt hat, in der alles die gleiche Sprache spricht, ist es schwer, zur alten Vorgehensweise zurückzukehren.
Denkt denn niemand an die Benutzer!
Ich weiß, was Sie denken: Bisher habe ich versucht, Ihnen die Vorteile von React für Entwickler schmackhaft zu machen, aber ich habe sorgfältig jegliche Erwähnung der Endbenutzererfahrung vermieden.
Und das bleibt das Hauptargument gegen moderne Bibliotheken: langsame, JavaScript-überladene Seiten, die ewig brauchen, um nur eine einzige "Ein seltsamer Trick"-Werbung anzuzeigen.
Bis auf ein kleines Geheimnis: **Sie können alle Vorteile von React ohne jegliches JavaScript genießen**!
Wovon ich hier spreche, ist das Rendering von React auf **dem Server**. Tatsächlich ermöglichen Tools wie Gatsby (und bald Next.js) sogar das Kompilieren von React-Komponenten in statische HTML-Dateien, die Sie beispielsweise auf GitHub Pages hosten können.
Als Beispiel ist meine persönliche Website eine Gatsby-generierte React-App, die überhaupt kein JavaScript lädt (abgesehen von einem Google Analytics-Snippet). Ich erhalte alle Vorteile der Verwendung von React in der Entwicklung (alles JavaScript, Zugriff auf das NPM-Ökosystem, styled-components usw.), aber am Ende habe ich ein 100%iges HTML- und CSS-Endprodukt.
Zusammenfassend
Zur Erinnerung, hier sind die vier Gründe, warum ich React für eine gültige Wahl für *jedes* Projekt halte:
- Es ist wirklich schwer zu garantieren, dass Sie nicht *jemals* interaktive Funktionen wie Tabs, Formulare usw. benötigen werden, selbst für die einfachste Website.
- Der komponentenbasierte Ansatz von React hat große Vorteile, selbst für statische, inhaltsbasierte Websites.
- Der Zugang zum modernen JavaScript-Ökosystem ist ein riesiger Vorteil.
- Moderne Server-Rendering-Tools eliminieren die Nachteile der Verwendung von React für den Endbenutzer.
Was denkst du, Chris? Habe ich einen überzeugenden Fall gemacht? Oder bleiben noch Zweifel in deinem Geist?
Und was ist mit Ihnen, lieber Leser? Ob Sie wie Chris denken, dass jedes Werkzeug seinen Zweck hat, oder ob Sie mir zustimmen, dass die Zeit des Hammers gekommen ist, lassen Sie es uns in den Kommentaren wissen!
Lang lebe JavaScript! klingt wie Lang lebe Hydra! für mich. Und ich bin mit Shield
Ich sehe viele Leute, die Ihren Ansatz verfolgen, sich aber nicht dazu bekennen. Deshalb applaudiere ich Ihnen dafür.
Ich habe diesen Ansatz früher auch verfolgt, aber gelernt, mehr in den Problembereich zu investieren als in die Frameworks/Toolsets, da diese kommen und gehen wie der Wind.
Viel Erfolg mit VulcanJs!
Lebhafte Debatte!
Bevor ich beginne, möchte ich sagen, dass *ich kein Experte für alles im Bereich React bin*. Ich bin Anfänger, habe aber die Perspektive von einem Jahrzehnt als Tech-Pundit und Produktverantwortlicher für ein Produkt in React.
Wo ich dachte, dass dies vielleicht in Richtung React-Native gehen würde, wo man, wenn man sich für den React-Weg entscheidet, Türen geöffnet bekommt (wie bei einer nativen App), die man auf anderen Tech-Stacks nicht unbedingt hat. Das ist also wahrscheinlich eine weitere Sache, die man zu Ihren Argumenten hinzufügen kann.
Es ist auch schön, dass wir Argumente bezüglich SEO, progressivem Enhancement und Benutzererfahrung und Ähnlichem beiseitelegen können, da React-Apps auf dem Server gerendert werden können und wir somit gesunde URLs haben und niemand ausgeschlossen wird und Ähnliches.
Oder können wir das? Server-gerenderte Seiten sind wahrscheinlich großartig für Ihren Blog, aber ich glaube nicht, dass man bedenkenlos sagen kann, dass man keinerlei Client-seitiges JavaScript ausliefern muss. Ich denke, 99% der React-Nutzung ist speziell für das Front-End. Es ist all das Zustandsmanagement (als Reaktion auf clientseitige Ereignisse) und DOM-Management, das React ursprünglich attraktiv gemacht hat und auf das ich Leute gerne zu React verweisen würde. Zu sagen, "Sie können alle Vorteile von React ohne jegliches JavaScript genießen!" fühlt sich für mich nicht ganz richtig an.
Ich finde es schwer, mir vorzustellen, wie eine server-gerenderte React-App aussieht, die auch die gesamte Front-End-Funktionalität von React nutzt. Ich schätze, deshalb nennt Ember seine Version davon "FastBoot", oder? Weil man die Seite ausliefert, die aber (größtenteils) nicht funktionsfähig ist, bis das JavaScript eintrifft und ausgeführt wird. Wahrgenommene Leistung.
Auch die Komplexität spielt hier eine Rolle. Es gibt einen erheblichen Unterschied zwischen
React
und
React + Redux*
(*Ersetzen Sie Ihr bevorzugtes Zustandsverwaltungssystem) Und Redux ist meiner Meinung nach ein ziemlich wichtiges Element, wenn ein großer Teil des Ziels darin besteht, Spaghetti-Code und uneinheitliche Wahrheitsquellen zu bekämpfen.
Und das ist schon ein großer Unterschied zu
React + Redux + Immutable + Styled Components + Babel + Webpack + Lambda + DynamoDB
All diese Dinge bieten viel Wert und sind in vielen Situationen sinnvoll. Aber Himmel, ist das ein dicker Stack.
Sie haben das nicht befürwortet, aber selbst mit Gatsby schauen Sie sich an
React + Gatsby + Webpack + React Router + Server Side Rendering
Was eine nicht unerhebliche Investition ist.
Ich habe hier keinen riesigen Punkt, außer dass dieser Weg eine große Lernkurve und viele Abhängigkeiten bedeutet. Meine Hoffnung wäre, dass im Laufe der Zeit Entscheidungen getroffen werden, die ein Aussteigen (um auf einen neuen, zukünftigen Hot-Tech-Stack umzusteigen) nicht so schwierig machen. Dinge wie Inhalte in Markdown und die Verwendung von CSS.
Aber man könnte argumentieren, dass jeder Stack dies tut.
Machen wir die vier Punkte!
Ich glaube nicht, dass es "interaktive Funktionen" sind, die React erfordern. Insbesondere nicht eine Handvoll davon, wie Tabs und (auch wiederholte) Formulare. Es ist ein *riesiger Berg* an interagierenden Funktionen, die miteinander verknüpft sind, was für mich auf den Moment hindeutet, "nach React zu greifen".
Wenn das Endprodukt "eine statische inhaltsbasierte Website" ist, dann ist die Tür für Stack-Experimente weit offen. Alles ist auf dem Tisch. Klassische CMS, statische Website-Generatoren, Websites, die mit Dingen wie Pug oder Nunjucks kompiliert wurden, und sicher, ein cooles Headless-CMS + server-gerendertes React-Ding könnte perfekt sein.
Es fällt mir schwer zu denken: "Statische Inhaltsseite? Die beste Option dafür ist server-gerendertes React". Dieser Stack ist ziemlich dick und meinungsbildend, und ich bin mir nicht sicher, ob jede Website wie diese den exakt gleichen Nagel für den metaphorischen Ein-wahren-Hammer darstellt.
Einverstanden! React ist dafür nicht zwingend erforderlich, aber ich verstehe den Punkt.
In Bezug auf eine "Fast-Boot"-Situation, ja. Das hilft bei der Ladegeschwindigkeit und minimiert so die Nachteile der Langsamkeit. In Bezug auf das klassische Denken der progressiven Verbesserung, nein. Wenn Sie ein animiertes und interaktives Formular haben, das von React angetrieben wird, benötigen Sie React auf der Clientseite, um es anzutreiben, und ich würde argumentieren, dass React Sie nicht gerade dazu ermutigt, dieses server-gerenderte Formular für den Fall zu erstellen, dass Client-seitiges React nicht wie erwartet funktioniert.
Ich genieße diese Diskussion! Danke für Ihre Perspektive, Sacha.
Tolle Debatte! Nur um eine Sache zu kontern:
Da Gatsby sich um Ihre Webpack-Konfiguration, das Routing sowie das SSR kümmert, ist der Gatsby-Stack in der Praxis nur React und Gatsby. Ich denke, das ist, wo viel Verwirrung über React herkommt: Leute, die mit dem JavaScript-Ökosystem nicht vertraut sind, gehen davon aus, dass Webpack, Babel usw. alles einzelne Teile des Stacks sind, die man lernen muss, wenn sie stattdessen nur Werkzeuge sein können, die im Hintergrund laufen und Ihre Entwicklungserfahrung verbessern.
Aber insgesamt denke ich, Sie machen einige durchaus vernünftige Punkte, was es sehr schwer macht, Ihnen zu widersprechen... Trotzdem habe ich mein Bestes getan ;)
Und dann eine binäre Empfehlung zu einem sehr komplexen Thema machen...
Was hier meiner Meinung nach fehlt, und was oft in diesen Arten von Argumenten fehlt, sind Hintergrundinformationen, insbesondere die getroffenen Annahmen. Es gibt eine breite Palette von Projekten, an denen wir arbeiten, und sie erfordern oft unterschiedliche Werkzeuge, aber manchmal ist es sehr schwierig, über die eigene Welt hinauszublicken und in andere zu sehen. Oft finde ich mich, wenn ich mit Client-Side-Evangelisten spreche, sofort im Widerspruch zu ihnen, aber wenn ich tiefer grabe, stelle ich fest, dass die Art der Arbeit, die sie tun, tendenziell gut für JS-lastige Projekte geeignet ist, während die Art der Arbeit, die ich täglich mache, das nicht ist.
Vielleicht war das eine schlechte Wahl für Beispiele, aber Formulare gibt es schon länger als JavaScript, es gibt keinen Bedarf, einfache Formulare überhaupt mit JS zu verwenden. Tabs können auch in modernen Browsern ohne JS einfach erstellt werden. Solche Argumente ohne zusätzlichen Hintergrund zu machen, führt dazu, dass neue Entwickler sie als bare Münze nehmen und meiner Meinung nach zu einem Rückgang der Web-Kompetenz und des allgemeinen Verständnisses für Entwickler führt, die jetzt lernen, für das Web zu programmieren.
Ich habe mit diesem Artikel bewusst einen kontroversen Standpunkt eingenommen, also bleibe ich dabei ;)
Ich glaube, das ist eigentlich eine gute Sache. Webentwicklung war viel zu lange unübersichtlich und komplex, und nur weil wir uns daran gewöhnt haben, merken wir es nicht. Sicher, man kann Tabs mit Radio-Buttons und CSS-Selektoren erstellen, aber ist das eine vernünftige Art zu programmieren? Haben wir nicht vor 10 Jahren alle gegen den Missbrauch von Tabellen für Layouts protestiert?
Deshalb glaube ich, dass es höchste Zeit ist, dass React (oder etwas Ähnliches) als Abstraktionsschicht über HTML/CSS dient und diese ganze "Web-Kompetenz" für alle außer einer Minderheit von Webentwicklern obsolet macht.
Das ist ein sehr valider Punkt, Sacha, und einer, den ich unterstützen kann. Allerdings bekomme ich beim Lesen Ihres Artikels eher eine streitlustige als eine ermutigende Botschaft.
Was ich daraus mitnehmen möchte, ist, dass React, ähnlich wie WordPress, ein Werkzeug sein sollte, das jeder aufstrebende Entwickler ohne Angst vor der Frage "Ist das wirklich das richtige Werkzeug?" verwenden kann. Wenn Sie tiefer in die Webentwicklung einsteigen, kann es ebenso eine gute Wahl sein, aber Sie sollten sich auch bewusst sein, dass es noch viel mehr gibt.
Hören wir auf, darüber zu streiten, und fangen wir an, mehr Leute zu ermutigen, mehr coole Dinge zu bauen.
Können Sie uns helfen, die Motivationen und möglichen Interessenkonflikte in dieser Debatte zu verstehen? Die übliche Methode zur Prüfung eines "externen" Beitrags ist die Aufnahme einer Erklärung zu möglichen Interessenkonflikten (normalerweise am Ende). Chris kenne ich, Sacha kenne ich nicht. Gibt es eine Verbindung (beruflich, monetär oder anderweitig) mit dem fraglichen Produkt und dem Autor des Arguments? Helfen Sie uns bitte, potenzielle Voreingenommenheit bei solchen Artikeln zu verstehen. Danke.
Ich habe die Erwähnung von "vulcanJS" bei meiner ersten Durchsicht übersehen, bin mir aber immer noch nicht sicher, wie es vollständig mit React verbunden ist – vielleicht ist der Artikel nicht für Leute, die das Produkt nicht nutzen? (noch)
Ich sehe Yeogurt als die beste Option für einfache statische Websites. Es bietet ein großartiges Framework für modulares Design und gibt Ihnen einfachen Zugang zur npm-Community.
Danke Chris, dass Sie den größeren Abhängigkeitsstack erklärt haben, der sich möglicherweise ergibt, wenn man sich für React entscheidet. Ich habe keinen Zweifel daran, dass React super mächtig ist und Webentwickler gut daran tun, sich damit zu beschäftigen. Ich bin jedoch immer ein wenig skeptisch, in Technologien zu investieren, die man nicht unbedingt "versteht". Zum Beispiel sehe ich viele Projekte, die unnötigerweise und aus Gewohnheit Bibliotheken importieren. Fazit: Verstehen Sie die Technologie, die Sie verwenden, wann Sie sie verwenden und warum. Ich bin auch ein Verfechter dafür, sein Gehirn zur Problemlösung einzusetzen, anstatt nur eine vorgefertigte Komponente zu importieren – manchmal ist es ein gutes Gefühl, etwas von Grund auf neu zu bauen und tatsächlich etwas aus den Grundprinzipien zu lernen, anstatt nur zu lernen, wie man Technologiekomponenten verknüpft oder zusammenwürfelt, um die gewünschten Ergebnisse zu erzielen.
Dieser Artikel stößt auf viel Gegenwind, aber aus meiner Sicht (kleine Agentur mit kleinen bis mittleren Kunden) ist React äußerst nützlich, da Kunden immer vorwärts wollen und nicht rückwärts, indem sie im Laufe des Projekts zusätzliche Funktionen hinzufügen.
Wenn wir also zum Beispiel mit einem Kunden beginnen, der nur eine statische Website benötigt, aber später eine App erstellen möchte, bedeutet der direkte Umstieg auf React später weniger Arbeit.
Außerdem macht es verdammt Spaß, damit zu arbeiten. Alles, was ich jetzt mache, ist so DRY, dass ich mich endlich auf interessante Dinge konzentrieren kann, anstatt das Gefühl zu haben, den ganzen Tag Widgets zu bauen. Wenn die Lernkurve zu steil erscheint, schauen Sie sich "react create app" an – es funktioniert sofort.
Das ist ein großartiger Punkt, danke!
Ich glaube nicht, dass React dem gleichwertig mit einem "Hammer" ist. Ein Hammer ist ein grundlegendes Werkzeug, das seit Tausenden von Jahren existiert und sicherlich noch viele Jahre verwendet wird. Etwas Analoges in der Web-Welt wären HTML, CSS und (reines) JavaScript – standardisierte Technologien, die seit langem existieren und lange existieren werden.
React (und Co) ist ein komplexeres Werkzeug, das dem Test der Zeit nicht standgehalten hat. Wahrscheinlich wird es in ein paar Jahren als uncool gelten, und die Entwicklung wird sich verlangsamen. Diejenigen, die heute React verwenden, werden sich irgendwann für etwas anderes entscheiden müssen.
Ich bin nicht gegen React und andere ähnliche Frameworks, aber das sind Werkzeuge, die geschaffen wurden, um spezifische Probleme unserer Zeit zu lösen, und sie sollten nicht als Entschuldigung verwendet werden, um das Erlernen der Kerntechnologien zu vermeiden.
React ist ein Werkzeug, das analog zu dem ist, was jQuery bis vor kurzem war, oder was WYSIWYG-Editoren in der weiter entfernten Vergangenheit waren. Wenn Sie ein Webentwickler sind, sollten Sie die Kerntechnologien des Webs beherrschen und nicht die Modeerscheinung des Tages als Ausrede dafür nutzen. Dann können Sie React usw. verwenden, wann immer es für das spezifische Projekt sinnvoll ist, und nicht, weil es das einzige Werkzeug ist, das Sie gut kennen.
Kann ich dir nicht mehr zustimmen, Theo.
Ich liebe deine Sachen, Sacha, und ich schätze es, dass du hier eine wirklich voreingenommene Sichtweise einnimmst, um deinen Punkt zu machen, aber es gab ein paar Dinge, die ich erwähnen wollte, denen ich widerspreche oder die ich in meiner eigenen Praxis problematisch gefunden habe.
Dieser Kommentar kam am Ende eines Satzes über das Hinzufügen eines Newsletter-Anmeldeformulars mit der Annahme, dass jQuery benötigt würde, um es funktionsfähig zu machen und zu animieren. Wir können Newsletter-Anmeldeformulare und Animationen einfach ohne jQuery oder JavaScript erstellen, aber Sie haben richtig gesagt, dass bestimmte Bedingungen mit Hilfe von React einfacher gemacht werden können.
Außerdem sind die Technologien, die wir verwenden, HTML, CSS und JavaScript, sodass hier auch keine Festlegung erfolgt.
Das klingt zwar gut, aber es gibt das Problem, zuerst NPM einzurichten... und Vorsicht, wenn etwas schief geht. Manchmal ist es einfacher, auf eine Homepage zu gehen und die neueste stabile Version einer Bibliothek herunterzuladen, als NPM mit Ihrem Projekt einzurichten und zum Laufen zu bringen.
Auch hier weiß ich, dass Sie einen Punkt machen. Ich bin daran interessiert, React besser zu verstehen, als ich es derzeit tue, aber die Leute sollten nicht getäuscht werden, dass es der einfachste Ansatz zum Erstellen jeder Website ist.
Mach weiter so, Sacha!