Не так давно GitHub полностью перестал использовать jQuery в своём фронтенд-коде. Мы перевели пост, в котором разработчики рассказывают, с чего началась их работа с jQuery, как они поняли, что пора от него отказываться, и как они смогли сделать это без использования других библиотек или фреймворков.
Зачем jQuery был нужен раньше?
jQuery 1.2.1 вошёл в число зависимостей GitHub в конце 2007 года. Это произошло за год до того, как Google выпустил первую версию браузера Chrome. На тот момент не было общепринятого способа обращаться к элементам DOM с помощью CSS-селектора, не было стандартного способа добавить анимацию к стилю элемента, а интерфейс XMLHttpRequest, предложенный Internet Explorer, как и многие API, был плохо совместим с браузерами.
С jQuery стало гораздо проще управлять DOM, создавать анимации и делать AJAX-запросы. У веб-разработчиков появилась возможность создавать более современные, динамические сайты, которые выделялись среди остальных. Самое главное, все функции JavaScript, проверенные в одном браузере с помощью jQuery, как правило, работали и в других браузерах. На заре GitHub, когда большинство его функций только обретали форму, появление jQuery позволило небольшой команде разработчиков быстро создавать прототипы и представлять новые функции без необходимости подстраивать их отдельно под каждый браузер.
Простой интерфейс jQuery также послужил основой для создания библиотек, которые в будущем стали компонентами остальной части фронтенда GitHub.com: pjax и facebox.
Веб-стандарты в последующие годы
С течением времени GitHub превратился в компанию с сотнями разработчиков и постепеннно сформировалась команда, которая отвечала за размер и качество JavaScript-кода, который мы отправляем браузерам. Одна из вещей, за которыми мы постоянно следим, — технический долг, порой вырастающий из некогда полезных зависимостей, которые потеряли свою актуальность по прошествии времени.
techbyteshub.com
Когда очередь дошла до jQuery, мы сравнили его с развивающимся веб-стандартом в браузерах и поняли, что:
Шаблон $(selector) можно легко заменить на querySelectorAll();
Переключение CSS-классов теперь можно осуществить с помощью Element.classList;
CSS теперь поддерживает создание анимации в таблицах стилей, а не в JavaScript;
$.ajax-запросы можно выполнять с помощью Fetch Standard;
Интерфейс addEventListener() достаточно стабилен для кроссплатформенного использования;
Шаблон делегирования событий легко инкапсулировать с помощью легковесной библиотеки;
С эволюцией JavaScript часть синтаксического сахара jQuery устарела.
Кроме того, синтаксис цепочек команд не удовлетворял нашим представлениям о коде, который мы хотели бы писать в будущем. Например:
$(‘.js-widget’)
.addClass(‘is-loading’)
.show()
Такой синтаксис прост в написании, однако по нашим стандартам не очень хорошо передаёт намерения автора. Сколько элементов js-widget, по его задумке, должно быть на странице: один или больше? А если мы обновим разметку страницы и случайно оставим имя класса js-widget, будет ли выброшено исключение, которое сообщит нам, что что-то пошло не так? По умолчанию jQuery молча пропускает всё выражение, когда нет совпадений по начальному селектору; однако для нас такое поведение было больше багом, нежели фичей.
Наконец, нам хотелось начать аннотировать типы с Flow, чтобы проводить статическую проверку типов во время сборки, и мы пришли к выводу, что синтаксис цепочек плохо поддаётся статическому анализу, так как почти каждый результат вызова метода jQuery одного и того же типа. Из возможных вариантов мы выбрали именно Flow, так как тогда такие возможности, как режим @flow weak, позволили нам начать прогрессивно и эффективно применять типы к кодовой базе, которая по большей части была нетипизированной.
В конечном счёте отказ от jQuery означает, что мы можем больше полагаться на веб-стандарты, использовать веб-документацию MDN в качестве официальной документации для наших фронтендеров, поддерживать более гибкий код в будущем и уменьшить вес наших зависимостей на 30 Кбайт, что в итоге увеличит скорость загрузки страницы и выполнения JavaScript.
Постепенный переход
Хотя наша конечная цель была не за горами, мы знали, что было бы нецелесообразно направить все имеющиеся ресурсы на переписывание всего с jQuery на чистый JS. Во всяком случае, такое поспешное решение негативно бы сказалось на функциональности сайта, от которой нам бы пришлось отказаться. Вместо этого мы:
Начали отслеживать количество вызовов jQuery на строку кода и следили за графиком на протяжении времени, чтобы убедиться, что он либо не меняется, либо падает, но не растёт.
Отказались от использования jQuery в новом коде. Чтобы достичь этого с помощью автоматизации, мы создали eslint-plugin-jquery, который проваливал CI-тесты при попытке использовать возможности jQuery вроде $.ajax.
В старом коде появилось много нарушений правил eslint, которые мы пометили с помощью специальных правил eslint-disable в комментариях. Для того, кто будет это читать, такие комментарии должны были служить явным сигналом того, что здесь не отражаются наши текущие методы написания кода
Мы написали бота, который при отправке pull request’а оставлял комментарий, сигнализирующий нашей команде каждый раз, как кто-то хотел добавить новое правило eslint-disable. Таким образом мы могли провести ревью кода на ранней стадии и предложить альтернативы.
Большая часть старого кода была явно связана с внешними интерфейсами jQuery-плагинов pjax и facebox, поэтому мы оставили их интерфейсы почти без изменений, в то время как изнутри заменили их реализацией на чистом JS. Наличие статической проверки типов вселило в нас уверенность в проводимом рефакторинге.
Много старого кода было связано с rails-behaviors, нашим адаптером для Ruby on Rails, таким образом, что он присоединял обработчик жизненного цикла AJAX к определённым формам:
// УСТАРЕВШИЙ ПОДХОД
$(document).on(‘ajaxSuccess’, ‘form.js-widget’, function(event, xhr, settings, data) {
// вставка данных ответа куда-нибудь в DOM
})
Вместо того чтобы переписывать все эти вызовы согласно новому подходу, мы решили использовать ложные события жизненного цикла ajax*, и формы продолжали отправлять данные асинхронно, как и раньше; только теперь изнутри использовался fetch().
Мы поддерживали свою сборку jQuery, из которой убирали ненужные нам модули и заменяли более лёгкой версией. Например, после избавления от всех jQuery-специфичных CSS-псевдоселекторов вроде :visible или :checkbox мы смогли убрать модуль Sizzle; а когда мы заменили $.ajax-вызовы на fecth(), мы смогли отказаться от модуля AJAX. Мы убивали двух зайцев разом: уменьшали время выполнения JavaScript, параллельно гарантируя то, что никто не напишет код, который будет пытаться использовать удалённую функциональность.
Глядя на статистику нашего сайта, мы старались прекратить поддержку Internet Explorer настолько быстро, насколько это возможно. Как только использование определённой версии IE падало ниже определённого порога, мы прекращали её поддержку и фокусировались на более современных браузерах. Отказ от поддержки IE 8-9 на раннем этапе позволил нам использовать многие нативные возможности браузеров, которые в противном случае было бы сложно «заполифиллить».
В рамках нашего усовершенствованного подхода к написанию фронтенда GitHub мы сосредоточились на использовании обычного HTML по-максимуму, добавляя JavaScript в качестве последовательного улучшения. В итоге даже те формы и другие элементы интерфейса, которые были улучшены с помощью JS, как правило, могли работать даже с выключенным в браузере JavaScript. В некоторых случаях нам даже удалось удалить определённую устаревшую функциональность вместо её переписывания на чистом JS.
Благодаря этим и аналогичным усилиям с течением времени мы постепенно смогли уменьшить нашу зависимость от jQuery вплоть до того момента, когда не осталось ни одной строки кода, ссылающейся на эту библиотеку.
Custom Elements: пользовательские элементы
Одна технология, наделавшая шуму в последние годы, — Custom Elements: библиотека компонентов, встроенная в браузер, что означает отсутствие необходимости для пользователя качать, парсить и компилировать дополнительные байты фреймворка.
Мы создали несколько пользовательских элементов на основе спецификации v0 с 2014 года. Однако, поскольку стандарты в то время постоянно менялись, мы сильно в это не вкладывались. А начали только с 2017 года, когда была выпущена спецификация Web Components v1, реализованная как в Chrome, так и в Safari.
Во время перехода с jQuery мы искали структуры, которые можно было бы извлечь в качестве пользовательских элементов. Например, мы преобразовали код facebox, использованный для отображения модальных диалогов, в элемент .
Наша общая философия прогрессивного улучшения относится и к пользовательским элементам. Это значит, что мы стараемся хранить как можно больше контента в разметке и только добавлять поведение поверх неё. Например, по умолчанию показывает исходную временную метку, но с улучшением может переводить время в местный часовой пояс, а , расположенный внутри элемента
Вот пример того, как можно реализовать элемент :
// Элемент local-time отображает время в текущем
// часовом поясе и местоположении пользователя.
//
// Пример:
// Sep 6, 2018
//
class LocalTimeElement extends HTMLElement {
static get observedAttributes() {
return [‘datetime’]
}
attributeChangedCallback(attrName, oldValue, newValue) {
if (attrName === ‘datetime’) {
const date = new Date(newValue)
this.textContent = date.toLocaleString()
}
}
}
if (!window.customElements.get(‘local-time’)) {
window.LocalTimeElement = LocalTimeElement
window.customElements.define(‘local-time’, LocalTimeElement)
}
Один из аспектов Web Components, который мы очень хотим перенять, — Shadow DOM. У Shadow DOM есть потенциал для раскрытия множества возможностей для веба, однако он также усложняет полифиллинг. Так как его полифиллинг на данный момент приведёт к снижению производительности даже для кода, который управляет частями DOM, не относящихся к веб-компонентам, для нас нецелесообразно использовать его в продакшне.
Полифиллы
Здесь вы можете увидеть полифиллы, которые помогли нам перейти к использованию встроенных возможностей браузера. Мы стараемся использовать их, только когда это совершенно необходимо, т.е. как часть отдельного JavaScript-бандла для совместимости с устаревшими браузерами.
github/eventlistener-polyfill
github/fetch
github/form-data-entries
iamdustan/smoothscroll
javan/details-element-polyfill
jonathantneal/closest
kumarharsh/custom-event-polyfill
marvinhagemeister/request-idle-polyfill
mathiasbynens/Array.from
mathiasbynens/String.prototype.codePointAt
mathiasbynens/String.prototype.endsWith
mathiasbynens/String.prototype.startsWith
medikoo/es6-symbol
nicjansma/usertiming.js
rubennorte/es6-object-assign
stefanpenner/es6-promise
webcomponents/template
webcomponents/URL
webcomponents/webcomponentsjs
WebReflection/url-search-params
yola/classlist-polyfill
Смотрите также: «Фундаментальные принципы объектно-ориентированного программирования на JavaScript»
Перевод статьи «Removing jQuery from GitHub.com frontend»
Добавить комментарий