Con el advenimiento de las bibliotecas de JavaScript desarrolladas por grandes equipos, como Angular, React, Vue, abandonaron irreversiblemente la arena, genios individuales que desarrollaron toda o al menos la parte principal de la biblioteca por su cuenta. Sugiero recordar juntos los nombres de estas bibliotecas y, finalmente, descubrir los nombres de sus desarrolladores.2005 - Prototype.js
La biblioteca se lanzó en 2005 como parte del proyecto Ruby-on-Rails. El primer desarrollador de la biblioteca fue Sam Stephenson (ver www.sergiopereira.com/articles/prototype.js.html ). La licencia Prototype.js (ver prototypejs.org/license.html ) tiene un enlace a su página personal sstephenson.us , que, a su vez, publicó el correo electrónico del autor: sstephenson@gmail.com.Otras búsquedas por correo electrónico dan como resultado su repositorio activo github.com/sstephenson y twitter.com/sstephenson (twitter no público). También puede aprender sobre él que trabaja como programador en Basecamp y ver un informe en video de la conferencia RubyConf 2016Por primera vez, la biblioteca Prototype.js desarrolló un "conjunto de caballeros" de todas las bibliotecas posteriores de esa época: acceso al DOM a través de la función $ (...), solicita Ajax. Pero lo principal fue un gran avance hacia el "funcionalismo" mediante la implementación de la interfaz Enumerable (all (), any (), collect (), detect (), each (), etc.). De hecho, con la difusión de esta biblioteca en particular, la programación de JavaScript ha adquirido un estilo moderno. Algunas ideas de Prototype.js entraron en el estándar del lenguaje y se repitieron en las bibliotecas posteriores underscore.js y lodash.js.La biblioteca Prorotype.js tiene dos inconvenientes importantes. La implementación de la nueva funcionalidad se basó en mezclar nuevas propiedades y métodos en objetos nativos. Por ejemplo, debido a esta línea, dejamos de usar para siempre el bucle for ... in para iterar sobre los elementos de la matriz:
Object.extend(Array.prototype, Enumerable);
También es problemático la definición de una gran cantidad de variables con un alcance global en la biblioteca 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);
}
}
}
...
Como corrección de estos dos errores de cálculo, se colocó la biblioteca jquery, a la que posiblemente podamos regresar.2010 - requirejs
Las primeras versiones de JavaScript no tenían soporte de módulo, ya que las variables y funciones definidas en el nivel superior tenían un alcance global (y no local dentro del módulo, archivo), y no había ningún mecanismo para cargar módulos dependientes. En enero de 2009, Kevin Dangoor publicó una publicación de blog llamada Blue Sky on Mars, que comenzó una discusión sobre las formas de portar JavaScript al servidor. En algún momento, surgió la idea de la API wiki.commonjs.org/wiki/Modules/AsynchronousDefinition (AMD), que permitiría cargar módulos dependientes de forma asincrónica, sin ir más allá del JavaScript estándar (para 2009). Esta API no se aceptó posteriormente para su implementación en el lado del servidor, pero pronto se extendió ampliamente en la interfaz, ya que se basó en JavaScript estándar.Las primeras implementaciones de la especificación AMD cargaron módulos en forma de texto, que luego fue ejecutado por la función eval (). Este enfoque tenía fallas significativas en términos de rendimiento, seguridad y era difícil de depurar. Estos problemas fueron resueltos por la biblioteca requirejs, que carga módulos utilizando elementos SCRIPT generados mediante programación.Tratemos de averiguar quién fue el autor de esta idea. En las primeras versiones de la biblioteca hay un enlace al repositorio James Burke (ahora la biblioteca en sí no está en este repositorio):
La búsqueda de enlaces nos lleva a Twitter por twitter.com/jrburke , el ya mencionado repositorio github.com/jrburke y el perfil de Linkedin www.linkedin.com/in/james-burke-7994a11 . Además, en el dominio público hay una actuación del autor en la conferencia VanJS 2013 (sí, anteriormente no había conferencias glamorosas):El desarrollador de la biblioteca requirejs ideó una forma ingeniosa de cargar módulos de acuerdo con la especificación AMD, sin ir más allá del JavaScript estándar en ese momento, que es su mérito indudable. Pero también hubo desventajas. La sintaxis para usar módulos AMD es bastante complicada, por lo que el grupo CommonJS se ha negado. Cargar una gran cantidad de módulos pequeños ralentiza la carga de una página web. Pronto, los enlazadores gruñeron, tragaron, webpack y otros aparecieron que negaban los beneficios de usar la biblioteca requirejs. En general, podríamos caracterizar a esta biblioteca como una herramienta que distrajo a algunos desarrolladores, que hasta el último seguían con vanillajs js, de la transición al nuevo estándar JavaScript.Continuará