Mit dem Aufkommen von JavaScript-Bibliotheken, die von großen Teams wie Angular, React, Vue entwickelt wurden, verließen sie irreversibel die Arena, einzelne Genies, die die gesamte oder zumindest den Hauptteil der Bibliothek selbst entwickelten. Ich schlage vor, die Namen dieser Bibliotheken gemeinsam abzurufen und schließlich die Namen ihrer Entwickler herauszufinden.2005 - Prototype.js
Die Bibliothek wurde 2005 im Rahmen des Ruby-on-Rails-Projekts veröffentlicht. Der erste Entwickler der Bibliothek war Sam Stephenson (siehe www.sergiopereira.com/articles/prototype.js.html ). Die Prototype.js-Lizenz (siehe prototypejs.org/license.html ) enthält einen Link zu seiner persönlichen Seite sstephenson.us , auf der wiederum die E-Mail des Autors veröffentlicht wurde: sstephenson@gmail.com.Weitere E-Mail-Suchen führen zu seinem aktiven Repository github.com/sstephenson und twitter.com/sstephenson (nicht öffentliches Twitter). Sie können auch erfahren, dass er als Programmierer bei Basecamp arbeitet, und sich einen Videobericht von der RubyConf 2016-Konferenz ansehenZum ersten Mal bildete die Prototype.js-Bibliothek einen „Gentleman-Satz“ aller nachfolgenden Bibliotheken dieser Zeit: Zugriff auf das DOM über die Funktion $ (...), fordert Ajax an. Die Hauptsache war jedoch ein starker Durchbruch in Richtung „Funktionalismus“ durch die Implementierung der Enumerable-Schnittstelle (all (), any (), collect (), detect (), each () usw.). Tatsächlich hat die JavaScript-Programmierung mit der Verbreitung dieser speziellen Bibliothek einen modernen Stil erhalten. Einige Ideen von Prototype.js gingen in den Standard der Sprache ein und wurden in den späteren Bibliotheken underscore.js und lodash.js wiederholt.Die Prorotype.js-Bibliothek weist zwei wesentliche Nachteile auf. Die Implementierung der neuen Funktionalität basierte auf dem Mischen neuer Eigenschaften und Methoden in native Objekte. Zum Beispiel haben wir aufgrund dieser Zeile für immer aufgehört, die for ... in-Schleife zu verwenden, um über Array-Elemente zu iterieren:
Object.extend(Array.prototype, Enumerable);
Problematisch ist auch die Definition einer großen Anzahl von Variablen mit einem globalen Bereich in der Bibliothek Prototype.js:
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);
}
}
}
...
Als Korrektur dieser beiden Fehlkalkulationen wurde die jquery-Bibliothek positioniert, auf die wir möglicherweise zurückkommen können.2010 - requirejs
Die ersten Versionen von JavaScript hatten keine Modulunterstützung, da die auf der obersten Ebene definierten Variablen und Funktionen einen globalen Bereich hatten (und nicht lokal innerhalb des Moduls, der Datei) und es keinen Mechanismus zum Laden abhängiger Module gab. Im Januar 2009 veröffentlichte Kevin Dangoor einen Blog-Beitrag namens Blue Sky on Mars, in dem eine Diskussion über Möglichkeiten zum Portieren von JavaScript auf den Server gestartet wurde. Irgendwann kam die Idee der AMD- API ( wiki.commonjs.org/wiki/Modules/AsynchronousDefinition ) auf , mit der abhängige Module asynchron geladen werden können, ohne über das Standard-JavaScript (für 2009) hinauszugehen. Diese API wurde später nicht für die Implementierung auf der Serverseite akzeptiert, verbreitete sich jedoch bald im Frontend, da sie auf Standard-JavaScript basierte.Bei den ersten Implementierungen der AMD-Spezifikation wurden Module in Form von Text geladen, der dann von der Funktion eval () ausgeführt wurde. Dieser Ansatz hatte erhebliche Mängel in Bezug auf Leistung und Sicherheit und war schwer zu debuggen. Diese Probleme wurden durch die requirejs-Bibliothek gelöst, die Module mit programmgesteuert generierten SCRIPT-Elementen lädt.Versuchen wir herauszufinden, wer der Autor dieser Idee war. In den ersten Versionen der Bibliothek gibt es einen Link zum James Burke-Repository (jetzt befindet sich die Bibliothek selbst nicht in diesem Repository):
Die Suche nach Links führt uns zu Twitter über twitter.com/jrburke , das bereits erwähnte github.com/jrburke Repository und das Linkedin-Profil www.linkedin.com/in/james-burke-7994a11 . Im öffentlichen Bereich gibt es auch eine Aufführung des Autors auf der VanJS 2013-Konferenz (ja, es gab zuvor keine glamourösen Konferenzen):Der Entwickler der requirejs-Bibliothek hat eine ausgeklügelte Methode gefunden, um Module gemäß der AMD-Spezifikation zu laden, ohne über das damalige Standard-JavaScript hinauszugehen, was zweifellos der Vorteil ist. Es gab aber auch Nachteile. Die Syntax für die Verwendung von AMD-Modulen ist ziemlich kompliziert, was die CommonJS-Gruppe abgelehnt hat. Das Laden einer großen Anzahl kleiner Module verlangsamt das Laden einer Webseite. Bald tauchten die Linker auf, schluckten, schluckten, webpackten und andere, die die Vorteile der Verwendung der erforderlichen Bibliothek zunichte machten. Im Allgemeinen könnte man diese Bibliothek als ein Werkzeug charakterisieren, das einige Entwickler, die bis zuletzt an vanillajs js festhielten, vom Übergang zum neuen JavaScript-Standard ablenkte.Fortsetzung folgt