Warum haben wir uns für Vue.js entschieden (und nicht für React)?

Vor kurzem hat das Qwintry-Team eine aktive Migration zu Vue.js in all unseren alten und neuen Projekten begonnen:

  • auf einem älteren Drupal-basierten System (qwintry.com)
  • in unserem neuen, komplett neu geschriebenen qwintry.com-Thread (Backend auf Yii2 / Node.js)
  • in unseren B2B-Systemen (unterstützt von Yii2) (logistics.qwintry.com)
  • in all unseren kleinen internen und öffentlichen Projekten (hauptsächlich mit PHP und Node.js im Backend)

Warum sich unsere Programmierer für Vue.js entschieden haben, sagt der Entwicklungsleiter bei Qwintry LLC . Anton Sidashin ➔

Kurz über uns: Das Qwintry- Projekt wird von einer halben Million Kunden auf der ganzen Welt genutzt, wir haben zwei Lager (in den USA und in Deutschland), die unsere eigene Cloud-Software verwenden, und wir sind einer der größten Postversender in den USA in Bezug auf den Besucher- und Abflugverkehr. Wir helfen Menschen, Waren in US-Online-Shops zu kaufen und ihre Pakete in unserem persönlichen Konto zu verwalten, und können beim internationalen Versand erheblich sparen. Wir nutzen unsere eigene IT-Plattform und Lieferketten , um eine qualitativ hochwertige internationale Lieferung zu einem guten Preis zu gewährleisten.


Unser Paket vor der Tür des Kunden - aus Kundenbewertungen

Qwintry hat eine ziemlich große Codebasis, die hauptsächlich aus PHP und JS besteht (+ Swift und Java für mobile Anwendungen).

Wir haben uns für Vue.js entschieden, nachdem wir eine Testanwendung mit identischer Funktionalität - unseren Taschenrechner - für React, Vue.js und Angular2 erstellt hatten.
 

React.js


Die Popularität von React ist in den letzten ein oder zwei Jahren sprunghaft angestiegen, und jetzt ist es vielleicht die Standardauswahl für einen JS-Entwickler, der etwas Komplizierteres im Frontend schreiben möchte als einen dreizeiligen Code-Absatz.

Wir haben mehrere SPA- und dynamische Widgets auf React gesehen und React Native (für iOS) und Redux getestet. Ich denke, React war ein großer Schritt für die JS-Welt in Bezug auf das staatliche Bewusstsein und hat vielen Menschen gezeigt, was echte funktionale Programmierung auf gute, pragmatische Weise ist. Ich denke auch, dass React Native großartig ist - es verändert buchstäblich die gesamte Landschaft der mobilen Entwicklung.

Nachteile für mich reagieren:

Oft dominieren Sauberkeit, Immunität und Ideologie den pragmatischen Ansatz.


Versteh mich nicht falsch. Ich schätze die Reinheit und Einfachheit des render () -Ansatzes - zweifellos ist dies eine großartige Idee, die in der realen Entwicklung funktioniert. Ich spreche über andere Dinge.

Ich denke, dieses Maß an Genauigkeit und Sauberkeit kann nützlich sein, wenn Sie 1.000 Entwickler in Ihrem Unternehmen haben - ungefähr zur gleichen Zeit, zu der Sie sich entscheiden, Ihre eigene Syntax zu entwickeln, um Ihren gesamten PHP-Code in statische Typen zu übersetzen . Oder wenn Sie ein Haskell-Entwickler sind, der sich entschlossen hat, JS zu verstehen. Die meisten Unternehmen haben jedoch weit weniger Entwickler, kleinere Budgets und Ziele, die sich von den Facebook-Zielen unterscheiden. Darauf werde ich noch etwas näher eingehen.

JSX ist scheiße


Warte eine Sekunde! Ich weiß! Dies ist "nur reines Javascript mit spezieller Syntax". Unsere Leute, die ein Design in einer Skizze und einem Photoshop zeichnen und es dann in HTML konvertieren, die feste Fristen haben und die dieses Formular gerade erstellen und es in eine Reihe von Divs einwickeln - im Moment - die Trommel ist sauber und „einfach“. ES6. Das Anwenden von Design auf React-Komponenten ist kein Brunnen, da JSX nicht lesbar ist. Die Unfähigkeit, die gute alte IF in einen HTML-Codeblock einzufügen, ist schlecht, und bitte vertrauen Sie nicht React-Fans, die sagen, dass "if () das letzte Jahrhundert ist und jetzt alle normalen Programmierer ternäre Operatoren verwenden". Ich versichere Ihnen: JSX ist immer noch ein Durcheinander von HTML und JS, sobald Sie es lesen und bearbeiten, auch wenn es später zu reinem JS kompiliert wird.

<ul>
       {items.map(item =>
         <li key={item.id}>{item.name}</li>
       )}
</ul>

Viele Entwickler denken (und ich stimme ihnen seit einiger Zeit zu), dass solche Syntaxbeschränkungen sie stärker machen und ihnen helfen, modulareren Code zu schreiben, da JSX-Einschränkungen (out of the box) Sie dazu zwingen, Codeteile in kleine Hilfsfunktionen einzufügen und sie darin zu verwenden render () -Funktionen, wie dies und viele andere vorgeschlagen haben:

stackoverflow.com/a/38231866/1132016

JSX zwingt Sie auch dazu, Komponenten in 15 Zeilen HTML in 3 Komponenten aufzuteilen , 5 Zeilen HTML in jeder. Denken Sie nicht, dass dieser Ansatz Sie zu einem besseren Entwickler macht.

Hier ist das Ding:

Wenn Sie eine relativ komplexe Komponente schreiben - die Sie wahrscheinlich morgen nicht auf einem öffentlichen Repräsentanten auf GitHub veröffentlichen werden, um sie auf HackerNews zu demonstrieren -, zieht Sie dieser Ansatz, Komponenten aufgrund von JSX-Einschränkungen in super dumme Komponenten zu zerlegen, immer aus dem Stream heraus Damit lösen Sie ein echtes Geschäftsproblem. Nein, ich sage nicht, dass die Idee von Bruchteilen schlecht ist oder nicht funktioniert. Sie sollten sich klar darüber im Klaren sein, dass Sie die Funktionalität in ihre Komponenten aufteilen müssen, um Ihren Code in einem kontrollierten Zustand zu halten. Sie sollten dies jedoch nur tun, wenn Sie der Meinung sind, dass diese bestimmte logische Entität in Ihrem Code besser ist, eine separate Komponente mit eigenen Requisiten zu sein - und nichtfür jeweils zwei oder drei Bedingungen, die mit dem ternären Operator geschrieben wurden! Jedes Mal, wenn Sie hier und da eine neue Komponente erstellen, kostet Sie dies einen ganz bestimmten Aufwand und stört Ihren Fluss.Da Sie vom Denken des Architekten (wenn Sie sich bereits an den aktuellen Status des Komponentenmodells erinnern und hier und da nur HTML hinzufügen müssen, damit die Funktionalität funktioniert) zum Denken des Managers wechseln müssen, müssen Sie eine separate Datei für die Komponente erstellen und über die Requisiten dieser neuen Komponente nachdenken wie sie den Status abbilden, wie Sie Rückrufe weiterleiten usw. Infolgedessen wird die Geschwindigkeit beim Schreiben von Code verringert, da Sie sich um die vorzeitige Modularität von Komponenten kümmern müssen, die Sie wahrscheinlich nicht benötigen würden, wenn die JSX-Syntax flexibler wäre. Meiner Meinung nach ist vorzeitige Modularität der vorzeitigen Optimierung sehr ähnlich. Für mich und unser Team ist die Lesbarkeit von Code wichtig, aber es ist immer noch sehr wichtig, Spaß am Schreiben von Code zu haben. Es ist nicht coolWenn für eine einfache Form des Taschenrechners 6 Komponenten mit jeweils eigenen Requisiten erstellt werden müssen.

Oft ist eine solche Hypermodularität auch im Hinblick auf die Wartung, Änderung oder Anwendung eines neuen Designs schlecht, da Sie zum Aktualisieren des HTML-Codes im Widget über mehrere Dateien / Funktionen springen und jedes kleine Stück HTML separat überprüfen müssen.

Auch hier schlage ich nicht vor, Monolithen zu schreiben. Ich schlage vor, für die tägliche Programmierung Komponenten anstelle von Mikrokomponenten zu verwenden. Es geht um Gleichgewicht und gesunden Menschenverstand.

Wenn Sie mit Formularen und Redux arbeiten, können Sie den ganzen Tag drucken


Reagieren - es geht um Sauberkeit und Einbahnstraße, erinnerst du dich? Aus diesem Grund wurde LinkedStateMixin zu einer Persona non grata.und jetzt müssen Sie 10 Funktionen schreiben, um Eingaben von 10 Formularfeldern zu erhalten. Nein, Sie können natürlich eine Funktion schreiben, die e.target überprüft, aber am Ende gibt es einen solchen Baum von Bedingungen mit der Normalisierung der Daten, die aus dem Formular kommen, das Sie weinen möchten. deshalb macht das niemand. 80% dieser Funktionen enthalten eine Zeile mit this.setState () oder einen Aufruf der Redux-Aktion. (Dann müssen Sie wahrscheinlich 10 weitere Konstanten erstellen - eine für jede Aktion). Ich denke, dieser Ansatz wäre akzeptabel, wenn Sie den gesamten Code generieren könnten, indem Sie nur darüber nachdenken ... Aber ich kenne keinen IDE-Editor, der das Schreiben eines solchen Boilerplates erheblich vereinfachen könnte. Warum sollten Sie so viel drucken? Weil die großen Leute entschieden haben, dass die bidirektionale Bindung in großen Unternehmensanwendungen gefährlich ist.Ich kann bestätigen, dass die bidirektionale Bindung manchmal nicht so einfach und nicht so lesbar ist, aber die meisten dieser Befürchtungen hängen mit dem allgemeinen Leiden von Menschen aus der ersten Version von Angular zusammen, bei der die bidirektionale Bindung möglicherweise nicht die beste ist. Und doch ... war dies wahrscheinlich nicht die größte Fehleinschätzung, selbst in Angular. Schauen Sie sich meinen Schnelleditor an, den ich kürzlich mit Vue.js für unsere Drupal-Plattform satt habe (ich entschuldige mich im Voraus für das Design, dies ist das UI-Backend für unsere Bediener, und die Designer sind damit beschäftigt, Schnittstellen für unsere Kunden zu erstellen, sodass diese Funktionalität darauf wartet, dass sie verfügbar ist Stunden, um schön zu werden):war wahrscheinlich nicht die größte Fehleinschätzung selbst in Angular. Schauen Sie sich meinen Schnelleditor an, den ich kürzlich mit Vue.js für unsere Drupal-Plattform satt habe (ich entschuldige mich im Voraus für das Design, dies ist das UI-Backend für unsere Bediener, und die Designer sind damit beschäftigt, Schnittstellen für unsere Kunden zu erstellen, sodass diese Funktionalität darauf wartet, dass sie verfügbar ist Stunden, um schön zu werden):war wahrscheinlich nicht die größte Fehleinschätzung selbst in Angular. Schauen Sie sich meinen Schnelleditor an, den ich kürzlich mit Vue.js für unsere Drupal-Plattform satt habe (ich entschuldige mich im Voraus für das Design, dies ist das UI-Backend für unsere Bediener, und die Designer sind damit beschäftigt, Schnittstellen für unsere Kunden zu erstellen, sodass diese Funktionalität darauf wartet, dass sie verfügbar ist Stunden, um schön zu werden):



Ich kann den Code aus offensichtlichen Gründen nicht anzeigen, aber das Schreiben in Vue war sehr schön und der Code war sehr gut lesbar. Und ich weiß mit Sicherheit, dass ich nicht vor Glück springen würde, wenn ich für jedes Feld der Form eine eigene Funktion schreiben würde, wie in React.

Redux ist auch ausführlich und erfordert viel Schreiben . Und im Internet ist es leicht, Aussagen von Entwicklern zu finden, die Mobx beschuldigen, React in Angular umzuwandeln, nur weil Mobx die bidirektionale Datenbindung verwendet (siehe Abschnitt 1 zu „Sauberkeit“). Es scheint, dass viele kluge Leute die „Sauberkeit“ ihres Codes mehr schätzen als die schnell und gut gelöste Geschäftsaufgabe (was im Prinzip normal ist, wenn Sie keine Fristen haben).

Gleichzeitig halte ich das Flux / Redux-Konzept selbst für sehr cool. Redux ist einfach und bietet ein unglaubliches Maß an Kontrolle über den Status der Anwendung und trennt den Status von reinen Schnittstellenteilen - dies erleichtert sofort das Schreiben von Tests. Aber leider ist all dies durch eine sehr große Menge an Kritzeleien gegeben. Ja, das Debuggen von Zeitreisen als Nebeneffekt ist fantastisch. Aber ich persönlich bin bereit, es für das Schreiben von Hochgeschwindigkeitscode zu opfern und darüber nachzudenken, ob Sie Zeitreisen benötigen, wenn Sie für jedes Feld in der Form eine Konstante erstellen müssen.

Übermäßiger Werkzeugüberschuss


React arbeitet mit dem ursprünglichen Bereich auf Babel. Sie werden keine echte React-Anwendung ohne eine anständige Reihe von npm-Paketen erstellen, beginnend mit dem ES5-Compiler. Eine einfache Anwendung, die auf dem offiziellen Start-Build in der Last basiert, empfängt ungefähr 75 MB JS-Code in node_modules. Dies ist keine kritische Sache und bezieht sich mehr auf die JS-Welt als auf React, fügt aber dennoch Frustration und Ärger hinzu.

Mein React-Urteil - ermöglicht es Ihnen, großartigen, lesbaren Code zu schreiben, aber viel zu schreiben macht keinen Spaß. Nun, Probleme für Layoutdesigner, die ES6 nicht in HTML besitzen und nicht besitzen möchten, verschwinden nicht.

Winkel 1: Zu viel Freiheit ist auch schlecht


Winkel 1 ist ein guter Rahmen für seine Zeit und befindet sich in der gegenüberliegenden Ecke (von React) einer imaginären JS-Karte zur Sauberkeit und Lesbarkeit des Codes. Mit Angular können Sie schnell beginnen, die ersten 1k Codezeilen schreiben und dann praktisch Code schreiben, der nicht sehr gut funktioniert. Es ist wahrscheinlich, dass Sie sich in Direktiven, Bereichen und bidirektionalen Datenströmen verlieren, die alle Ebenen Ihrer Anwendung durchdringen. Dies ist der letzte Akkord des Schwanengesangs Ihres Codes, den frisch eingestellte Entwickler nicht einmal berühren möchten, weil etwas kaputt geht. Warum passiert das? Angular.js wurde 2009 erstellt, als die Welt der Front-End-Entwicklung recht einfach aussah und niemand über eine gute Kontrolle über den Status der Anwendung nachdachte. Sie sollten den Autoren keine Vorwürfe machen - sie haben nur mit einigen neuen Chips einen Konkurrenten zu Backbone gemacht und wollten weniger drucken (und sie haben alles getan, eine weitere Frage zu welchem ​​Preis).

Angular2


Erstellen Sie einfach eine Hallo-Welt-Anwendung und sehen Sie sich die Anzahl der Dateien an, die in der Rübe landen. Ich werde Typescript verwenden müssen (und ich bin nicht 100% sicher, was ich jeden Tag tun möchte - nein, Leute, statisches Tippen in JS ist kein Allheilmittel, aber ich muss noch einmal gute Gedanken von Eric Eliott zu diesem Thema drucken) und Compiler, um loszulegen. Dies war genug für uns, um Angular2 auf bessere Zeiten zu verschieben. Ich bin faul und für mich ist es zu viel Boilerplate, bevor Sie anfangen, echten Code zu schreiben. Meiner Meinung nach versuchen die Autoren von Angular 2, ein ideales System für ein Unternehmen aufzubauen, das React besiegt, anstatt ein Framework zu erstellen, das geschäftliche Probleme für einen normalen Durchschnittsbenutzer löst. Vielleicht irre ich mich und meine Meinung kann sich ändern - ich habe nicht viel Erfahrung mit Angular2, wir haben am Ende nur eine Testrechner-Anwendung erstellt. Eine wunderbare Vergleichsseite auf Vue.js nennt Angular2 ein gutes System, das viele Ideen mit Vue.js gemeinsam hat.

Vue.js


Vue.js ist eine Sache, auf die ich lange gewartet habe (im Folgenden werde ich über Vue.js 2 sprechen, das im Vergleich zur ersten Version von Vue viele Verbesserungen erhalten hat, und dies ist die aktuelle stabile Version des Systems). Für mich ist Vue.js in Bezug auf Eleganz und Prägnanz sowie die Konzentration auf Lösungen für reale Probleme der größte Durchbruch in JS seit dem Tag, an dem ich 2007 von Jquery getroffen wurde. Wenn Sie sich die Grafiken der Popularität von Vue.j ansehen, dann Beachten Sie, dass er dieses Jahr nicht nur mir gefiel:



On Vue Github - Top 1 JS-Projekt von 2016 (unter Rüben mit Quellcode).

Aufgrund der Beliebtheit in Google Trends übertraf Vue.js im Jahr 2016 React deutlich (dies ist natürlich die Durchschnittstemperatur in einem sehr großen Krankenhaus und hängt stark von der formulierten Anfrage ab - ein sehr indirektes Zeichen der Beliebtheit).
https://www.google.com/trends/explore?q=vue.js,react.js,angular.js

Vue.js ist eines der am schnellsten wachsenden (in Bezug auf die Community oder zumindest die Anzahl der Likes im Github und Benutzer von Vue Dev Tools in Chrome) JS-Lösungen im Jahr 2016, und ich bin sicher, dass dies nicht nur eine weitere modische Bibliothek für Hipster ist, die alle 3 Monate zu einem neuen JS-Framework wechseln, oder dass die Arbeit der PR-Abteilung groß ist Firma.

Laravel hat Vue.js zum Kernel hinzugefügt, und dies ist eine ernsthafte Behauptung.

Vorteile von Vue.js


Vue.js sorgt für ein hervorragendes Gleichgewicht zwischen Lesbarkeit, Wartbarkeit des Codes und dem Vergnügen, diesen Code zu schreiben. Diese Waage befindet sich in ungefähr gleichem Abstand zwischen React und Angular 1, und wenn Sie sich die Richtlinie vue.js ansehen, werden Sie sofort feststellen, wie viele nützliche Ideen er von diesen Systemen entlehnt hat.

In React Vue.js habe ich den Komponentenansatz, Requisiten, einen Einweg-Datenstrom für die Komponentenhierarchie, die Leistung, die Fähigkeit zum Rendern im Backend und die Bedeutung einer ordnungsgemäßen Statusverwaltung verwendet. Vue.js hat Angular1 ähnliche Vorlagen mit guter Syntax und bidirektionaler Bindung entnommen, aber nur dort, wo Sie es wirklich brauchen, und Sie können nicht sofort auf Ihr Bein schießen (innerhalb einer Komponente). Es ist sehr einfach, Code unter Vue.js zu schreiben - das habe ich in unserem Team gesehen. Für Vue.js sind keine Standard-Compiler erforderlich. Daher ist es sehr einfach, Vue.js zu Ihrer alten Codebasis hinzuzufügen und mit dem Kopieren von jQuery-Hash in lesbaren Code zu beginnen.

Die richtige Menge an Magie


Vue.js ist sowohl im Hinblick auf den HTML-zentrierten Ansatz als auch aus Sicht der JS-Entwickler sehr einfach zu bedienen: Sie können ziemlich komplexe Vorlagen erstellen, ohne den Fokus auf die Geschäftsaufgabe zu verlieren, und die resultierende HTML-Vorlage wird normalerweise auch dann gut gelesen, wenn er ist schon groß Zu diesem Zeitpunkt haben Sie in der Regel gute Fortschritte bei der Lösung des Geschäftsproblems erzielt, und Sie möchten möglicherweise die Vorlagen neu organisieren und in kleinere Komponenten aufteilen. In diesem Moment sehen Sie das gesamte "Bild" Ihrer Anwendung viel besser als zu Beginn. Meine Erfahrung zeigt, dass sich dies erheblich von dem Ansatz unterscheidet, den React-Programmierer normalerweise verwenden, und dieser Unterschied spart Programmierern, die Vue.js verwenden, viel Zeit und Mühe. In React sind Sie dazu gezwungenTeilen Sie Komponenten gleich zum Zeitpunkt des Schreibens der ersten „Entwurfs“ -Version des Codes in Mikrokomponenten und Mikrofunktionen auf. Andernfalls werden Sie buchstäblich in einem Durcheinander von geschweiften Klammern und HTML zwischen ihnen begraben. In React verbringe ich viel Zeit damit, Requisiten zu polieren und superkleine Komponenten (die natürlich nie wiederverwendet werden) immer wieder neu zu gestalten, da ich sie nicht so deutlich sehe, wenn ich mitten im Prozess plötzlich die Logik des Codes ändern muss.

Formulare


Die Arbeit mit HTML-Formularen in Vue.js ist eine Freude. Hier hilft die doppelseitige Bindung wirklich. Selbst in schwierigen Fällen gibt es kein Problem, obwohl Beobachter auf den ersten Blick Angular 1 ähneln können. Ein Einweg-Datenfluss steht Ihnen immer zur Verfügung, wenn Sie Komponenten aufteilen.

Technologie


Wenn Sie kompilieren möchten, sind Flusen, PostCSS und ES6 kein Problem . Einzeldateikomponenten scheinen die Hauptmethode zum Schreiben öffentlicher Komponenten in Vue.js 2 zu werden. Übrigens ist die Idee, dass Scoped CSS sofort in Einzeldateikomponenten funktioniert, sehr gut und kann die Notwendigkeit strenger CSS-Namensregeln verringern Klassen und Technologien wie BEM .

Staatsverwaltung


Vue.js verfügt über eine relativ einfache und nützliche Statusverwaltung mithilfe von data () - und props () -Methoden - sie funktionieren in der realen Entwicklung einwandfrei. Wenn die Seele etwas mehr für das Staatsmanagement verlangt, gibt es Vuex (das meiner Meinung nach Mobx in React ähnelt - der Staat ist dort veränderlich). Ich denke, ein guter Prozentsatz der Vue.js-Anwendungen benötigt keine Statusverwaltung über Vuex, aber es ist schön, eine Alternative zu haben.

Leistung


Das Thema ist ganzheitlich, im Allgemeinen reagieren beide und vue.js sind schnell. Trotzdem ist vue.js anscheinend im Durchschnitt spürbar schneller.

Ein wunderbarer Link aus den Kommentaren zum TodoMVC-Lauf mit Messungen:
eigenmethod.imtqy.com/mol/app/bench/#bench=%2Ftodomvc%2Fbenchmark%2F#sample=angular2~angularjs~mol~react~vue~vanillajs#sort=fill#

Und hier gibt es detailliertere Berichte (allerdings von der interessierten Partei) .

Ein weiterer detaillierter und verständlicher Benchmark-Vergleich:
stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html

Nachteile VueJS


Laufzeitvorlagenfehler


Größte: unangenehme Laufzeitfehler in Vorlagen. Opfer für das bequeme Schreiben von Code. Dies ist Angular 1 sehr ähnlich. Vue.js kann viele nützliche Warnungen für JS-Code generieren: Wenn Sie beispielsweise versuchen, die Requisiten zu mutieren oder die data () -Methode falsch zu verwenden, ist der positive Einfluss von React hier sehr deutlich. Aber Laufzeitvorlagenfehler sind immer noch die Schwäche von Vue.js. Ausnahmen-Stack-Traces sind häufig nutzlos und führen zu internen Methoden von Vue.j. In diesem Fall ist JSX in dieser Klasse von Fehlern und Debugging oft angenehmer: Aufgrund der Kompilierung „von JS nach JS“ führt das Klicken auf einen Fehler in der Browserkonsole normalerweise genau dazu, wo dieser Fehler im Code aufgetreten ist.

Bibliotheken


Die Infrastruktur von Vue.j ist noch recht jung. Tatsächlich können stabile Komponenten aus der Community an den Fingern gezählt werden, und viele davon wurden für Vue.js 1 erstellt, und es ist für Anfänger oft nicht so einfach herauszufinden, für welche Version von Vue.js eine bestimmte Bibliothek erstellt wurde. Dieses Problem wird durch die Tatsache gemildert, dass Sie in Vue.js coole Dinge tun können, ohne dass Bibliotheken von Drittanbietern benötigt werden. Sie benötigen wahrscheinlich nur eine Bibliothek für Ajax-Anfragen ( vue-resource wäre eine gute Wahl, wenn Sie sich nicht für isomorphe Anwendungen interessieren, ansonsten Axios ) und wahrscheinlich einen Vue-Router, der als Bibliothek mit guter Unterstützung von Vue.js angesehen wird.

Nicht englischsprachige Community


Chinesische Kommentare im Code der meisten öffentlichen Repositories, und das ist nicht überraschend: Vue.js wird in China zu einer sehr beliebten Lösung (Vue.js spricht Chinesisch)

Ein-Personen-Projekt.


Eher ein potenzielles Problem als ein echtes, aber manchmal möchten Sie auf Nummer sicher gehen. Evan You ist der Typ, der Vue gebaut hat, nachdem er an Google und Meteor gearbeitet hat. Laravel ist natürlich auch ein Einzelprojekt, aber er ist trotzdem sehr erfolgreich, oder?

Vue.js in Drupal


Haftungsausschluss: Wir planen nicht, Drupal 8 bald in Qwintry zu verwenden, da wir auf modernere, schnellere und einfachere PHP- und Node.js-Frameworks umsteigen, aber unser Legacy-Code ist Drupal. Da die Hauptseite qwintry.com auf Drupal läuft, war es für uns sehr wichtig, Vue.js hier im Kampf zu überprüfen. Ehrlich gesagt bin ich nicht stolz auf viele Abschnitte unseres Codes in diesem Repository. Wir versuchen, nicht an prominente Stellen zu gelangen, während es zumindest irgendwie funktioniert, aber dieses alte Projekt mit einer Geschichte funktioniert einigermaßen gut und generiert unser Einkommen. Deshalb respektieren wir es. verbessern Sie es, und viele neue Funktionen kommen hier heraus. Hier ist eine Liste der Dinge, die ich in Drupal auf Vue aufgebaut habe: Ein schnelles Formular für den Entitätseditor, das das Generieren von Kundenrechnungen sowie das schnelle Bearbeiten von Produktlisten umfasst.Hier musste eine einfache JSON-API zum Laden und Speichern von Entitäten erstellt werden - nichts Besonderes, nur ein paar Rückrufe. Zwei Dashboards über die Saas-REST-API der Produkte, die wir für unser Support-Team verwenden, sodass die Bediener nicht die Administrationsseiten einzelner Websites durchsuchen müssen, um Informationen zu einem bestimmten Kunden zu überprüfen. All dies ist jetzt direkt in das Kundenprofil auf unserer Website integriert. Ich weiß, dass viele Backend-Entwickler im Jahr 2010 immer noch mit dem Ajax Drupal-Kernelsystem feststecken. Ich weiß genau, wie kompliziert Drupal-Code sein kann, wenn Sie versuchen, mithilfe der Ajax-Funktionalität aus dem Kernel eine komplexe mehrstufige Form zu erstellen. Es ist fast unmöglich, diesen Code später zu verwalten. Ja, ich spreche von Ihnen, ctools_wizard_multistep_form () und Ihnen,über die Saas REST-API der Produkte, die wir für unser Support-Team verwenden, damit die Betreiber nicht die Administrationsseiten einzelner Websites durchsuchen müssen, um Informationen zu einem bestimmten Kunden zu überprüfen. All dies ist jetzt direkt in das Kundenprofil auf unserer Website integriert. Ich weiß, dass viele Backend-Entwickler im Jahr 2010 immer noch mit dem Ajax Drupal-Kernelsystem feststecken. Ich weiß genau, wie kompliziert Drupal-Code sein kann, wenn Sie versuchen, mithilfe der Ajax-Funktionalität aus dem Kernel eine komplexe mehrstufige Form zu erstellen. Es ist fast unmöglich, diesen Code später zu verwalten. Ja, ich spreche von Ihnen, ctools_wizard_multistep_form () und Ihnen,über die Saas REST-API der Produkte, die wir für unser Support-Team verwenden, damit die Betreiber nicht die Administrationsseiten einzelner Websites durchsuchen müssen, um Informationen zu einem bestimmten Kunden zu überprüfen. All dies ist jetzt direkt in das Kundenprofil auf unserer Website integriert. Ich weiß, dass viele Backend-Entwickler im Jahr 2010 immer noch mit dem Ajax Drupal-Kernelsystem feststecken. Ich weiß genau, wie kompliziert Drupal-Code sein kann, wenn Sie versuchen, mithilfe der Ajax-Funktionalität aus dem Kernel eine komplexe mehrstufige Form zu erstellen. Es ist fast unmöglich, diesen Code später zu verwalten. Ja, ich spreche von Ihnen, ctools_wizard_multistep_form () und Ihnen,All dies ist jetzt direkt in das Kundenprofil auf unserer Website integriert. Ich weiß, dass viele Backend-Entwickler im Jahr 2010 immer noch mit dem Ajax Drupal-Kernelsystem feststecken. Ich weiß genau, wie kompliziert Drupal-Code sein kann, wenn Sie versuchen, mithilfe der Ajax-Funktionalität aus dem Kernel eine komplexe mehrstufige Form zu erstellen. Es ist fast unmöglich, diesen Code später zu verwalten. Ja, ich spreche von Ihnen, ctools_wizard_multistep_form () und Ihnen,All dies ist jetzt direkt in das Kundenprofil auf unserer Website integriert. Ich weiß, dass viele Backend-Entwickler im Jahr 2010 immer noch mit dem Ajax Drupal-Kernelsystem feststecken. Ich weiß genau, wie kompliziert Drupal-Code sein kann, wenn Sie versuchen, mithilfe der Ajax-Funktionalität aus dem Kernel eine komplexe mehrstufige Form zu erstellen. Es ist fast unmöglich, diesen Code später zu verwalten. Ja, ich spreche von Ihnen, ctools_wizard_multistep_form () und Ihnen,ajax_render !

Gleichzeitig werden diese Entwickler von den Anforderungen an moderne Schnittstellen vorangetrieben, aber die Komplexität der modernen JS-Infrastruktur treibt sie in eine Depression. Ja, ich erkenne mich vor einem Jahr wieder. Also Leute, hört mir zu! Sie werden keinen besseren Moment und Weg finden, um Ihre Schnittstellen zu verbessern, als jetzt Vue.js zu nehmen, es in sites / all / library einzufügen, es mit drupal_add_js () zur Vorlage hinzuzufügen und mit dem Schreiben von Code zu beginnen. Sie werden schockiert sein, wie viel einfacher es ist, ein System zu warten, in dem Drupal nur für den generierten JSON verantwortlich ist, wenn der gesamte Clientcode, einschließlich der Formulare, vollständig von Vue.js unterstützt wird.

Vue.js in Yii2


Unterhaltsame Tatsache: Yii wurde vom chinesischsprachigen Entwickler Qiang Xue erstellt. Man kann Yii + Vue.js also nicht nur als Stapel bezeichnen, dessen Name beim ersten Versuch kaum auszusprechen ist, sondern auch als Stapel mit chinesischem Erbe (auf gute Weise). Für die neue Version von Qwintry.com (noch nicht veröffentlicht) haben wir uns für Yii2 entschieden, das meiner Meinung nach eines der besten und schnellsten PHP-Frameworks ist. Es ist definitiv nicht so beliebt wie Laravel, das die Führung in der PHP-Welt übernommen hat, aber der Yii2-Stack ist für uns ganz in Ordnung.(Obwohl wir uns von Zeit zu Zeit mit Laravel befassen, nutzen die Entwickler dort und natürlich eine ausgereiftere Infrastruktur in Bezug auf Bibliotheken). Wir reduzieren schrittweise die Menge an HTML, die Yii2 und PHP generieren, und konzentrieren uns mehr auf die REST-API, die JSON für die Clientseite generiert und auf Vue.js / Swift / Java ausgeführt wird. Der API-First-Ansatz wird für die meisten unserer Active Record-Modelle im Projekt verwendet. Hier nehmen wir die API bereits ernst und deshalb verbringen wir viel Zeit mit guter API-Dokumentation, auch wenn diese API nicht öffentlich ist. In den Codeabschnitten, in denen der HTML-Teil auf PHP-Ebene generiert wird, verwenden wir unsere eigenen Lösungen und unser Webpack zum Bündeln und bequemen Bereitstellen von Yii2-Widgets, die wiederum Vue-Einzeldateikomponenten verwenden. Mit PHP7 und dem neuesten MySQL unterscheidet sich die Antwortzeit unseres Yii2-JSON-Backends nicht wesentlich von der von Node.js Backends (ich spreche von einer Reaktionsgeschwindigkeit in der Größenordnung von 15 bis 20 ms), das sind ehrlich gesagt keine kosmischen Zahlen, aber dies ist mehr als genug für unsere Bedürfnisse, und vor allem ist es 10 bis 20 Mal schneller als das, was es ausgeben kann unsere alte Drupal Seite. Gleichzeitig ist dies ein gutes altes (und vielleicht langweiliges) PHP mit der ganzen Stärke der Komponistenbibliotheken und einer stabilen Codebasis. Die Reaktionsfähigkeit der auf Yii2 & Vue.js aufgebauten Schnittstellen ist sehr akzeptabel, und auch unter dem Gesichtspunkt der Lesbarkeit des Codes ist hier alles in Ordnung.Die Reaktionsfähigkeit der auf Yii2 & Vue.js aufgebauten Schnittstellen ist sehr akzeptabel, und auch unter dem Gesichtspunkt der Lesbarkeit des Codes ist hier alles in Ordnung.Die Reaktionsfähigkeit der auf Yii2 & Vue.js aufgebauten Schnittstellen ist sehr akzeptabel, und auch unter dem Gesichtspunkt der Lesbarkeit des Codes ist hier alles in Ordnung.

Wir verwenden Vue.js auch in einer Reihe von internen und externen Projekten, in denen das Backend auf Node.js ausgeführt wird. Ich werde dem oben Gesagten nichts Neues hinzufügen, alles funktioniert einwandfrei.

Fazit


Wir schreiben seit ungefähr 4 Monaten jeden Tag Vue.js Code in verschiedenen Projekten und die Ergebnisse sind beeindruckend. 4 Monate sind nichts in der Backend-Welt, aber für die JS-Welt ist dies eine anständige Zeit, in der fünf Frameworks geboren werden und sterben :) Mal sehen, was als nächstes passiert. Ich denke, dass Vue.js in den nächsten 16 bis 24 Monaten die Hauptlösung für JS sein wird, wenn Evan You die richtigen Schritte unternimmt, zumindest unter den Back-End- und kleinen Front-End-Teams. Der React-Stack wird 2017 zum Mainstream, insbesondere wenn React Native im gleichen Tempo wie jetzt weiter wächst und sich verbessert.

UPD: Dieser Artikel traf die Top-Hacker News, und es folgte eine nützliche Diskussion (250+ Kommentare): news.ycombinator.com/item?id=13151317

In Top-Reddit WebDev wir besuchten, auch 60+ Kommentare hier. Lustige Kommentar-Meinung zu Angular2 von dort:
Die gesamte Google-Dokumentation ähnelt dem Lesen von Microsoft-Dokumenten aus den frühen 2000er Jahren.
"Das Einrichten eines Angular-Projekts ist ein Kinderspiel! Stellen Sie einfach sicher, dass der zustandslose Referenzprototyp-Mutator vom Legacy-Objekt des Basisspeicherladers erbt, das den MODOK-Dienstanbieter implementiert (nicht Teil des Kerns: siehe hier für ebenso unlesbare Details). Sie können dann Ihren Angular-Kernel kompilieren und dabei vorsichtig sein, Webpack 2.3.9 zu verwenden (Hinweis: nicht 2.3.8, wie im Lieferumfang des Repositorys enthalten). Dies ist alles, was Sie wissen müssen, um mit einem großartigen Angular-Projekt zu beginnen. Angular: Die Entwicklung einfach und macht wieder Spaß! “

Fragen von Lesern:


JSX ist cool und korrekt, aber Sie sind nicht sehr! Wenn Sie wirklich Bedingungen wollen - programmieren Sie Ihre If-Komponente, das sind drei Zeilen!

Es ist unangenehm, ein Framework zu wählen und dann solche Dinge gegen ihn zu tun. Jeder neue Entwickler, der zum Projekt kommt, wird Sie nach solchen Entscheidungen fragen, und in den Komponenten anderer Leute werden Ihre Augen immer über die Ternarität stolpern.
Wenn die Komponente "Stirn" geschrieben wird, treten außerdem Probleme auf, da die internen Komponenten immer ausgeführt werden. Es gibt jedoch interessantere Lösungen: github.com/AlexGilleran/jsx-control-statements

Was schlagen Sie also vor, Liebes, jetzt müssen Sie React dringend löschen und alles in Vue.js umschreiben?

Nein, nein! React ist ein ausgezeichnetes Framework, mit dem Sie lesbaren und unterstützten Code schreiben können, und es wurde bereits eine große Anzahl hochwertiger Bibliotheken dafür geschrieben (und die Mikrokomponenten und Einschränkungen von JSX, die ich oben „gescholten“ habe, spielen hier eine positive Rolle, für öffentliche Bibliotheken ist dies eine Rolle bereits oft gerechtfertigt), die für keine andere JS-Lösung gelten. Wenn Sie und Ihr Team mit allem in JSX zufrieden sind und Sie nicht viel tippen, macht es vielleicht keinen Sinn, zu Vue.js zu wechseln, ist das Spiel einfach nicht die Kerze wert. Viele JS-Liebhaber haben es in letzter Zeit geliebt, von einem Framework zu einem Framework zu springen. Missbrauche es nicht, meiner Meinung nach ist es besser, diese Zeit für etwas Interessanteres zu verwenden, das die Benutzer deines Projekts bemerken werden.

Wenn Sie sich jedoch aufgrund umfangreicher Tools und anderer Schwierigkeiten nicht dazu bringen konnten, React zu verwenden, und Ihr Code auf verschwommenes jQuery- oder Backbone-Chaos stößt, kann Vue.js eine großartige Option sein, nicht akademisch, einfach und prägnant.

Ich habe nicht den ganzen Artikel gelesen, aber in der Überschrift, in der Sie dort etwas Negatives über Immunität gesagt haben, sind Sie wahrscheinlich nicht orthodox, weil Sie aufgrund Ihrer Unerfahrenheit und Dummheit nicht verstehen, wie großartig ein funktionaler Ansatz ist!

Lassen Sie uns die Immunität als funktionales Paradigma (wir respektieren den funktionalen Ansatz, das Konzept der Immunität und die Reinheit der Funktionen sehr) und den aktuellen Zustand der JS-Welt und ihrer Bibliotheken trennen. Wenn ein Entwickler nach dem Lesen des Facebook-Blogs gerne Immutable.js greift und es in Produktion nimmt und dann feststellt, dass er kein sehr gutes Dock hat, arbeiten Lodash und der gesamte Rest des von der vorherigen Entwicklergeneration geschriebenen Codes nicht mit ihm (ja, ich weiß Bescheid über unveränderliche Wrapper um lodash, danke), und daher versäumt der Entwickler die Frist - dies bedeutet, dass der Entwickler nicht das Funktionsparadigma gekauft hat, sondern den Hype um die spezifische Bibliothek. Denken Sie nicht, dass wenn Facebook echte Probleme hat, die mit Immutable.js gelöst werden, dies bedeutet, dass Sie Probleme in einer ähnlichen Reihenfolge auf Ihrer Zielseite oder Ihrem SPA haben.Höchstwahrscheinlich nichtIhren Anlegern wird das Geld ausgehen, Sie müssen die Arbeitsfunktionen so schnell wie möglich einführen, und es reicht aus, wenn der Code normal ist und nicht mutiert, wenn dies nicht erforderlich ist. Dazu muss Immutable.js nicht verwendet werden (lesen Sie beispielsweise die Meinung zu Immutable.js hier ). Unabhängig davon stelle ich fest, dass eine große Anzahl von JS-Entwicklern, deren Meinung ich als das Hauptkiller-Feature von Immutable.js angesehen habe, nicht die Reinheit und Zuverlässigkeit des resultierenden Codes genannt werden, sondern - Aufmerksamkeit! - Steigerung der Produktivität (wir sprechen von schnellen Vergleichen von Strukturen)! Etwas auf dieser Welt stimmt nicht, wenn Leute ein funktionales Stück dieses Levels vorantreiben, um die Leistung in ihrem Projekt zu verbessern. Es scheint, dass die Mode wieder eingegriffen hat ...

Wenn Sie Ihr Leben vereinfachen möchten, hören Sie einfach auf, Ihren Zustand zu mutieren, wechseln Sie zu Requisiten, und diese einfachen Dinge werden Ihr Leben jetzt verbessern.

Source: https://habr.com/ru/post/de400227/


All Articles