Vergleich der Unterschiede zwischen SeaJS und RequireJS_AngularJS

„Geschichte ist nicht Vergangenheit, Geschichte geschieht jetzt. Mit der rasanten Entwicklung von Spezifikationen wie W3C und Browsern wird die modulare Front-End-Entwicklung nach und nach zur Infrastruktur. Alles wird irgendwann Geschichte und die Zukunft wird besser.“ „—— Wenn ich den letzten Absatz von Yu Bos Originalartikel zitiere, stimme ich persönlich sehr zu. Wenn wir nun über die „Zukunft“ sprechen, denke ich persönlich, dass, wenn sich das Front-End-JS-Modul weiterentwickelt, sein Modulformat wahrscheinlich zu einer Standardspezifikation für das zukünftige WEB wird, was zu mehreren Implementierungsmethoden führt. Genau wie das JSON-Format wurde es schließlich zum Standard und wurde von Browsern nativ implementiert.

Wer wird mit größerer Wahrscheinlichkeit zum zukünftigen Standard für asynchrone Module? SeaJS folgt der CMD-Spezifikation und RequireJS folgt der AMD-Spezifikation. Beginnen wir mit diesen beiden unterschiedlichen Formaten.

CMD

CMD-Modulabhängigkeitsdeklarationsmethode:

Code kopieren Der Code lautet wie folgt:

define(Funktion (erforderlich) {
var a = require('./a');
var b = require('./b');
// mehr Code ..
})

CMD-Abhängigkeiten werden in der Nähe deklariert und über die interne Anforderungsmethode deklariert. Da es sich jedoch um ein asynchrones Modul handelt, muss der Loader diese Module im Voraus laden, sodass alle Abhängigkeiten im Modul extrahiert werden müssen, bevor das Modul tatsächlich verwendet wird. Unabhängig davon, ob es direkt vom Loader extrahiert oder durch automatisierte Tools vorextrahiert wird, kann dieses Abhängigkeitsdeklarationsformat von CMD nur durch statische Analyse erreicht werden, was den Nachteil von CMD darstellt.

Nachteile der CMD-Spezifikation

Kann nicht direkt komprimiert werden: „require“ ist eine lokale Variable, was bedeutet, dass sie nicht direkt über das Komprimierungstool komprimiert werden kann. Wenn die „require“-Variable ersetzt wird, können der Loader und die Automatisierungstools die Abhängigkeiten des Moduls nicht abrufen.
Es gibt zusätzliche Konventionen für das Schreiben von Modulen: Pfadparameter können keinen String-Operationen unterzogen und nicht durch Variablen ersetzt werden, da der Lader und die Automatisierungstools sonst den Pfad nicht korrekt extrahieren können.
Verträge außerhalb der Spezifikation bedeuten mehr Dokumentation, sofern sie nicht auch Teil der Spezifikation sind.

Hinweis: Die statische SeaJS-Analyse wird implementiert, indem das Modulpaket in String() eingefügt wird und dann mithilfe regulärer Ausdrücke der erforderliche Teil extrahiert wird, um den abhängigen Modulpfad zu erhalten.

AMD

AMD-Modulabhängigkeitsdeklarationsmethode:

Code kopieren Der Code lautet wie folgt:

define(['./a', './b'], function (a, b) {
// mehr Code ..
})

AMD-Abhängigkeiten werden im Voraus deklariert. Der Vorteil dieses Vorteils besteht darin, dass Abhängigkeiten nicht statisch analysiert werden müssen. Sowohl Loader als auch Automatisierungstools können Abhängigkeiten einfacher definieren, was bedeutet, dass leistungsfähigere Implementierungen erstellt werden können Analysetools sind von Vorteil.

Nachteile der AMD-Spezifikationen

Die vorherige Deklaration von Abhängigkeiten ist beim Schreiben von Code nicht so einfach.
Es gibt bestimmte Unterschiede zwischen Modulen intern und NodeJS-Modulen.
Der zweite Punkt bedarf einer besonderen Erläuterung. Tatsächlich können weder CMD noch AMDs asynchrone Module mit der synchronen Modulspezifikation (NodeJS-Module) übereinstimmen. Nur eines ähnelt eher einem synchronen Modul als das andere. Um AMD in ein synchronisiertes Modul zu konvertieren, müssen Sie zusätzlich zum Entfernen des Wrappers der Definitionsfunktion „require“ im Header verwenden, um die Abhängigkeiten zu deklarieren, während CMD nur den Wrapper der Definitionsfunktion entfernen muss.

Zusammenfassung

In Bezug auf die Spezifikationen ist AMD einfacher und strenger und bietet eine breitere Anwendbarkeit. Mit der starken Förderung von RequireJS ist es im Ausland fast zum De-facto-Standard für asynchrone Module geworden, und auch große Bibliotheken haben sukzessive AMD-Spezifikationen unterstützt.

Aber aus Sicht von SeaJS und CMD hat es auch viel Gutes bewirkt:

1. Relativ natürlicher Abhängigkeitsdeklarationsstil
2. Kleine, aber feine interne Umsetzung
3. Intimes peripheres Funktionsdesign
4. Bessere Unterstützung der chinesischen Community

Wenn möglich, hoffe ich, dass SeaJS auch AMD unterstützt. Um mit der Front-End-Community-Umgebung konsistent zu sein, liegt die größte Freude bei der Mehrheit der Entwickler.