Зал Трудовой Славы JavaScipt09.05.2020 11:52

?v=1

С появлением библиотек JavaScript, которые разрабатываются большими коллективами, таких как Angular, React, Vue, — безвозвратно ушли с арены гении-одиночки, которые разрабатывали всю или, по крайней мере, основную часть библиотеки самостоятельно. Предлагаю вместе вспомнить названия этих библиотек, и, наконец, узнать имена их разработчиков.

2005 год — Prototype.js


Библиотека вышла в 2005 году как часть проекта Ruby-on-Rails. Первым разработчиком библиотеки был Sam Stephenson (см. www.sergiopereira.com/articles/prototype.js.html). В лицензии Prototype.js (см. prototypejs.org/license.html) есть ссылка на его персональную страничку sstephenson.us, на которой, в свою очередь, опубликован email автора: sstephenson@gmail.com.

Дальнейшие поиски по email приводят к его активному репозитарию github.com/sstephenson и твиттеру twitter.com/sstephenson (твиттер не публичный). Также о нем можно узнать, что он работает на позиции Programmer at Basecamp, и посмотреть видео доклада с конференции RubyConf 2016

В библиотеке Prototype.js впервые сложился «джентельментский набор» всех последующих библиотек того времени: доступ к DOM через функцию $(…), Ajax-запросы. Но главным был мощный прорыв в сторону «функциональщины» путем реализации интерфейса Enumerable (all (), any (), collect (), detect (), each () и т.д.). Фактически, с распространением именно этой библиотеки, программирование на JavaScript приобрело современный стиль. Некоторые идеи Prototype.js вошли в стандарт языка, и были повторены в более поздних библиотеках underscore.js и lodash.js.

Есть у библиотеки Prorotype.js и два существенных недостатка. Реализация новой функциональности базировалась на подмешивании новых свойств и методов в нативные объекты. Например, именно из-за этой строчки мы навсегда перестали пользоваться циклом for…in для перебора элементов массива: 

// Prototype.js v 1.5.0
Object.extend(Array.prototype, Enumerable);


Также проблемным является определение в библиотеке Prototype.js большого количества переменных с глобальной областью видимости: 

/*  Prototype JavaScript framework, version 1.5.0
 *  (c) 2005-2007 Sam Stephenson
 *
 *  Prototype is freely distributable under the terms of an MIT-style license.
 *  For details, see the Prototype web site: http://prototype.conio.net/
 *
/*--------------------------------------------------------------------------*/

var Prototype = {
  Version: '1.5.0',
  BrowserFeatures: {
    XPath: !!document.evaluate
  },

  ScriptFragment: '(?:)((\n|\r|.)*?)(?:<\/script>)',
  emptyFunction: function() {},
  K: function(x) { return x }
}

var Class = {
  create: function() {
    return function() {
      this.initialize.apply(this, arguments);
    }
  }
}
...


Как исправление этих двух просчетов позиционировалась библиотека jquery, к которой мы еще возможно вернемся.

2010 год — requirejs


Первые версии JavaScript не имели поддержки модулей, так как переменные и функции, определенные на вернем уровне имели глобальную область видимости (а не локальную внутри модуля, файла), и не было механизма загрузки зависимых модулей. В январе 2009 года Kevin Dangoor опубликовал блог-пост Blue Sky on Mars, с которого началась дискуссия о путях перенесения JavaScript на сервер. В какой-то момент появилась идея API wiki.commonjs.org/wiki/Modules/AsynchronousDefinition (AMD), который позволял бы асинхронно загружать зависимые модули, не выходя за рамки стандартного (на 2009 год) JavaScript. Это API впоследствии не было принято к реализации на стороне сервера, но вскоре широко распространилось на фронтенде, так как было основано на стандартном JavaScript.

Первые реализации спецификации AMD загружали модули в виде текста, который потом выполнялся функцией eval (). Такой подход имел существенные недостатки в плане производительности, безопасности и был сложен в отладке. Перечисленные проблемы решила библиотека requirejs, которая загружает модули при помощи программно сгенерированных элементов SCRIPT.

Попробуем разобраться, кто был автором этой идеи. В первых версиях библиотеки есть ссылка на репозитарий James Burke (сейчас в этом репозитарии нет самой библиотеки): 

/** vim: et:ts=4:sw=4:sts=4
 * @license RequireJS 0.27.1 Copyright (c) 2010-2011, The Dojo Foundation All Rights Reserved.
 * Available via the MIT or new BSD license.
 * see: http://github.com/jrburke/requirejs for details
 */
/*jslint strict: false, plusplus: false, sub: true */
/*global window: false, navigator: false, document: false, importScripts: false,
  jQuery: false, clearInterval: false, setInterval: false, self: false,
  setTimeout: false, opera: false */


Поиск ссылок приводит нас к твиттеру автора twitter.com/jrburke, уже упомянутому репозиторию github.com/jrburke и профилю Libkedin www.linkedin.com/in/james-burke-7994a11. Также, в публичном доступе есть выстоупление автора на конференции VanJS 2013 (да были раньше не гламурные конференции):


Разработчик библиотеки requirejs придумал остроумный способ загрузки модулей по спецификации AMD, не выходя за рамки стандартного на то время JavaScript, в чем ее несомненная заслуга. Но были и недостатки. Синтаксис использования AMD модулей довольно сложный, за что от него отказалась группа CommonJS. Загрузка большого количества мелких модулей замедляет загрузку веб-страницы. Вскоре появились компоновщики grunt, gulp, webpack и другие, которые свели на нет преимущества от использования библиотеки requirejs. В целом, можно было бы охарактеризовать эту библиотеку, как инструмент, который отвлек часть разработчиков, до последнего державшихся за vanillajs js от перехода на новый стандарт JavaScript.

© Habrahabr.ru