Die Diskussion der Ergebnisse des Jahres im Frontend wurde plötzlich zum Thema . Ich werde meine Meinung hinzufügen und mich freuen, die Meinung anderer zu hören.
Es scheint mir, dass es sinnvoll ist, darüber zu sprechen, was im modernen Web passiert, von außen wahrgenommen wird und von innen völlig anders wahrgenommen wird. Ja, und "innen" hat mehrere Ebenen. Die Ansicht „sie komplizieren das Layout wieder“ ist einerseits absolut korrekt und andererseits fehlerhaft und verdorben, aber auch die Ansicht „hindert uns nicht daran, Abstraktionen zu erstellen“ ist unwirksam.
Wenn sich jemand beschwert, dass das moderne Web zu kompliziert geworden ist, vertraut ich dieser Person jedes Mal, wenn ich daran erinnern möchte, dass dieses moderne Web seinem Geld in Online-Banken und Kaufformularen, persönlicher Korrespondenz in sozialen Netzwerken und Webversionen von Instant Messenger vertraut. und persönliche Dateien in den Wolken. Und höchstwahrscheinlich möchte er wirklich, dass der Entwicklungsprozess dieser Systeme komplex, schwierig, aber zuverlässig ist und nicht versagt.
Bildquelle
Unter dem modernen Frontend und seinen Freunden verstehen sie jetzt viel mehr, als es von außen scheint. Dies sind klassische Websites und SPA sowie Anwendungen auf dem Elektron und mobile Anwendungen auf Cordova, NativeScript, React Native und sogar auf Flutter. Dies ist eine komplexe Infrastruktur mit CDNs, geodezentralen Diensten, Chatbots auf JS und sogar Tools für maschinelles Lernen, um die Montage und sogar die Layoutgenerierung zu optimieren .
Und im Web selbst erscheinen ungeheuer komplexe Lösungen, die zuvor ausschließlich im Desktop-Modus funktionieren konnten. Ich selbst hatte vor ein paar Jahren Zeit, mich mit der Entwicklung eines vollwertigen Genombrowsers im Browser zu befassen. Ich war damit beschäftigt, Leistung und 60 FPS bereitzustellen, was ein ausreichend großes, aber lösbares Problem war. Noch vor 5 Jahren konnte niemand gedacht haben, dass der Genombrowser nicht auf einem leistungsstarken Computer installiert sein könnte, und diese Lösung ermöglichte es Ärzten und Forschern, selbst von einem Tablet oder einem leichten Laptop aus mit dem Genom zu arbeiten.
Warum?
Derzeit ist das HTML + CSS + JS-Bundle eines der leistungsstärksten in Bezug auf das Erstellen von Schnittstellen - nicht nur aufgrund seiner Funktionen, sondern auch aufgrund der Anzahl der darauf aufbauenden Lösungen - CSS-Frameworks, Bibliotheken visueller Komponenten, Schnittstellen zu einer Vielzahl von Diensten und SAAS . In Bezug auf die Effizienz der Entwicklungszeiten für potenzielle Zielgruppen und die Barrierefreiheit sind Webtechnologien sowohl mobilen als auch Desktop-Lösungen voraus. Und jetzt hat es sich in drei Bereiche aufgeteilt:
- Entwicklung vollständig statischer und nahezu statischer Websites mit teilweise dynamischem Inhalt (Galerien, Popups usw.)
- Entwicklung "klassischer" Webanwendungen auf Server-Frameworks (Django, Rails)
- Web-Client-Entwicklung
Und jeder von ihnen hat eine ganz andere Spezifität.
Die JS-Entwicklung war wirklich schmerzhaft, daher tauchten Lösungen auf, die diesen Schmerz lösten.
Wenn Sie sie sich ansehen, sehen Sie etwas sehr Interessantes: Zuerst tauchten Lösungen wie jQuery und CoffeeScript auf, die die Redundanz und Ausführlichkeit der Sprache reduzierten. Aber sie verschwanden schnell und an ihre Stelle traten Tools, die es ermöglichten, Code so effizient wie möglich wiederzuverwenden, Fehler statisch zu erkennen und effektive Abstraktionen zu erstellen, wodurch einzelne Komplexitätsebenen hinter einfachen und gut beschriebenen Schnittstellen "versteckt" wurden.
Es erschien GraphQL, das Probleme mit der Komplexität der Beschreibung, Dokumentation und Pflege von REST löst. TypeScript und Flow erschienen, wodurch die Probleme des fehlenden Tippens gelöst wurden. Es sind neue Sprachentitäten erschienen, mit denen Sie effektiv mit asynchronen Operationen, Klassen und Datenströmen arbeiten können. WebAssembly wurde angezeigt, mit dem Sie Code aus anderen Sprachen schnell wiederverwenden können.
Alle diese Lösungen zielen auf dasselbe ab: die Wiederverwendung des Codes und das Potenzial, "flache" Teams aufzubauen. Sie lösen das Problem, um den Code eines anderen zu übernehmen und ihn zu verwenden.
Dies ist ein klarer Beweis dafür, dass sich das Web dahingehend entwickelt, in großen Teams zu arbeiten. Es ist zu einer Plattform für "Erwachsenen" -Lösungen geworden.
Eine Reihe von Ereignissen, die sich weiter ereigneten, wurden noch deutlicher: React Native, NativeScript, Dart + Flutter und andere Lösungen zur Wiederverwendung von Code auf nativen Plattformen wurden angezeigt. Dies ist ein sehr wichtiger Punkt: Aufgrund der mangelnden Fähigkeit, andere Sprachen im Web zu verwenden, begannen Unternehmen, ihre Prozesse auf der Suche nach einer "Silberkugel" zu optimieren, die es ihnen ermöglicht, keineswegs geringe Entwicklungskosten und Zeit zu reduzieren, um allen Kunden neue Funktionen bereitzustellen. Es ist wichtig, dass jedes Projekt schnell ist, und hochrangige Spezialisten begannen sich zusammenzuschließen, um die Möglichkeit zu finden, effektiv an JS zu arbeiten.
Aus dem gleichen Grund begannen Template-Engines übrigens teilweise zu sterben: Die Verwendung einer weiteren Semantik erwies sich als weniger effektiv als die Verwendung von bekanntem HTML mit kleinen Erweiterungen in JS (Angular, Vue) oder die Verwendung nur einer Sprache zur Beschreibung des Layouts (React, Flutter). Die Unfähigkeit zu expandieren, die Notwendigkeit, Entwickler in eine neue Sprache einzuführen, das Risiko des Plattformsterbens und die Dezentralisierung führten dazu, dass sie Framework-Vorlagen bevorzugten, die versuchten, HTML / DOM-Plattformen so nahe wie möglich zu kommen.
Zusätzlich zum effizienten Schreiben von Code gibt es jedoch auch einen „Koeffizienten“ zum Synchronisieren eines Befehls. Wenn die Sprache es Ihnen ermöglicht, superschnell zu arbeiten, aber gleichzeitig die Synchronisierung einer einzelnen Funktion zwischen zwei Entwicklern einen schrecklichen Schmerz verursacht, bleibt sie höchstwahrscheinlich eine Nische. Daher zielen viele der Sprachfunktionen und -lösungen speziell darauf ab, Probleme mit der Synchronisation und das Fehlen von Problemen zu reduzieren. Sie reduzieren diesen "Koeffizienten", der angibt, wie viele Junioren gleichzeitig die Mitte steuern können und wie viele Mitten vom Hauptentwickler gesteuert werden können. Von den neuesten Beispielen für solche Funktionen löst es6-Importe teilweise das Problem der zyklischen Abhängigkeit, während hübscher es Ihnen ermöglicht, die erwartete, gut geeignete Zusammenführung in Git-Code zu erhalten, unabhängig davon, wie der Entwickler sie schreibt. Es sollte nicht schön sein, es sollte gut synchronisiert sein.
Infolgedessen wurde das Web als Plattform in nur wenigen Jahren von großen Unternehmen und seriösen Teams übernommen, weshalb die Mehrheit unter "Javascript-Müdigkeit" leidet . Übrigens besteht der Hauptanspruch auf das von Chromium vertretene Fast-Monopol von Google im Web darin, dass sie das, was sie benötigen, in die Funktionen der Webplattform und von JS einbringen (obwohl dies normalerweise mit dem übereinstimmt, was die meisten Unternehmen benötigen).
Als Ergebnis haben wir einerseits eine absolut reizvolle Plattform für Code, der überall wiederverwendet wird, eine Syntax, mit der Sie mit großen flachen Befehlen arbeiten können. Aber ...
Alles wurde kompliziert und alle wurden verwirrt
Und niemand verstand, was zu tun war. Was ist eigentlich das Problem? In diesen drei verschiedenen Kategorien.
- Entwicklung vollständig statischer und nahezu statischer Websites mit teilweise dynamischem Inhalt: Diese Art von Anwendung zeichnet sich durch HTML als Einstiegspunkt, maximale Downloadgeschwindigkeit und optionales JS aus
- Entwicklung "klassischer" Webanwendungen auf Server-Frameworks (Django, Rails): Diese Lösungen zeichnen sich derzeit durch das Laden von HTML als Einstiegspunkt aus. Statt der maximalen Download-Geschwindigkeit konzentrieren sie sich jedoch auf die Wiederverwendung von Code, DRY und Backend-Integration. JS-Code wird teilweise vom Framework generiert (Benachrichtigungen, Formulare, Turbo-Links usw.), teilweise müssen Sie selbst schreiben
- Entwicklung von Webclient-Anwendungen. Hier passiert das Unerwartete: HTML anstelle eines Einstiegspunkts wird sowohl zum Anwendungsmanifest als auch zur Rendering-Plattform, und JS wird zum „Einstiegspunkt“.
Was meine ich mit einem Einstiegspunkt: Dies ist eine bestimmte Entität, deren Belastung der Mindestlieferung an den Produktbenutzer entspricht. Wenn der Benutzer die Informationen anzeigen muss, benötigen wir HTML + CSS. Wenn wir die Anwendung ausführen, benötigen wir JS, das über HTML ausgeführt wird.
Und um alle völlig zu verwirren, erschien eine vierte Kategorie:
Isomorphe Anwendungen
Unter "isomorph" in der Webentwicklung versteht man normalerweise etwas, das sowohl auf dem Server als auch auf dem Client funktioniert. In diesem Modus können Anwendungen auf React, Angular, Vue.js funktionieren. Es gibt vorgefertigte Frameworks - beispielsweise Next und Nuxt .
Beide Aufgaben sind für sie relevant: Die Webanwendung sollte dem Benutzer so schnell wie möglich ihren Ausgangszustand liefern und als Anwendung fungieren. Mit anderen Worten, sie müssen sowohl HTML als auch JS als zwei Einstiegspunkte bereitstellen, einen für den Inhalt und einen für die Anwendung. Dies führt zu zwei widersprüchlichen Absätzen: Zum einen muss die gelieferte Datenmenge minimal sein, zum anderen ist eine Wiederverwendung von Code erforderlich. Für JS wird dies durch Webpack-Chunks, Code-Aufteilung und dynamisches Laden von Code gelöst. Die Vorlagen bleiben für JS übrig, CSS bleibt jedoch erhalten. Und vor allem möchten wir dem Benutzer kein einziges zusätzliches Byte liefern. Und dann kam jemand auf die Idee: Solche Anwendungen haben wirklich zwei Einstiegspunkte. Sie können als zwei autonome Einheiten verarbeitet werden.
Daraus entstand das CSS-in-JS-Konzept, das sich auf zwei separate Prozesse konzentrierte: Generieren einer CSS-Datei für statischen Inhalt und Speichern von Stilen neben Komponenten.
Alles übrig für JS.
Jetzt können Sie in JS Stile, Layout und den tatsächlichen Code finden.
Jetzt ist alles in js und das ist gut so
Es lohnt sich, einen weiteren Exkurs zu machen - jetzt zum Lebensmittelgeschäft.
Es ist wichtig, dass sich jedes Produkt in der Entwicklung oder Entwicklung in die andere Richtung "bewegen" kann. Es wirkt auf einer der Ebenen:
Die Möglichkeit, eine visuelle Komponente durch Hinzufügen einer Codezeile in eine Komponente mit minimaler Logik umzuwandeln, ist sehr cool. Die Notwendigkeit, es von Grund auf neu zu schreiben, ist nicht cool.
Es ist wirklich cool, es billig zu machen, ein SPA oder eine serverseitige Anwendung zu werden, aber es ist sehr selten möglich. Es ist klüger, mit einer solchen Plattform von vorne zu beginnen, wenn sie keine Kosten verursacht.
Daher versucht fast jedes Webprojekt, bei dem das Risiko besteht, dass es auf dem Server gerendert werden muss, das Risiko, dass Komponenten umgestaltet werden müssen, von einer Vorlagen-Engine zu einer anderen zu wechseln, Risiken zu vermeiden.
Wenn es eine einzige Plattform gibt, auf der sich einige Entitäten recht billig in andere verwandeln können, ist die Entwicklung verdammt schnell.
Bei einer Anwendung auf Angular / React / Vue ist dies genau so. Sie sind schwer zu verstehen. Natürlich nicht so kompliziert wie Angular 1, aber trotzdem - der Weg zum Verständnis ist lang und die sechsmonatigen Online-Kurse reichen nicht aus, um sie zu verstehen. Aber sie bieten die Möglichkeit, in wenigen Stunden das zu tun, was einige Wochen zuvor getan wurde, und in wenigen Tagen - was früher mehrere Monate gedauert hat.
Das Gegenteil ist jedoch auch der Fall - viele brauchen sie nicht, aber sie werden verwendet, weil sie "modisch" sind.
Wenn der Infrastrukturarchitekt für Web- und mobile Anwendungsgruppen und der Layoutdesigner sprechen, wird es ihnen verdammt schwer fallen. Dies sind so unterschiedliche Richtungen, dass sie außer JS keine Schnittpunkte im Wissen haben.
Wenn Sie das nächste Mal sagen möchten, dass das Web sehr komplex und aufgebläht ist, denken Sie darüber nach, wie schwierig es ist, einen Google-Posteingang-Mail-Client (mit intelligenten Entitäten, die je nach Buchstabe enthalten sind), eine Web-IDE wie Cloud9 oder Internetbanking zu entwerfen und zu erstellen .
Aber wenn ein Codierer zu Ihnen kommt und über die Tatsache spricht, dass er reagieren muss, weil er strenge Eingaben und Dekoratoren für das Layout der Zielseite benötigt, lassen Sie sich nicht überzeugen.