С появлением библиотек JavaScript, которые разрабатываются большими коллективами, таких как Angular, React, Vue, — безвозвратно ушли с арены гении-одиночки, которые разрабатывали всю или, по крайней мере, основную часть библиотеки самостоятельно. Предлагаю вместе вспомнить названия этих библиотек, и, наконец, узнать имена их разработчиков.
Библиотека вышла в 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 большого количества переменных с глобальной областью видимости:
Как исправление этих двух просчетов позиционировалась библиотека jquery, к которой мы еще возможно вернемся.
Первые версии 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 (сейчас в этом репозитарии нет самой библиотеки):
Поиск ссылок приводит нас к твиттеру автора twitter.com/jrburke, уже упомянутому репозиторию github.com/jrburke и профилю Linkedin www.linkedin.com/in/james-burke-7994a11. Также, в публичном доступе есть выстоупление автора на конференции VanJS 2013 (да были раньше не гламурные конференции):
Разработчик библиотеки requirejs придумал остроумный способ загрузки модулей по спецификации AMD, не выходя за рамки стандартного на то время JavaScript, в чем ее несомненная заслуга. Но были и недостатки. Синтаксис использования AMD модулей довольно сложный, за что от него отказалась группа CommonJS. Загрузка большого количества мелких модулей замедляет загрузку веб-страницы. Вскоре появились компоновщики grunt, gulp, webpack и другие, которые свели на нет преимущества от использования библиотеки requirejs. В целом, можно было бы охарактеризовать эту библиотеку, как инструмент, который отвлек часть разработчиков, до последнего державшихся за vanillajs js от перехода на новый стандарт JavaScript.
Продолжение следует
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: '(?:<script.*?>)((\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 и профилю Linkedin www.linkedin.com/in/james-burke-7994a11. Также, в публичном доступе есть выстоупление автора на конференции VanJS 2013 (да были раньше не гламурные конференции):
Разработчик библиотеки requirejs придумал остроумный способ загрузки модулей по спецификации AMD, не выходя за рамки стандартного на то время JavaScript, в чем ее несомненная заслуга. Но были и недостатки. Синтаксис использования AMD модулей довольно сложный, за что от него отказалась группа CommonJS. Загрузка большого количества мелких модулей замедляет загрузку веб-страницы. Вскоре появились компоновщики grunt, gulp, webpack и другие, которые свели на нет преимущества от использования библиотеки requirejs. В целом, можно было бы охарактеризовать эту библиотеку, как инструмент, который отвлек часть разработчиков, до последнего державшихся за vanillajs js от перехода на новый стандарт JavaScript.
Продолжение следует