Avec l'avènement des bibliothèques JavaScript développées par de grandes équipes, telles que Angular, React, Vue, ont irréversiblement quitté l'arène, des génies uniques qui ont développé tout ou au moins la partie principale de la bibliothèque par eux-mêmes. Je suggère de rappeler les noms de ces bibliothèques ensemble et, enfin, de trouver les noms de leurs développeurs.2005 - Prototype.js
La bibliothèque est sortie en 2005 dans le cadre du projet Ruby-on-Rails. Le premier développeur de la bibliothèque a été Sam Stephenson (voir www.sergiopereira.com/articles/prototype.js.html ). La licence Prototype.js (voir prototypejs.org/license.html ) a un lien vers sa page personnelle sstephenson.us , qui, à son tour, a publié le courriel de l'auteur: sstephenson@gmail.com.D'autres recherches par e-mail aboutissent à son référentiel actif github.com/sstephenson et twitter.com/sstephenson (twitter non public). Vous pouvez également apprendre à son sujet qu'il travaille en tant que programmeur à Basecamp, et regarder un reportage vidéo de la conférence RubyConf 2016Pour la première fois, la bibliothèque Prototype.js a constitué un «gentleman's set» de toutes les bibliothèques de l'époque: accès au DOM via la fonction $ (...), demande Ajax. Mais l'essentiel a été une percée puissante vers le «fonctionnalisme» en implémentant l'interface Enumerable (all (), any (), collect (), detect (), each (), etc.). En fait, avec la propagation de cette bibliothèque particulière, la programmation JavaScript a acquis un style moderne. Certaines idées de Prototype.js sont entrées dans le standard du langage et ont été répétées dans les bibliothèques ultérieures underscore.js et lodash.js.La bibliothèque Prorotype.js présente deux inconvénients importants. L'implémentation de la nouvelle fonctionnalité était basée sur le mélange de nouvelles propriétés et méthodes dans des objets natifs. Par exemple, c'est à cause de cette ligne que nous avons définitivement cessé d'utiliser la boucle for ... in pour parcourir les éléments du tableau:
Object.extend(Array.prototype, Enumerable);
La définition d'un grand nombre de variables de portée globale dans la bibliothèque Prototype.js pose également problème:
var Prototype = {
Version: '1.5.0',
BrowserFeatures: {
XPath: !!document.evaluate
},
ScriptFragment: '(?:<script.*?>)((\n|\r|.)*?)(?:<\/script>)',
emptyFunction: function() {},
K: function(x) { return x }
}
var Class = {
create: function() {
return function() {
this.initialize.apply(this, arguments);
}
}
}
...
Pour corriger ces deux erreurs de calcul, la bibliothèque jquery a été positionnée, sur laquelle nous pourrions éventuellement revenir.2010 - requirejs
Les premières versions de JavaScript ne prenaient pas en charge les modules, car les variables et fonctions définies au niveau supérieur avaient une portée globale (et non locale dans le module, le fichier), et il n'y avait pas de mécanisme de chargement des modules dépendants. En janvier 2009, Kevin Dangoor a publié un article de blog intitulé Blue Sky on Mars, qui a lancé une discussion sur les moyens de porter JavaScript sur le serveur. À un moment donné, l'idée de l' API wiki.commonjs.org/wiki/Modules/AsynchronousDefinition (AMD) est apparue , ce qui permettrait de charger les modules dépendants de manière asynchrone, sans aller au-delà du JavaScript standard (pour 2009). Cette API n'a pas été acceptée par la suite pour la mise en œuvre côté serveur, mais s'est rapidement répandue largement sur le frontend, car elle était basée sur JavaScript standard.Les premières implémentations de la spécification AMD ont chargé des modules sous forme de texte, qui a ensuite été exécuté par la fonction eval (). Cette approche avait des défauts importants en termes de performances, de sécurité et était difficile à déboguer. Ces problèmes ont été résolus par la bibliothèque requirejs, qui charge les modules à l'aide d'éléments SCRIPT générés par programme.Essayons de savoir qui est l'auteur de cette idée. Dans les premières versions de la bibliothèque, il y a un lien vers le référentiel James Burke (maintenant la bibliothèque elle-même n'est pas dans ce référentiel):
La recherche de liens nous mène à Twitter par twitter.com/jrburke , le référentiel github.com/jrburke déjà mentionné et le profil Linkedin www.linkedin.com/in/james-burke-7994a11 . De plus, dans le domaine public, il y a une performance de l'auteur à la conférence VanJS 2013 (oui, il n'y avait pas de conférences glamour auparavant):Le développeur de la bibliothèque requirejs a trouvé une manière ingénieuse de charger des modules selon la spécification AMD, sans aller au-delà du JavaScript standard à l'époque, ce qui est son mérite incontestable. Mais il y avait aussi des inconvénients. La syntaxe d'utilisation des modules AMD est assez compliquée, pour laquelle le groupe CommonJS a refusé. Le chargement d'un grand nombre de petits modules ralentit le chargement d'une page Web. Bientôt, les éditeurs de liens grognent, gulp, webpack et d'autres sont apparus qui annulaient les avantages de l'utilisation de la bibliothèque requirejs. En général, on pourrait caractériser cette bibliothèque comme un outil qui a distrait certains développeurs, qui jusqu'au dernier tenaient à vanillajs js, de passer au nouveau standard JavaScript.À suivre