L'histoire du développement de la modularité frontale

Le texte original fait référence au maître de Yu Bo, j'ai fait le tri.

Notre sujet d'aujourd'hui porte sur l'histoire du développement modulaire front-end, principalement pour le développement d'AMD CMD. Ces deux choses sont une sorte de spécification. Leurs produits actuels sont AMD, RequireJS. , et CMD Le produit de Seajs est seajs. Leur apparence est développée sur la base de COMMONjs.

COMMONJS

Vers 2009 – 10 ans, la communauté CommonJS s’est réunie. CommonJS s'appelait à l'origine ServerJS Après le lancement de la spécification Modules/1.0, il a atteint de très bonnes pratiques dans l'environnement Node.js. Au cours du second semestre 2009, ces experts assidus ont voulu promouvoir davantage l'expérience réussie de ServerJS du côté des navigateurs, ils ont donc renommé la communauté CommonJS et ont en même temps débattu âprement de la prochaine version de la spécification des modules. Des différences et des conflits sont nés, et trois grandes écoles se sont progressivement formées : Modules/1.x (entièrement basé sur les fonctions de la 1.0, en ajoutant juste une fonction de conversion), Modules/Async, Modules/ 2.0.

Modules/1.x school : Ce point de vue estime que la spécification 1.x est suffisante et doit seulement être portée sur le navigateur. Ce qu'il faut faire est d'ajouter une nouvelle spécification Modules/Transport, c'est-à-dire d'utiliser un outil de conversion pour convertir le module en code conforme à la spécification Transport avant de l'exécuter sur le navigateur. Il existe deux implémentations auxquelles il convient de prêter attention maintenant : le composant et le module es6.

Modules/Async school : ce point de vue estime que les navigateurs ont leurs propres caractéristiques et ne devraient pas utiliser directement la spécification Modules/1.x. Les représentants typiques de cette perspective sont la spécification AMD et son implémentation RequireJS. Nous en reparlerons plus tard.

École Modules/2.0 : ce point de vue estime que les navigateurs ont leurs propres caractéristiques et ne devraient pas utiliser directement la spécification Modules/1.x, mais devraient être aussi cohérents que possible avec la spécification Modules/1.x. Les représentants typiques de cette perspective sont les auteurs de BravoJS et FlyScript. Les auteurs BravoJS ont apporté des contributions significatives à la communauté CommonJS. L'auteur de FlyScript a proposé la spécification Modules/Wrappings, qui est le prédécesseur de la spécification CMD. Malheureusement, BravoJS était trop académique et FlyScript s'est ensuite auto-castré et a mis hors ligne l'intégralité du site Web (flyscript.org). Cette histoire est un peu tragique, je n’entrerai donc pas dans les détails.

Ce qui précède sont les trois grandes écoles qui ont émergé, ce qui signifie que les produits démarrés avec Modules/2.0 se sont tous terminés sans aucun problème. À cette époque, Modules/1.x standard ES6 était. pas encore mature, et plus tard c'est RequireJS, qui utilise Modules/Async comme spécification, qui se développe rapidement.

Cependant, il existe des objections quant au timing d'exécution de RequireJS d'AMD, et le style d'écriture du module est controversé et n'a pas été reconnu par la communauté CommonJS. Parlons de ces deux points en détail :

Télécharger un fichier .js à l'avance dans AMD est une limitation du navigateur, et il n'y a aucun moyen de le télécharger de manière synchrone. Cependant, dans AMD, il est exécuté à l'avance, et dans la spécification de base Modules/1.0. il est exécuté lorsqu'il est requis pour la première fois. Beaucoup de gens ne peuvent pas accepter cette différence, y compris ceux qui soutiennent le point de vue Modules/2.0, et ils ne peuvent pas accepter le point de vue d'AMD. Cette différence conduit également au fait que les modules Node et les modules AMD ne peuvent pas être partagés, et il existe un conflit potentiel

L'autre est : le style d'écriture des modules est controversé

Dans le style AMD, les modules dépendants sont transmis via des paramètres, ce qui détruit le principe de déclaration de proximité. Le principe de proximité signifie que ce sera le cas. être utilisé lorsqu'il est utilisé, sans qu'il soit nécessaire de le déclarer au préalable. Finalement, AMD s'est séparé de la communauté CommonJS et est devenu la seule communauté AMD. Plus tard, vous saurez que RequireJS est particulièrement populaire !

En fait, à cette époque, il s'est détaché de la spécification AMD de la communauté CommonJS et. essentiellement évolué vers un accessoire de RequireJS. Plus tard, de nombreuses personnes de la communauté RequireJS ont signalé qu'elles voulaient utiliser la méthode require. En fin de compte, l'auteur de RequireJS a fait un compromis, et c'était le seul moyen d'avoir ce support semi-désactivé. (Notez qu'il s'agit d'un pseudo support, et derrière cela se trouve toujours la logique de fonctionnement d'AMD, comme l'exécution précoce) La popularité d'AMD dépend en grande partie de la promotion des auteurs de RequireJS, et l'évolution des spécifications AMD est indissociable de RequireJS.

Modules/2.0

Wes Garland, l'auteur de BravoJS, possède de profondes compétences en programmation et est également très respecté dans la communauté CommonJS. Mais BravoJS lui-même est très académique, un projet écrit pour démontrer la spécification Modules/2.0-draft. L’école universitaire était vulnérable au pragmatique RequireJS et ne conserve désormais que quelques bons souvenirs.

En ce moment, il existe également une faction pratique dans le camp Modules/2.0 : FlyScript, qui proposait une spécification Modules/Wrappings très concise : Cette spécification concise prend en compte la particularité du navigateur, et est également aussi compatible avec les modules/que possible les spécifications 1.0. Malheureusement, après que FlyScript ait lancé sa version officielle et son site Web officiel, RequireJS était en plein essor à l'époque. Au cours de cette période, il y a eu quelques disputes entre l'auteur de FlyScript et l'auteur de RequireJS, James Burke. Plus tard, l'auteur de FlyScript a effectué une auto-castration et a effacé le projet et le site officiel sur GitHub. Il a laissé une phrase sur le site officiel à ce moment-là. Je me souviens vaguement que c'était :

Je reviendrai avec. chose meilleure.

Ce qui s'est passé au milieu est inconnu. Plus tard, oncle Yu a envoyé un e-mail à l'auteur de FlyScript pour s'enquérir, et l'autre partie m'a donné deux raisons que je respecte, à l'effet général :

1. Je ne suis pas issu du milieu front-end, et James Burke, l'auteur de RequireJS, connaît les navigateurs mieux que moi.

2. Nous devrions travailler ensemble pour favoriser le développement d'une communauté, même si ce n'est pas votre préférée.

Ces deux phrases ont eu un grand impact sur Oncle Yu. C'est également après cela que j'ai commencé à étudier attentivement RequireJS et que j'ai fait de nombreuses suggestions à RequireJS par le biais d'e-mails et d'autres méthodes. Plus tard, dans l’utilisation réelle de RequireJS, j’ai rencontré de nombreux pièges. Même si RequireJS était très populaire à cette époque, il n’était vraiment pas parfait. Pendant cette période, je pensais aussi à ce que FlyScript disait en partant : "Je reviendrai avec de meilleures choses"

Oncle Yu a dit que je ne suis pas aussi génial que l'auteur de FlyScript, et il n'arrêtait pas de donner suggestions à RequireJS Mais après qu'il ait été rejeté à plusieurs reprises, j'ai commencé à avoir l'idée d'écrire moi-même un chargeur.

Voici SeaJS. SeaJS emprunte beaucoup de choses à RequireJS, comme renommer module.declare dans FlyScript en define etc. SeaJS vient davantage du point de vue Modules/2.0, mais il supprime autant que possible les éléments académiques et ajoute beaucoup d'idées pratiques. C'est le produit indirect de CMD, SeaJs.

D'accord, j'ai terminé l'historique de base, je ne sais pas si vous pouvez comprendre ce que j'ai dit. Pour résumer, c'est le premier COMMONJS, car COMMONJS est utilisé sur le. côté serveur., ne peut pas être utilisé directement dans les navigateurs. De nouvelles choses doivent faire l'objet de débats sur la façon d'utiliser cette spécification dans les navigateurs, et différents concepts et arguments sont apparus. Par conséquent, il existe des spécifications AMD et des spécifications CMD adaptées aux navigateurs. Les problèmes n'ont pas été reconnus par la communauté COMMONJS et ont finalement fonctionné de manière indépendante. Bien sûr, RequireJS est devenu populaire pendant un certain temps, et plus tard, le produit Seajs de CMD a été développé par Yubo.

À en juger par la situation actuelle, ces deux produits sont probablement obsolètes. Bien sûr, ils sont toujours utilisés. Après tout, le développement de webpack es6 est imparable et prend entièrement en charge les trois spécifications. à l'avenir, partageons quelques connaissances sur le webpack. C'est tout pour l'histoire du développement modulaire front-end. Il est nécessaire que les débutants comprennent le développement historique du front-end. En fait, l'article original a été écrit par Oncle Yu. Je viens de le modifier dans ma propre version pour qu'il soit plus facile à comprendre pour tout le monde. Vous pouvez également rechercher des informations sur l'histoire de la modularisation frontale. pourquoi la modularisation est nécessaire. Vous pouvez d'abord la comprendre et vous apprendrez plus rapidement si vous étudiez avec des questions.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!