"Die Geschichte ist nicht die Vergangenheit, die Geschichte wird inszeniert. Mit der raschen Entwicklung von W3C und Browsern wird die modulare Entwicklung der Frontend allmählich in eine Infrastruktur. Alles wird irgendwann Geschichte und die Zukunft wird besser." - Ich persönlich stimme dem letzten Absatz von Yu Bos ursprünglichem Text zu. Da wir über die "Zukunft" sprechen, bin ich persönlich der Ansicht, dass das Modulformat wahrscheinlich zu einer Standardspezifikation für zukünftige Web-Methoden wird, wenn sich das Front-End-JS-Modul weiterentwickelt und mehrere Implementierungsmethoden erzeugt. Genau wie das JSON -Format wird es schließlich Standard und wird vom Browser nativ implementiert.
Wer hat den besten Standard für asynchrone Module, um die Zukunft zu werden? SeaJs folgt der CMD -Spezifikation, fordertjs folgt der AMD -Spezifikation und beginnen wir mit diesen beiden verschiedenen Formaten.
CMD
CMD -Modulabhängigkeitserklärung Methode:
Die Codekopie lautet wie folgt:
definieren (Funktion (erfordern) {
var a = erfordern ('./ a');
var b = erfordern ('./ B');
// mehr Code ..
})
CMD -Abhängigkeiten werden in der Nähe deklariert und durch interne Forderungsmethoden deklariert. Da es sich jedoch um ein asynchrones Modul handelt, muss der Lader diese Module im Voraus laden. Bevor das Modul tatsächlich verwendet wird, müssen alle Abhängigkeiten im Modul extrahiert werden. Unabhängig davon, ob es sich bei der Lader-Extraktion oder der Vorextrahiere durch automatisierte Tools handelt, kann dieses Abhängigkeitserklärungsformat von CMD nur durch statische Analyse implementiert werden, was der Nachteil von CMD ist.
Nachteile der CMD -Spezifikationen
Kann nicht direkt komprimieren: Erfordernis ist eine lokale Variable, was bedeutet, dass sie nicht direkt durch das Komprimierungswerkzeug komprimiert werden kann. Wenn die erforderliche Variable ersetzt wird, können die Lader- und Automatisierungswerkzeuge die Abhängigkeiten des Moduls nicht erhalten.
Das Modul verfügt über eine zusätzliche Konvention: Die Pfadparameter können keine String -Operationen sein, und stattdessen können Variablen nicht verwendet werden, andernfalls können die Lader- und Automatisierungswerkzeuge den Pfad nicht korrekt extrahieren.
Konventionen außerhalb der Spezifikation bedeuten mehr Dokumentation, es sei denn, sie sind auch Teil der Spezifikation.
HINWEIS: Die Implementierung der statischen Analyse von SeaJS besteht darin, den regulären Teil des Extraktionsanforderungen zu verwenden, um den Abhängigkeitsmodulpfad zu erhalten.
AMD
AMD -Modulabhängigkeitserklärung Methode:
Die Codekopie lautet wie folgt:
definiere (['./ a', './b'], Funktion (a, b) {
// mehr Code ..
})
Die Abhängigkeiten von AMD werden im Voraus deklariert. Der Vorteil dieses Vorteils besteht darin, dass Abhängigkeit keine statische Analyse erfordert. Sowohl der Lader als auch das Automatisierungswerkzeug können direkt Abhängigkeiten erhalten. Die Definition der Spezifikation kann einfacher sein, was bedeutet, dass leistungsfähigere Implementierungen generiert werden können, was sowohl für den Lader- als auch für das Automatisierungsanalyse -Tool von Vorteil ist.
Nachteile der AMD -Spezifikation
Abhängigkeitserklärungen sind beim Schreiben von Code nicht so freundlich.
Es gibt einen bestimmten Unterschied zwischen dem Modul im Inneren und den Modulen von NodeJs.
Das zweite Problem muss ausführlich erläutert werden. Tatsächlich können weder die asynchronen Module von CMD noch AMD mit der Synchronisationsmodulspezifikation (NodeJS -Module) übereinstimmen, nur wer ist eher ein Synchronisationsmodul als wie der, der es ist. Um AMD in ein Synchronisationsmodul umzuwandeln, müssen Sie neben der Entfernung des Pakets der Define -Funktion im Kopf die Anforderung verwenden, um die Abhängigkeit zu deklarieren, während CMD nur das Paket der Define -Funktion entfernen muss.
Zusammenfassen
In Bezug auf die Spezifikation ist AMD einfacher und strenger und hat eine breitere Anwendbarkeit. Mit der starken Förderung von Forderung ist es fast zu einem asynchronen Modulstandard im Ausland geworden, und große Bibliotheken haben nacheinander AMD -Spezifikationen unterstützt.
Aber von SeaJs und CMD haben wir auch viele gute Dinge getan:
1. Relativ natürlicher Abhängigkeitsstil
2. kleine und schöne interne Erkenntnis
3.. Sorgfältiges Design der peripheren Funktionsfunktion
4.. Bessere Unterstützung für die chinesische Gemeinschaft
Wenn möglich, hoffe ich zu sehen, dass SeaJs AMD auch unterstützt, und das ultimative Glück der Entwickler ist die Mehrheit der Entwickler.