Как стать автором
Обновить

Зал Трудовой Славы JavaScript

Время на прочтение4 мин
Количество просмотров6.2K
С появлением библиотек 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: '(?:<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.

Продолжение следует
Теги:
Хабы:
+7
Комментарии15

Публикации

Истории

Работа

Ближайшие события

Weekend Offer в AliExpress
Дата20 – 21 апреля
Время10:00 – 20:00
Место
Онлайн
Конференция «Я.Железо»
Дата18 мая
Время14:00 – 23:59
Место
МоскваОнлайн