Com o advento das bibliotecas JavaScript desenvolvidas por grandes equipes, como Angular, React, Vue, deixaram irreversivelmente a arena, gênios únicos que desenvolveram toda ou pelo menos a parte principal da biblioteca por conta própria. Sugiro lembrar os nomes dessas bibliotecas juntos e, finalmente, descobrir os nomes de seus desenvolvedores.2005 - Prototype.js
A biblioteca foi lançada em 2005 como parte do projeto Ruby-on-Rails. O primeiro desenvolvedor da biblioteca foi Sam Stephenson (consulte www.sergiopereira.com/articles/prototype.js.html ). A licença Prototype.js (consulte prototypejs.org/license.html ) possui um link para sua página pessoal sstephenson.us , que, por sua vez, publicou o email do autor: sstephenson@gmail.com.Outras pesquisas por email resultam em seu repositório ativo github.com/sstephenson e twitter.com/sstephenson ( twitter não público). Você também pode aprender sobre ele que ele trabalha como programador no Basecamp e assistir a um relatório em vídeo da conferência RubyConf 2016Pela primeira vez, a biblioteca Prototype.js desenvolveu um "conjunto de cavalheiros" de todas as bibliotecas subseqüentes da época: acesso ao DOM por meio da função $ (...), solicita o Ajax. Mas o principal foi um avanço poderoso em direção ao “funcionalismo” implementando a interface Enumerable (all (), any (), collect (), detect (), each (), etc.). De fato, com a expansão dessa biblioteca específica, a programação JavaScript adquiriu um estilo moderno. Algumas idéias do Prototype.js entraram no padrão da linguagem e foram repetidas nas bibliotecas posteriores underscore.js e lodash.js.A biblioteca Prorotype.js tem duas desvantagens significativas. A implementação da nova funcionalidade foi baseada na mistura de novas propriedades e métodos em objetos nativos. Por exemplo, foi por causa dessa linha que paramos para sempre de usar o loop for ... in para iterar sobre os elementos da matriz:
Object.extend(Array.prototype, Enumerable);
Também problemática é a definição de um grande número de variáveis com escopo global na 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 uma correção desses dois erros de cálculo, a biblioteca jquery foi posicionada, à qual podemos retornar.2010 - requirejs
As primeiras versões do JavaScript não tinham suporte para módulo, pois as variáveis e funções definidas no nível superior tinham um escopo global (e não local no módulo, arquivo) e não havia mecanismo para carregar módulos dependentes. Em janeiro de 2009, Kevin Dangoor publicou um post chamado Blue Sky on Mars, que iniciou uma discussão sobre maneiras de portar o JavaScript no servidor. Em algum momento, surgiu a idéia da API wiki.commonjs.org/wiki/Modules/AsynchronousDefinition (AMD), que permitiria carregar módulos dependentes de forma assíncrona, sem ir além do JavaScript padrão (para 2009). Essa API não foi aceita posteriormente para implementação no lado do servidor, mas logo se espalhou amplamente no frontend, pois era baseada no JavaScript padrão.As primeiras implementações da especificação AMD carregaram módulos na forma de texto, que foram executados pela função eval (). Essa abordagem apresentava falhas significativas em termos de desempenho, segurança e era difícil de depurar. Esses problemas foram resolvidos pela biblioteca requirejs, que carrega módulos usando elementos SCRIPT gerados programaticamente.Vamos tentar descobrir quem foi o autor dessa ideia. Nas primeiras versões da biblioteca, há um link para o repositório James Burke (agora a biblioteca em si não está neste repositório):
A busca de links nos leva ao Twitter pelo twitter.com/jrburke , o repositório github.com/jrburke já mencionado e o perfil do Linkedin www.linkedin.com/in/james-burke-7994a11 . Além disso, no domínio público, há uma atuação do autor na conferência VanJS 2013 (sim, anteriormente não havia conferências fascinantes):O desenvolvedor da biblioteca requirejs criou uma maneira engenhosa de carregar módulos de acordo com a especificação da AMD, sem ir além do JavaScript padrão da época, que é seu mérito indiscutível. Mas também havia desvantagens. A sintaxe para o uso de módulos AMD é bastante complicada, para a qual o grupo CommonJS se recusou. Carregar um grande número de módulos pequenos diminui o carregamento de uma página da web. Logo, os vinculadores grunhiram, gulp, webpack e outros pareciam negar os benefícios do uso da biblioteca requirejs. Em geral, pode-se caracterizar essa biblioteca como uma ferramenta que distraiu alguns desenvolvedores, que até o último mantiveram o vanillajs js, da mudança para o novo padrão JavaScript.Continua