GitHub.com начал использовать jQuery 1.2.1 в конце 2007 года, за год до того, как Google выпустил браузер Chrome. Не существовало стандартного способа запроса элементов DOM с помощью селекторов CSS или динамического рендеринга стилей для элементов, а интерфейс XMLHttpRequest в Internet Explorer, как и многие другие API, имел несоответствия между браузерами.
jQuery делает манипулирование DOM, создание анимации и запросы «AJAX» довольно простыми и, по сути, позволяет веб-разработчикам создавать более современные и динамичные веб-интерфейсы. Лучше всего то, что код, разработанный для одного браузера с помощью jQuery, работает и в других браузерах. На заре GitHub jQuery позволял небольшим командам разработчиков быстро создавать прототипы и разрабатывать новые функции без необходимости настраивать код специально для каждого веб-браузера.
Библиотеки расширений, основанные на простом интерфейсе jQuery, также стали основными строительными блоками интерфейса GitHub.com: pjax (https://github.com/defunkt/jquery-pjax) и facebox (https://github.com/defunkt/facebox). ).
Мы никогда не забудем такую полезную базовую библиотеку, созданную и поддерживаемую Джоном Резигом и участниками jQuery.
Более поздние веб-стандартыЗа прошедшие годы GitHub превратился в компанию с сотнями инженеров и постепенно сформировал специальную команду, отвечающую за размер и качество кода JavaScript. Мы исключили технический долг, и иногда технический долг растет вместе с зависимостями, которые дают нам некоторую ценность в начале, но со временем эта ценность также снижается.
Мы можем сравнить jQuery с быстрой эволюцией веб-стандартов, поддерживаемых современными браузерами:
-
Шаблон $(селектор) можно заменить на querySelectorAll();
-
Теперь вы можете использовать Element.classList для реализации переключения имени класса CSS;
-
CSS теперь поддерживает определение визуальной анимации в таблицах стилей вместо JavaScript;
-
Запросы $.ajax теперь можно выполнять с помощью Fetch Standard;
-
Интерфейс addEventListener() достаточно стабилен для использования на разных платформах;
-
Мы можем использовать облегченную библиотеку для инкапсуляции шаблона делегирования событий;
-
По мере роста языка JavaScript часть синтаксического сахара, предоставляемого jQuery, стала избыточной.
Кроме того, синтаксис цепочки не работает так, как мы хотим писать код. Например:
$('.js-widget')
.addClass('is-loading')
.show()
скопировать код
Этот синтаксис прост в написании, но по нашим стандартам он не очень хорошо передает наши намерения. Ожидает ли автор один или несколько элементов js-widget на текущей странице? Кроме того, если мы обновим разметку страницы и случайно пропустим имя класса js-widget, выдаст ли браузер исключение, сообщающее нам, что пошло не так? По умолчанию jQuery пропускает все выражение, когда ничего не соответствует селектору, но для нас это было ошибкой.
Наконец, мы начали аннотировать типы с помощью Flow для выполнения статической проверки типов во время сборки и обнаружили, что синтаксис цепочки не подходит для статического анализа, поскольку почти все методы jQuery возвращают один и тот же тип. В то время мы выбрали Flow, потому что такие функции, как слабый шаблон @flow, позволяли нам постепенно применять типы к нетипизированным кодовым базам.
В целом, удаление jQuery означает, что мы можем больше полагаться на веб-стандарты, сделать веб-документацию MDN де-факто по умолчанию для разработчиков интерфейсов, поддерживать более отказоустойчивый код в будущем и удалить 30 КБ зависимостей из наших пакетов. Удалено из пакета для ускорения загрузки страниц и выполнения JavaScript.
пошаговая развязкаХотя конечная цель поставлена, мы также знаем, что невозможно сразу выделить все ресурсы для удаления jQuery. Эта спешка может привести к ухудшению функциональности веб-сайта. Вместо этого мы приняли следующую стратегию:
1. Настройте метрику, отслеживайте скорость, с которой jQuery вызывается для всей строки кода, и следите за тем, как метрика меняется с течением времени, чтобы убедиться, что она остается неизменной или снижается, а не растет.
2. Мы не рекомендуем импортировать jQuery в любой новый код. Для облегчения автоматизации мы создали eslint-plugin-jquery (https://github.com/dgraham/eslint-plugin-jquery), если кто-то попытается использовать функции jQuery, такие как $.ajax, проверки CI не пройдут.
3. В старом коде много нарушений правил eslint, которые мы аннотировали конкретными правилами eslint-disable в комментариях к коду. Читатели, увидевшие этот код, должны знать, что он не соответствует нашим текущим методам кодирования.
4. Мы создали бота запроса на включение, который оставит комментарий к запросу на включение, когда кто-то попытается добавить новое правило eslint-disable. Это позволяет нам заранее проводить проверки кода и предлагать альтернативы.
5. Много старого кода использовало плагины pjax и facebox, поэтому мы повторно реализовали их логику внутри с помощью JS, сохранив их интерфейсы практически без изменений. Статическая проверка типов помогает повысить нашу уверенность в рефакторинге.
6. Много унаследованного кода взаимодействует с поведением rails, наши адаптеры Ruby on Rails — это в значительной степени «ненавязчивый» JS, который прикрепляет обработчики жизненного цикла AJAX к некоторым формам:
// 旧方法
$(document).on('ajaxSuccess', 'form.js-widget', function(event, xhr, settings, data) {
// 将响应数据插入到 DOM 中
})
скопировать код
7. Вместо того, чтобы переписывать все вызовы сразу, мы решили запускать поддельные события жизненного цикла ajax* и сохранять эти формы, отправляющие содержимое асинхронно, как и раньше, просто используя внутреннюю функцию fetch().
8. Мы сами поддерживаем версию jQuery, и всякий раз, когда мы обнаруживаем, что модуль jQuery нам больше не нужен, мы удаляем его из пользовательской версии и выпускаем более легкую версию. Например, после удаления псевдоселекторов CSS jQuery (таких как :visible или :checkbox) мы можем удалить модуль Sizzle, и мы можем удалить AJAX, когда все вызовы $.ajax заменены модулем fetch().
Это служит двум целям: ускорить выполнение JavaScript, гарантируя, что никакой новый код не попытается использовать удаленную функциональность.
9. Мы прекращаем поддержку старых версий Internet Explorer как можно скорее на основании результатов анализа нашего веб-сайта. Всякий раз, когда определенная версия IE падает ниже определенного порога, мы прекращаем предоставлять поддержку JavaScript и сосредотачиваемся на поддержке более современных браузеров. Отказ от поддержки IE 8 и IE 9 на раннем этапе означает, что мы можем использовать множество нативных функций браузера, которые в противном случае было бы трудно реализовать полифиллом.
10. В рамках нашего нового подхода к разработке функций внешнего интерфейса на GitHub.com мы сосредоточились на максимально возможном использовании обычного HTML и постепенном добавлении поведения JavaScript в качестве прогрессивного улучшения. В результате веб-формы и другие элементы пользовательского интерфейса, улучшенные с помощью JS, часто хорошо работают в браузерах, в которых отключен JavaScript. В некоторых случаях мы можем полностью удалить устаревший код, не переписывая его на JS.
С годами мы постепенно уменьшали нашу зависимость от jQuery до тех пор, пока на нее не ссылалась ни одна строка кода.
пользовательский элементНовая технология, получившая широкое распространение в последние годы, — это настраиваемые элементы — библиотека компонентов, встроенных в браузер, что означает, что пользователям не нужно загружать, анализировать и компилировать лишние байты.
С 2014 года мы создали несколько пользовательских элементов на основе спецификации v0. Однако, поскольку стандарты все еще меняются, мы не приложили к этому особых усилий. Только в 2017 году, когда была выпущена спецификация веб-компонентов v1, а Chrome и Safari реализовали ее, мы начали более широко внедрять пользовательские элементы.
Во время удаления jQuery мы также искали шаблоны для извлечения пользовательских элементов. Например, мы преобразовали лицевую панель, используемую для отображения модального диалога, в элемент
Наша философия прогрессивного улучшения также распространяется на пользовательские элементы. Это означает, что мы сохраним как можно больше разметки, прежде чем добавлять в разметку поведение. Например,
Ниже приведен пример реализации пользовательского элемента
// local-time 根据用户的当前时区显示时间。
//
// 例如:
// <local-time datetime="2018-09-06T08:22:49Z">Sep 6, 2018</local-time>
//
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)
}
скопировать код
Мы с нетерпением ждем Shadow DOM для веб-компонентов. Мощь Shadow DOM открывает множество возможностей для Интернета, но также усложняет полифиллинг. Из-за потери производительности при использовании полифиллов их использование в производственной среде невозможно.
Английский оригиналhttps://githubengineering.com/removing-jquery-from-github-frontend/
Рекомендация по активности7-8 декабря в Пекинском международном конференц-центре пройдет саммит ArchSummit Global Architect.Темы конференции будут посвящены микросервисной финансовой архитектуре, микросервисной архитектуре, построению платформы инфраструктуры данных, короткой видеоархитектуре, блокчейну, информационная конфиденциальность и безопасность и др. тема. Приглашены технические специалисты из Alibaba, Netflix, Baidu, LinkedIn и других компаний.
Если у вас есть какие-либо вопросы, пожалуйста, свяжитесь с менеджером по продаже билетов Lachel-Grey, тел/WeChat: 17326843116.