With the advent of JavaScript libraries that are developed by large teams, such as Angular, React, Vue, irreversibly left the arena, single geniuses who developed all or at least the main part of the library on their own. I suggest recalling the names of these libraries together, and, finally, finding out the names of their developers.2005 - Prototype.js
The library was released in 2005 as part of the Ruby-on-Rails project. The first developer of the library was Sam Stephenson (see www.sergiopereira.com/articles/prototype.js.html ). The Prototype.js license (see prototypejs.org/license.html ) has a link to his personal page sstephenson.us , which, in turn, published the author's email: sstephenson@gmail.com.Further email searches result in his active repository github.com/sstephenson and twitter.com/sstephenson (non-public twitter). You can also learn about him that he works as a Programmer at Basecamp, and watch a video report from the RubyConf 2016 conferenceThe Prototype.js library for the first time formed a “gentleman's set” of all subsequent libraries of that time: access to the DOM via the $ (...) function, Ajax requests. But the main thing was a powerful breakthrough towards “functionalism” by implementing the Enumerable interface (all (), any (), collect (), detect (), each (), etc.). In fact, with the spread of this particular library, JavaScript programming has acquired a modern style. Some ideas of Prototype.js entered the standard of the language, and were repeated in the later libraries underscore.js and lodash.js.The Prorotype.js library has two significant drawbacks. The implementation of the new functionality was based on mixing new properties and methods into native objects. For example, it was because of this line that we forever stopped using the for ... in loop to iterate over array elements:
Object.extend(Array.prototype, Enumerable);
Also problematic is the definition of a large number of variables with a global scope in the Prototype.js library:
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);
}
}
}
...
As a correction of these two miscalculations, the jquery library was positioned, to which we may possibly return.2010 - requirejs
The first versions of JavaScript did not have module support, since the variables and functions defined at the top level had a global scope (and not local within the module, file), and there was no mechanism for loading dependent modules. In January 2009, Kevin Dangoor published the Blue Sky on Mars blog post, which started a discussion about ways to port JavaScript to the server. At some point, the idea of the wiki.commonjs.org/wiki/Modules/AsynchronousDefinition (AMD) API came up , which would allow to load dependent modules asynchronously, without going beyond the standard (for 2009) JavaScript. This API was not subsequently accepted for implementation on the server side, but soon spread widely on the frontend, as it was based on standard JavaScript.The first implementations of the AMD specification loaded modules in the form of text, which was then executed by the eval () function. This approach had significant flaws in terms of performance, security, and was difficult to debug. These problems were solved by the requirejs library, which loads modules using programmatically generated SCRIPT elements.Let's try to figure out who was the author of this idea. In the first versions of the library, there is a link to the James Burke repository (now the library itself is not in this repository):
The search for links leads us to Twitter by twitter.com/jrburke , the already mentioned github.com/jrburke repository, and the Linkedin profile www.linkedin.com/in/james-burke-7994a11 . Also, in the public domain there is a performance by the author at the VanJS 2013 conference (yes there were previously not glamorous conferences):The developer of the requirejs library has come up with an ingenious way to load modules according to the AMD specification, without going beyond the standard JavaScript at that time, which is its undoubted merit. But there were also disadvantages. The syntax for using AMD modules is rather complicated, for which the CommonJS group has refused. Loading a large number of small modules slows down the loading of a web page. Soon, the linkers grunt, gulp, webpack, and others appeared that negated the benefits of using the requirejs library. In general, one could characterize this library as a tool that distracted some developers, who until the last held on to vanillajs js, from switching to the new JavaScript standard.To be continued