Comparaison des différences entre SeaJS et RequireJS_AngularJS

"L'histoire n'est pas le passé, l'histoire se passe maintenant. Avec le développement rapide de spécifications telles que le W3C et les navigateurs, le développement modulaire frontal deviendra progressivement une infrastructure. Tout finira par devenir de l'histoire et l'avenir sera meilleur. "—— Citant le dernier paragraphe de l'article original de Yu Bo, je suis personnellement tout à fait d'accord. Maintenant que nous parlons du « futur », je pense personnellement que si le module front-end js continue de se développer, son format de module est susceptible de devenir une spécification standard pour le futur WEB, entraînant de multiples méthodes d'implémentation. Tout comme le format JSON, il est finalement devenu un standard et a été implémenté nativement par les navigateurs.

Qui est le plus susceptible de devenir le futur standard des modules asynchrones ? SeaJS suit la spécification CMD et RequireJS suit la spécification AMD. Commençons par ces deux formats différents.

CMD

Méthode de déclaration des dépendances du module CMD :

Copier le code Le code est le suivant :

définir (fonction (exiger) {
var a = require('./a');
var b = require('./b');
// plus de code ..
})

Les dépendances CMD sont déclarées à proximité et via la méthode require interne. Mais comme il s'agit d'un module asynchrone, le chargeur doit charger ces modules à l'avance, donc toutes les dépendances du module doivent être extraites avant que le module ne soit réellement utilisé. Qu'il soit extrait à la volée par le chargeur ou pré-extrait via des outils automatisés, ce format de déclaration de dépendance de CMD ne peut être obtenu que via une analyse statique, ce qui est l'inconvénient de CMD.

Inconvénients de la spécification CMD

Ne peut pas être compressé directement : require est une variable locale, ce qui signifie qu'elle ne peut pas être compressée directement via l'outil de compression. Si la variable require est remplacée, le chargeur et les outils d'automatisation ne pourront pas obtenir les dépendances du module.
Il existe des conventions supplémentaires pour l'écriture de modules : les paramètres de chemin ne peuvent pas être soumis à des opérations sur les chaînes et ne peuvent pas être remplacés par des variables, sinon le chargeur et les outils d'automatisation ne pourront pas extraire correctement le chemin.
Les contrats en dehors du cahier des charges impliquent davantage de documentation, à moins qu'ils ne fassent également partie du cahier des charges.

Remarque : l'analyse statique SeaJS est implémentée en plaçant le package de module toString(), puis en utilisant des expressions régulières pour extraire la partie requise afin d'obtenir le chemin du module dépendant.

AMD

Méthode de déclaration des dépendances du module AMD :

Copier le code Le code est le suivant :

définir(['./a', './b'], fonction (a, b) {
// plus de code ..
})

Les dépendances AMD sont déclarées à l'avance. L'avantage de cet avantage est que les dépendances n'ont pas besoin d'être analysées statiquement. Les chargeurs et les outils d'automatisation peuvent obtenir directement les dépendances. La définition des spécifications peut être plus simple, ce qui signifie que des implémentations plus puissantes peuvent être produites. les chargeurs et l’automatisation sont bénéfiques.

Inconvénients des spécifications AMD

La déclaration des dépendances à l'avance n'est pas si conviviale dans l'écriture de code.
Il existe certaines différences entre les modules internes et les modules NodeJS.
Le deuxième point nécessite une explication particulière. En fait, ni CMD ni le module asynchrone d'AMD ne peuvent être cohérents avec la spécification du module synchrone (un seul module ressemble plus à un module synchrone que l'autre). Pour convertir AMD en module synchronisé, en plus de supprimer le wrapper de la fonction de définition, vous devez utiliser require dans l'en-tête pour déclarer les dépendances, tandis que CMD n'a besoin que de supprimer le wrapper de la fonction de définition.

Résumé

En termes de spécifications, AMD est plus simple et plus rigoureux, avec une applicabilité plus large. Avec la forte promotion de RequireJS, il est presque devenu le standard de module asynchrone de facto à l'étranger, et les principales bibliothèques ont également successivement pris en charge les spécifications AMD.

Mais du point de vue de SeaJS et CMD, cela a aussi fait beaucoup de bonnes choses :

1. Style de déclaration de dépendance relativement naturel
2. Petite mais belle implémentation interne
3. Conception de fonctions périphériques intimes
4. Un meilleur soutien de la communauté chinoise

Si possible, j'aimerais que SeaJS supporte également AMD, afin d'être cohérent avec l'environnement communautaire front-end. Au final, la majorité des développeurs seront contents.