Die Entwicklungsgeschichte der Front-End-Modularität

Originalreferenz Yu Bo ist ein Meister, ich habe es geklärt.

Heute werden wir über die Geschichte der modularen Front-End-Entwicklung sprechen, hauptsächlich für die Entwicklung von AMD CMD. Ihre eigentlichen Produkte sind AMD, RequireJS Das Produkt von Seajs ist Seajs. Ihr Erscheinungsbild basiert auf COMMONjs.

COMMONJS

Ungefähr 2009 – 10 Jahre lang versammelte sich die CommonJS-Community. CommonJS hieß ursprünglich ServerJS. Nach der Einführung der Modules/1.0-Spezifikation hat es in der Node.js-Umgebung sehr gute Praktiken erzielt. In der zweiten Hälfte des Jahres 2009 wollten diese fleißigen Meister die erfolgreiche Erfahrung von ServerJS im Browser weiter vorantreiben, deshalb benannten sie die Community in CommonJS um und debattierten gleichzeitig heftig über die nächste Version der Modulspezifikation. Unterschiede und Konflikte entstanden und nach und nach wurden drei große Schulen gebildet: Modules/1.x (vollständig auf den Funktionen von 1.0 basierend, nur mit einer Konvertierungsfunktion hinzugefügt), Modules/Async, Modules/ 2.0.

Module/1.x Schule: Diese Ansicht geht davon aus, dass die 1.x-Spezifikation ausreichend ist und nur auf den Browser portiert werden muss. Was getan werden muss, ist, eine neue Modul-/Transportspezifikation hinzuzufügen, das heißt, ein Konvertierungstool zu verwenden, um das Modul in Code zu konvertieren, der der Transportspezifikation entspricht, bevor es im Browser ausgeführt wird. Es gibt zwei Implementierungen, die es wert sind, beachtet zu werden: Komponente und ES6-Modul.

Module/Async-Schule: Diese Ansicht geht davon aus, dass Browser ihre eigenen Eigenschaften haben und die Modules/1.x-Spezifikation nicht direkt verwenden sollten. Typische Vertreter dieser Perspektive sind die AMD-Spezifikation und deren Umsetzung RequireJS. Mehr dazu später.

Module/2.0-Schule: Diese Ansicht ist der Ansicht, dass Browser ihre eigenen Eigenschaften haben und die Modules/1.x-Spezifikation nicht direkt verwenden sollten, sondern so konsistent wie möglich mit der Modules/1.x-Spezifikation sein sollten. Typische Vertreter dieser Perspektive sind die Autoren von BravoJS und FlyScript. BravoJS-Autoren haben bedeutende Beiträge zur CommonJS-Community geleistet. Der Autor von FlyScript schlug die Modules/Wrappings-Spezifikation vor, die der Vorgänger der CMD-Spezifikation ist. Schade, dass BravoJS zu akademisch ist und FlyScript sich später selbst kastrierte und die gesamte Website (flyscript.org) offline nahm. Diese Geschichte ist etwas tragisch, daher werde ich nicht auf Details eingehen.

Die oben genannten sind die drei großen Schulen, die entstanden sind, was bedeutet, dass die Produkte, die mit Modules/2.0 begannen, alle ohne Probleme endeten. Zu dieser Zeit war Modules/1.x Standard ES6 noch nicht ausgereift, und später war es RequireJS, das Modules/Async als Spezifikation verwendet, entwickelt sich rasant.

Es gibt jedoch Einwände gegen den Ausführungszeitpunkt von AMDs RequireJS, und der Schreibstil des Moduls ist umstritten und wurde von der CommonJS-Community nicht anerkannt. Lassen Sie uns über diese beiden Punkte im Detail sprechen:

Das vorherige Herunterladen von .js in AMD stellt eine Einschränkung des Browsers dar und es gibt keine Möglichkeit, es synchron herunterzuladen. Diese Community stimmt jedoch zu, dass es in AMD im Voraus ausgeführt wird und in der Basismodule/1.0-Spezifikation enthalten ist. Es wird ausgeführt, wenn es zum ersten Mal benötigt wird. Viele Menschen können diesen Unterschied nicht akzeptieren, auch diejenigen, die die Ansicht von Modules/2.0 vertreten, und sie können die Ansicht von AMD nicht akzeptieren. Dieser Unterschied führt auch dazu, dass Knotenmodule und AMD-Module nicht gemeinsam genutzt werden können, und es besteht ein potenzieller Konflikt >

Das andere ist: Der Schreibstil des Moduls ist umstritten

Im AMD-Stil werden abhängige Module über Parameter übergeben, was das Prinzip der Näherungsdeklaration zerstört Es kann verwendet werden, wenn es verwendet wird, ohne dass es im Voraus als Modul deklariert werden muss. Schließlich trennte sich AMD von der CommonJS-Community und wurde zur AMD-Community. Später werden Sie wissen, dass RequireJS besonders beliebt ist!

Tatsächlich löste es sich zu diesem Zeitpunkt von der AMD-Spezifikation der CommonJS-Community Entwickelte sich im Wesentlichen zu einem Zubehörteil von RequireJS. Später berichteten viele Leute in der RequireJS-Community, dass sie die Require-Methode verwenden wollten. Am Ende ging der RequireJS-Autor einen Kompromiss ein, und dies war die einzige Möglichkeit, diese teilweise deaktivierte Unterstützung zu erhalten. (Beachten Sie, dass es sich hierbei um eine Pseudounterstützung handelt und dahinter immer noch die Betriebslogik von AMD steckt, beispielsweise die frühe Ausführung.) Die Popularität von AMD hängt weitgehend von der Förderung der RequireJS-Autoren ab, und die Entwicklung der AMD-Spezifikationen ist untrennbar mit RequireJS verbunden.

Modules/2.0

Wes Garland, der Autor von BravoJS, verfügt über umfassende Programmierkenntnisse und genießt auch in der CommonJS-Community großes Ansehen. Aber BravoJS selbst ist sehr akademisch, ein Projekt, das geschrieben wurde, um die Modules/2.0-Draft-Spezifikation zu demonstrieren. Die akademische Schule war anfällig für das pragmatische RequireJS und behält im Grunde nur noch einige gute Erinnerungen.

Derzeit gibt es auch eine praktische Fraktion im Modules/2.0-Lager: FlyScript, das eine sehr prägnante Modules/Wrappings-Spezifikation vorgeschlagen hat: Diese prägnante Spezifikation berücksichtigt die Besonderheiten des Browsers und ist es auch möglichst kompatibel mit Modulen/ möglichst 1.0 Spezifikationen. Leider boomte RequireJS zu dieser Zeit, nachdem FlyScript seine offizielle Version und offizielle Website veröffentlicht hatte. Während dieser Zeit kam es zu einigen Auseinandersetzungen zwischen dem FlyScript-Autor und dem RequireJS-Autor James Burke. Später führte der Autor von FlyScript eine Selbstkastration durch und löschte das Projekt und die offizielle Website auf GitHub. Ich erinnere mich vage daran, dass er lautete:

Ich werde mit zurückkommen bessere Dinge.

Was in der Mitte passiert ist, ist unbekannt. Später schickte Onkel Yu eine E-Mail an den FlyScript-Autor, um nachzufragen, und die andere Partei nannte mir im Allgemeinen zwei Gründe, die ich respektiere:

1. Ich komme nicht aus dem Frontend-Bereich und James Burke, der Autor von RequireJS, kennt sich mit Browsern besser aus als ich.

2. Wir sollten zusammenarbeiten, um die Entwicklung einer Community zu fördern, auch wenn es nicht Ihr Favorit ist.

Diese beiden Sätze hatten einen großen Einfluss auf Onkel Yu. Danach begann ich auch, RequireJS sorgfältig zu studieren und machte RequireJS viele Vorschläge per E-Mail und auf andere Weise. Später stieß ich bei der tatsächlichen Verwendung von RequireJS auf viele Fallstricke. Obwohl RequireJS zu dieser Zeit sehr beliebt war, war es wirklich nicht perfekt. Während dieser Zeit dachte ich auch darüber nach, was FlyScript sagte, als er ging: „Ich werde mit besseren Dingen zurückkommen“

Onkel Yu sagte, dass ich nicht so großartig sei wie der Autor von FlyScript, und er gab weiter Vorschläge zu RequireJS Aber nachdem es wiederholt abgelehnt wurde, kam mir die Idee, selbst einen Loader zu schreiben.

Das ist SeaJS. SeaJS übernimmt viele Dinge von RequireJS, wie zum Beispiel das Umbenennen von module.declare in FlyScript in define usw. SeaJS basiert eher auf der Module/2.0-Sicht, entfernt aber so weit wie möglich akademische Dinge und fügt viele praktische Ideen hinzu. Dies ist das indirekte Produkt von CMD, SeaJs.

Okay, ich bin mit der grundlegenden Geschichte fertig. Ich weiß nicht, ob jeder verstehen kann, was ich gesagt habe, weil COMMONJS verwendet wird Serverseitig kann es nicht direkt in Browsern verwendet werden, und es sind unterschiedliche Konzepte und Argumente entstanden. Daher gibt es AMD-Spezifikationen und CMD-Spezifikationen, die für Browser geeignet sind Die Probleme wurden von der COMMONJS-Community nicht erkannt und schließlich unabhängig betrieben. Natürlich wurde RequireJS eine Zeit lang populär, und später wurde das CMD-Produkt seajs von Yubo entwickelt.

Nach der aktuellen Situation sind diese beiden Produkte wahrscheinlich veraltet, sie werden immer noch verwendet. Schließlich ist die Entwicklung von Webpack es6 nicht aufzuhalten und wird mehr Unterstützung bieten Lassen Sie uns in Zukunft etwas Wissen über Webpack teilen. Das ist alles für die Geschichte der Front-End-Entwicklung. Es ist notwendig, dass Anfänger die historische Entwicklung des Front-Ends verstehen. Tatsächlich wurde der Originalartikel von Onkel Yu geschrieben, um ihn für alle verständlicher zu machen. Hier gibt es keine Erklärung Warum Modularisierung notwendig ist Sie können es zuerst verstehen und schneller lernen, wenn Sie mit Fragen lernen.

Das obige ist der detaillierte Inhalt vonDie Entwicklungsgeschichte der Front-End-Modularität. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!