Ein objektiver Blick auf den Bibliothekskrieg: React gegen Vue

Woher kommen wir? Was sind wir? Wohin gehen wir?

Halten wir einen Moment inne und überlegen wir, wo wir stehen. Als absoluter Boomer bezweifle ich aufrichtig, dass vor 10 oder so Jahren irgendjemand hätte vorhersagen können, dass Web-Entwicklung würde so weit gehen.

Utility-Desktop-Anwendungen gehören der Vergangenheit an, da alles in einem Browser erledigt werden kann. Tatsächlich werden Anwendungen, die APIs auf niedrigerer Ebene verwenden müssen, die im Browser nicht verfügbar sind, ebenfalls mit Browser-Engines und -Sprachen geschrieben, weil sie so leichter zu pflegen sind.

Mobile Anwendungen können leicht durch Werkzeuge für die Webentwicklung ersetzt werden - siehe React EinheimischNativeScript. Darüber hinaus haben wir PWA, die leicht "imitiert" den Betrieb von mobilen Anwendungen. Darüber hinaus können Komponenten, die eine in NativeScript geschriebene Anwendung antreiben Vue oder React können leicht verschiedene Code Elemente zwischen Plattformen.

Eines müssen wir zugeben - Webanwendungen sind derzeit ein Kraftpaket, das nur schwer auf den Boden der Tatsachen zu bringen sein wird. Als Nutzer sehe ich mich praktisch überall mit ihnen arbeiten: Kommunikation über Slack, Verwendung eines Code-Editors, Präsentationen oder sogar das Schreiben eines Blogartikels.

Es ist schwer vorherzusagen, was in ein paar Jahren passieren wird. WebAssembly kommt ins Spiel, und es wird uns ermöglichen, Anwendungen, die komplexere Berechnungen erfordern, in die Browserwelt zu verlagern. Eine Tatsache bleibt jedoch unverändert - es ist wirklich schwer, ein Hindernis zu finden, um mit dem Einsatz von Webtechnologien eine Anwendung zu bauen, von der wir nur träumen können.

Der Urknall in der Internet-Realität

Um es auf den Punkt zu bringen: Gehen wir einen Moment zurück in die Vergangenheit, bevor die ersten größeren Web-Frameworks auftauchten und Anwendungen auf zwingende Art und Weise entwickelt wurden. Jede interaktive Mechanik auf einer Seite wurde manuell gehandhabt und war für eine bestimmte Aktion verantwortlich.

Als bestes Beispiel kann die jQuery-Bibliothek angeführt werden - seinerzeit eine der beliebtesten Lösungen für die Handhabung einfacher Ereignisse. Mit ihrer Hilfe wurden verschiedene Dropdown-Menüs, Übergänge, Animationen, Taschenrechner und ähnliche Mechanismen implementiert.

Es ist erwähnenswert, dass schon damals Probleme in komplexeren Anwendungen auftraten - an Stellen, an denen verschiedene, unabhängige Teile z. B. auf einen richtigen Klick oder das Tippen von etwas reagieren mussten. Die meisten Anwendungen hatten keinen expliziten Zustand und wurden stattdessen z.B. durch die Attribute von Elementen oder die Klassen, die sie hatten, gerettet.

Damals war klar, dass dem aktuellen Ansatz die Reaktivität fehlte - eine strukturierte Möglichkeit für Komponenten, miteinander zu kommunizieren und z. B. ihren Zustand oder verschiedene Ereignisse auszutauschen, was die Wartung der Anwendungen erleichterte und ihnen ein gutes Benutzererlebnis zu geringen Kosten ermöglichte.

Erste Schritte auf dem Weg zu bekannten Rahmenwerken

Mit der Zeit tauchten die ersten Frontend-Frameworks auf, die die Architektur für komplexere Anwendungen strukturieren sollten.

Diese Frameworks basierten hauptsächlich auf dem MVC-Muster - einige schlugen einen eher manuellen Ansatz vor, wie z. B. Backbone.js, während andere, wie z. B. Knockout.js, auf eine Zwei-Wege-Datenbindung setzten.

Dennoch könnte man das Gefühl haben, dass das Schreiben der Anwendung schwieriger war, viel mehr Kodierung erforderte und nicht unbedingt die beabsichtigten Ergebnisse lieferte oder die verlorene Zeit für die Anwendungsentwicklung kompensierte.

Der Hauptgrund, warum es schwierig war, die goldene Mitte im JS-Ökosystem zu finden, lag darin, dass sie unter den bekannten Werten eine gewisse Sonderstellung einnahm. Programmiersprachen die schon seit langem ihre Wege geebnet haben.

Und ich möchte hier nicht näher darauf eingehen, welche Wege die Entwicklung der verschiedenen Frameworks im Laufe der Geschichte begleitet haben. Allerdings ist es wichtig, eine Sache zu beachten - die Reifezeit des JS-Ökosystems in den Browsern war nicht einfach und stand vor vielen Prüfungen.

Dies ist der einzige Grund, warum wir heute Webanwendungen erstellen und sie auf eine sehr einfache und schmerzlose Weise entwickeln können.

Grundlegende Informationen und ein kleiner Vergleich

Anstatt mit Fleisch zu werfen, wie es im Internet üblich ist, sollten wir uns beide Bibliotheken ansehen, Informationen über sie sammeln und sie vergleichen - sowohl in der Theorie als auch in der Praxis.

HINWEIS: Die Beschreibung der Mechanismen, die in Vue bezieht sich speziell auf Version 2. Version 3 bringt eine Menge wichtiger Änderungen mit sich, ist aber kein wirklicher Konkurrent für React im Moment, wenn auch nur aufgrund seiner Reife - Vue 3 Erscheinungsdatum: 18. September 2020.

Um eines klarzustellen: Wenn man sich näher mit den beiden Bibliotheken beschäftigt, stellt man fest, dass es mehr Gemeinsamkeiten als Unterschiede gibt. Abgesehen von der Art der Verwendung der Bibliotheken als solche - beide haben sehr ähnliche Konzepte, wie sie funktionieren. Beide werden von einem ähnlichen Ökosystem angetrieben und ihre Verwendung ist nicht diametral verschieden.

● Der Teufel steckt im Detail - je öfter wir ein Werkzeug verwenden, desto größere Nachteile seiner verschiedenen Lösungen stellen wir fest. Ein gutes Beispiel hierfür ist die Zwei-Wege-Datenbindung, die am häufigsten verwendet wird in Vue als V-Modell-Eigenschaft: Sie macht vieles einfacher, erledigt vieles automatisch und erfordert keine zusätzliche Unterstützung bei der Änderung von Werten.

Es gibt jedoch Fälle, in denen wir einen Änderungsversuch gezielt verfolgen und entsprechend reagieren müssen. In diesem Fall zwingen uns die auf dem V-Modell basierenden Komponenten oft dazu, mit anderen Komponenten herumzuspielen. Vue Mechanismen wie z. B. berechnete Eigenschaften, wodurch der erzielte Effekt oft viel schlechter aussieht als bei einem manuellen Ansatz;

● Ein weiterer interessanter Aspekt ist JSX, ein "vagabundierender" Weg, um gerenderte Inhalte mit React. In der Entwicklergemeinde gibt es unterschiedliche Meinungen dazu.

Nach meinen Beobachtungen scheinen Entwickler, die eine andere Umgebung als JS verwenden, z. B. PHP oder C#, sind eher geneigt, Ansichten so zu gestalten, dass Vue tut.

Zusammenfassend - Vorlagen bekannt aus Vue ermöglichen es, Ansichten auf eine sehr klare und elegante Weise zu definieren, während React's JSX es in vielen Fällen erlaubt, sie schneller zu erstellen, auf spezifische Bedürfnisse zugeschnitten und oft weniger Code benötigt, um verschiedene Strukturen aufzubauen;

Schauen wir uns auch die Ökosysteme dieser beiden Werkzeuge an. Im Prinzip können wir sagen, dass sie sich in nichts unterscheiden. Beide werden nicht ohne Grund als Bibliotheken bezeichnet - sie bieten das absolute Minimum für die Unterstützung reaktiver Webanwendungen.

Der Rest, der sich auf die Kommunikation mit der API, den Datenfluss und die UI-Komponenten bezieht, die auf den verschiedenen Unterseiten verwendet werden, sind die so genannten Vendoren - Bibliotheken, die von außen kommen und ordnungsgemäß an die Website angeschlossen werden müssen. Projekt. Es ist ein bisschen wie in der Welt von Lego: Wenn man ein kohärentes Ganzes bauen will, muss man es aus einzelnen, kleinen Bausteinen zusammensetzen.

Diese Allegorie bezieht sich auf die präzise angebrachten Komponenten, die die Leistung von Anwendungen sind, die mit React oder Vue;

Eine wichtige Sache, vor allem für Menschen, die nicht so erfahren in der JS-Umgebung sind, ist die Höhe der Einstieg in eine bestimmte Bibliothek. Mit anderen Worten - die Komplexität des Werkzeugs, bestehend aus der direkten Zeit, die Sie auf das Verständnis seiner Mechanik verbringen müssen.

Ich denke, eines muss hier unmissverständlich festgestellt werden - im Fall von Vueist es viel einfacher. Wir haben eine Zwei-Wege-Datenbindung, wir haben eine elegant spezifizierte Vorlage, die Lösungen in anderen Sprachen, z. B. Twig, täuschend ähnlich ist, und schließlich - wir haben keine Kopfschmerzen, die durch das Erlernen von Theorien über die Funktionsweise einzelner Hooks und Fälle, in denen bestimmte Mechanismen verwendet werden müssen, verursacht werden.

Was sagen die Statistiken?

Es ist nicht gerade eine gute Wahl, sich direkt nach der Stimme der Masse zu richten. Ein guter Schritt auf dem Weg zu einer guten Entscheidung ist es jedoch, zu analysieren, was Menschen sagen, die mit diesen Bibliotheken zu tun hatten.

Und ja - Sterne auf github kann ein Indikator dafür sein, wie stark die Gemeinschaft einer bestimmten Bibliothek in ihre Entwicklung involviert ist, wie sie von den Entwicklern wahrgenommen wird und ob sie daran interessiert sind, wohin sie sich entwickelt. Ingenieure, die sich für ein bestimmtes Repository interessieren, erhalten oft Benachrichtigungen über neue Versionen oder Codeänderungen, was sich in ihrem direkten Wissen über die Bibliothek niederschlägt.

Die Anzahl der Sterne auf Github sollte jedoch nicht als Orakel betrachtet werden - nicht jeder Entwickler, der ein Tool mag, wird eine Markierung hinterlassen - stattdessen würde ich sie als Zeichen der reinen Leidenschaft der Entwickler für ein bestimmtes Open-Source-Projekt betrachten.

Google Trends ist ein bekannter Dienst, der es uns ermöglicht, das Interesse an bestimmten Themen im Laufe der Zeit zu untersuchen. Obwohl er kein rationaler Indikator für Qualität oder Nutzung ist, kann er alle Arten von Analysen liefern.

Es ist leicht zu erkennen, dass der Verlauf der letzten 5 Jahre ziemlich ähnlich ist, wenn man die beiden Protagonisten des heutigen Artikels vergleicht. Die grundlegende Schlussfolgerung, die sich aus dem Diagramm ziehen lässt, lautet React in Bezug auf die Suchpopularität höher ist als seine Konkurrenten.

Um das klarzustellen: Dass eine Bibliothek bei Google Trends ganz oben steht, bedeutet nicht, dass sie besser ist. Wie ich bereits erwähnt habe, geht es um die Beliebtheit bei der Bevölkerung - wahrscheinlich haben mehr Menschen von diesem Tool gehört, es könnte mehr Interesse bei den Nutzern geweckt haben. CTOs, Softwareentwickler oder Menschen, die einfach nur ein bestimmtes Werkzeug erlernen wollen.

Entspricht diese Grafik der Realität? In gewisser Weise, ja. Im Allgemeinen weisen die befragten Personen mehr unterschiedlich anspruchsvolle Kenntnisse auf über React als Vue. Welche Meinungen können Sie im Gespräch mit diesen Menschen einholen? Ich werde versuchen, dies im nächsten Absatz zu skizzieren.

Zustand von JS  ist eine Website, die jedes Jahr Umfragen unter Personen durchführt, die mit JavaScript-bezogenen Technologien arbeiten. Ihr Ziel ist es, Informationen von Entwicklern darüber zu sammeln, wie sie die Werkzeuge sehen, mit denen sie täglich arbeiten.

Die Fragen beziehen sich auf einzelne Tools für unterschiedliche Zwecke - z. B. Tools, die im Front-End und im Back-End eingesetzt werden, aber auch Tools für das Testen, die Verwaltung des Anwendungsstatus usw. Auf jede dieser Fragen gibt es keine einfache Ja/Nein-Antwort, sondern die Website stellt eine Reihe von Fragen zum Tool selbst, zu Interessen, Erfahrungen und einer Gesamtbewertung, die auf den Satz "Würden Sie dieses Tool in zukünftigen Projekten verwenden?" hinausläuft.

Auf der Website selbst können Sie zahlreiche Analysen durchführen, relevante Tools vergleichen und manchmal auch weniger bekannte Bibliotheken kennenlernen, die sich in der JS-Welt zu etablieren beginnen, an Popularität gewinnen und gleichzeitig eine hohe Benutzerfreundlichkeit aufweisen. Ich möchte Sie aufrichtig dazu ermutigen, die Inhalte dieser Website zu durchstöbern.

Fassen wir den Abschnitt mit Statistiken zusammen. Die Analyse verschiedener Arten von Diagrammen kann oft eine sehr gute Option sein, um verschiedene Aspekte eines bestimmten Themas zu vergleichen. Es ist jedoch wichtig zu bedenken, dass es nicht unbedingt das Klügste ist, der Stimme der Masse zu folgen. Stattdessen können Sie eine fundierte Entscheidung treffen, indem Sie einige der Erkenntnisse aus der Analyse von Diagrammen nutzen.

Beste Wahl für Entwickler

Ich habe bereits auf die niedrigere Eintrittsschwelle für Vue - In der Tat können Sie sich schneller auf die eigentliche Entwicklung der Anwendung konzentrieren, indem Sie das Tool verwenden und die Zeit, die Sie benötigen, um sich mit der Umgebung, den Mechanismen und den verschiedenen Anwendungsfällen vertraut zu machen, auf ein Minimum reduzieren.

Im Allgemeinen bin ich der Meinung, dass Vue ist eher für Personen geeignet, die sich noch nicht mit Front-End-Bibliotheken beschäftigt haben. Sicherlich wird es Ihnen auf eine ermutigende Weise ermöglichen, in kurzer Zeit zufriedenstellende Ergebnisse zu erzielen.

Aber sagen wir es laut - die mangelnde Kenntnis der Sprache, in der wir bestimmte Tools verwenden, wird uns früher oder später schaden. Für einfache Dinge ist es ein vernachlässigbares Element, aber mit zunehmender Komplexität der erstellten Anwendungen wird es immer schwieriger, Anwendungen ohne gute Kenntnisse in folgenden Bereichen vernünftig zu erstellen JavaScript.

Ich beziehe mich nicht wirklich darauf, dass man in der Lage ist, einige anspruchsvolle Funktionen zu schreiben, denn dieser Teil kann z. B. von Anbietern weitgehend ersetzt werden. Ich beziehe mich auf einige häufige Fehler, die in der Sprache gemacht werden können, und darauf, dass man sich nicht bewusst ist, dass das falsche Verhalten nicht auf die Verwendung der Bibliothek, sondern auf die Verwendung der Sprache zurückzuführen ist. Der häufigste Fehler, der sich hier manifestiert, ist die so genannte Unveränderlichkeit - das heißt, die Kenntnis des Referenzmechanismus in JavaScript.

Ich kann nicht sagen, welche Bibliothek für Entwickler, die mit JavaScript mehr oder weniger vertraut sind, besser ist. Aber ich weiß eines - wenn Sie eine wirkliche Vorstellung davon haben wollen, wie die Entwicklung mit beiden Werkzeugen "von innen" aussieht - versuchen Sie, Anwendungen in jedem von ihnen zu schreiben. So können Sie sich ein Bild machen und sehen, welche Mechanismen Ihnen mehr zusagen und was für Sie die bessere Wahl ist.

Wie ich bereits erwähnt habe, werden beide Bibliotheken von ähnlichen Ökosystemen angetrieben und haben ähnliche Ansichten über die Entwicklung von Anwendungen mit kleinen Komponenten. Beiden Bibliotheken geht es gut - es gibt keine Anzeichen dafür, dass eine der beiden Bibliotheken in naher Zukunft verschwinden wird. Folglich werden die Stellenangebote in beiden Bibliotheken auf einem ähnlichen Niveau bleiben.

Die Schlussfolgerungen sind einfach: Verwenden Sie, was zu Ihnen passt; sammeln Sie Erfahrungen und werten Sie sie aus. Dies wird Ihnen helfen, einen rationalen Ansatz dafür zu entwickeln, ob es besser ist, die eine oder andere Bibliothek in einem bestimmten Projekt zu verwenden; versuchen Sie auch zu experimentieren - nichts lehrt so sehr wie die Fehler, die in der Vergangenheit gemacht wurden.

Beste Wahl für CTO

Es ist kein Geheimnis, dass es keinen goldenen Mittelweg gibt, der die beste Lösung für ein bestimmtes Projekt darstellt. Vor allem im Front-End-Bereich veralten die Tools, die zur Erstellung von Anwendungen verwendet werden, schnell und es ist oft schwer, sich in den neuesten Trends zurechtzufinden.

Die Wahl der Technologie ist jedoch nicht, oder sollte es zumindest nicht sein, eine Entscheidung darüber, was zu den aktuellen Trends passt. Stattdessen sollten wir sie auf bestimmte Erwartungen und Annahmen bezüglich der Anwendung, die wir entwickeln wollen, ausrichten. Jede der verglichenen Bibliotheken hat ihre Stärken und Schwächen, die es uns, abgestimmt auf den Anwendungsfall, ermöglichen werden, die sinnvollste Wahl zu treffen.

Eine interessante Option könnten Technologie-Zusammenfassungen großer Unternehmen sein, die oft ihre Anwendungsfälle beschreiben, wie die Entwicklung großer Anwendungen verlief oder verläuft und welche Fehler sie in der Vergangenheit gemacht haben. Vielleicht finden wir darin Fälle, die im Zusammenhang mit der Auswahl einer Bibliothek für ein bestimmtes Projekt besonders interessant sind.

Die Merkmale, die wir bei der Auswahl der richtigen Tools für die zu entwickelnde Anwendung berücksichtigen sollten, sind: die Dauer der Anwendungsentwicklung, die Einfachheit der Anwendungspflegedie Komplexität der Anwendung und die Erfahrung der Entwickler bei der Verwendung bestimmter Bibliotheken.

Entwickler sind diejenigen, die die meiste Zeit mit den von mir verglichenen Werkzeugen verbringen, und sie sind diejenigen, die Ihnen die besten Ratschläge geben und Ihnen helfen können, die beste Wahl im großen Durcheinander der Bibliotheken zu treffen. Während der Anwendungsentwicklung sehen Sie die verschiedenen Probleme, die sich direkt aus der Wahl der Technologie ergeben, und haben den besten Überblick darüber, welche Dinge die Verwendung eines bestimmten Tools für bestimmte Funktionen untergraben.

Wie ich bereits erwähnt habe, scheinen beide Bibliotheken nicht aus dem Internet zu verschwinden. MarktZumindest nicht in den nächsten paar Jahren. Anstatt Entscheidungen auf der Grundlage von Statistiken und Meinungen zu treffen
von verschiedenen Leuten aus dem Internet - vielleicht wäre es besser, einfach mit den Entwicklern zu sprechen.

Legen Sie ihnen dar, was von der Bewerbung erwartet wird, wie viel Zeit wir für die Lieferung haben, und ermöglichen Sie einen lockeren Meinungsaustausch darüber, was sie von den beiden Lösungen halten, bevor wir die endgültige Entscheidung treffen.

Schlussfolgerungen

Internetkriege sind in der Regel - oder vielleicht sogar in jedem Fall - sinnlos. Es wird immer Leute geben, die hartnäckig behaupten, dass ihre Wahl besser ist, ohne irgendwelche rationalen Argumente zur Bestätigung ihrer Entscheidung zu nennen.

Anstatt sich von bestimmten Entscheidungen blenden zu lassen, sollten wir uns auf die Analyse konzentrieren, versuchen, die richtigen Schlüsse zu ziehen und diese nutzen, um eine bestimmte Lösung anzupassen oder zu verwerfen.

Wie der Titel schon andeutet, habe ich nicht die Absicht, eine bestimmte Bibliothek als Heilmittel für jedes Leiden zu preisen. Stattdessen werden einige Hypothesen vorgestellt und die Stärken und Schwächen der beiden Bibliotheken aufgezeigt. Ich habe einige Ratschläge gegeben, worauf man bei der Wahl zwischen den beiden Bibliotheken achten sollte, um eine weise Entscheidung zu treffen und sich nicht von Trends oder zufälligen Personen aus dem Internet leiten zu lassen.

Jedes Werkzeug kann den Bedürfnissen des Projekts gut genug entsprechen. Keines von beiden wird in den nächsten Jahren schnell vom Markt verschwinden. Beide haben eine starke Gemeinschaft und sind ziemlich ausgereift, was uns zeigt, dass sie sich recht gut behaupten.

Die endgültige Entscheidung liegt in Ihren Händen. Wenn Sie jedoch Zweifel haben oder Ihren Fall mit The Codest besprechen möchten, können Sie uns gerne kontaktieren!

Lesen Sie mehr:

Warum Sie (wahrscheinlich) Typescript verwenden sollten

Wie kann man ein Projekt nicht durch schlechte Programmierpraktiken zerstören?

Strategien zum Abrufen von Daten in NextJS