"L'histoire n'est pas le passé, l'histoire est mise en scène. Avec le développement rapide du W3C et des navigateurs, le développement modulaire frontal deviendra progressivement des infrastructures. Tout deviendra finalement l'histoire, et l'avenir sera meilleur." - Je suis personnellement d'accord avec le dernier paragraphe du texte original de Yu Bo. Puisque nous parlons de "l'avenir", je crois personnellement que si le module JS frontal continue de se développer, son format de module est susceptible de devenir une spécification standard pour les futurs méthodes de mise en œuvre multiples. Tout comme le format JSON, il devient finalement standard et est implémenté nativement par le navigateur.
Qui a la meilleure norme pour que les modules asynchrones deviennent l'avenir? SEAJS suit la spécification CMD, requirejs suit la spécification AMD, commençons par ces deux formats différents.
CMD
Méthode de déclaration de dépendance du module CMD:
La copie de code est la suivante:
définir (fonction (require) {
var a = require ('./ a');
var b = require ('./ b');
// plus de code ..
})
Les dépendances CMD sont déclarées à proximité et sont déclarées par des méthodes internes exigent. Cependant, comme il s'agit d'un module asynchrone, le chargeur doit charger ces modules à l'avance, donc avant que le module ne soit réellement utilisé, toutes les dépendances du module doivent être extraites. Qu'il s'agisse d'extraction du chargeur ou de pré-extraction via des outils automatisés, ce format de déclaration de dépendance de CMD ne peut être mis en œuvre que par analyse statique, qui est l'inconvénient de la CMD.
Inconvénients des spécifications CMD
Impossible de compresser directement: exiger est une variable locale, ce qui signifie qu'il ne peut pas être compressé directement via l'outil de compression. Si la variable requise est remplacée, le chargeur et les outils d'automatisation ne pourront pas obtenir les dépendances du module.
Le module a une convention supplémentaire: les paramètres de chemin ne peuvent pas être des opérations de chaîne et les variables ne peuvent pas être utilisées à la place, sinon les outils de chargeur et d'automatisation ne peuvent pas extraire le chemin correctement.
Les conventions en dehors de la spécification signifient plus de documentation, sauf si elles font également partie de la spécification.
Remarque: La mise en œuvre de l'analyse statique SEAJS consiste à utiliser la partie d'exigence d'extraction régulière pour obtenir le chemin du module de dépendance.
DMLA
Méthode de déclaration de dépendance des modules AMD:
La copie de code est la suivante:
définir (['. ./ a', './b'], fonction (a, b) {
// plus de code ..
})
Les dépendances d'AMD sont déclarées à l'avance. L'avantage de cet avantage est que la dépendance ne nécessite pas d'analyse statique. Le chargeur et l'outil d'automatisation peuvent obtenir directement des dépendances. La définition de la spécification peut être plus simple, ce qui signifie que des implémentations plus puissantes peuvent être générées, ce qui est bénéfique à la fois pour le chargeur et l'outil d'analyse d'automatisation.
Inconvénients de la spécification AMD
Les déclarations d'avance de dépendance ne sont pas si amicales dans l'écriture de code.
Il y a une certaine différence entre le module à l'intérieur et les modules de NodeJS.
Le deuxième numéro doit être expliqué en détail. En fait, ni les modules asynchrones de CMD ni AMD ne peuvent être cohérents avec la spécification du module de synchronisation (modules de NodeJS), seulement qui ressemble plus à un module de synchronisation que qui l'est. Pour convertir AMD en un module de synchronisation, en plus de supprimer le package de la fonction Define, vous devez utiliser l'exigence dans la tête pour déclarer la dépendance, tandis que CMD doit uniquement supprimer le package de la fonction Définir.
Résumer
En termes de spécification, la DMA est plus simple et rigoureuse et a une applicabilité plus large. Avec la forte promotion des exigences, il est presque devenu un module asynchrone de facto standard à l'étranger, et les grandes bibliothèques ont succédé des spécifications de DMLA.
Mais de Seajs et CMD, nous avons également fait beaucoup de bonnes choses:
1. Style de déclaration de dépendance relativement naturelle
2. Réalisation interne petite et belle
3. Conception prudente de la fonction périphérique
4. Meilleur soutien communautaire chinois
Si possible, j'espère voir les Seajs soutenir également AMD, et le bonheur ultime des développeurs est la majorité des développeurs.