На первый взгляд кнопка «наверх» — задача на пять минут. Добавил position: fixed, обработчик window.scrollTo() — готово.

Но стоит этой кнопке появиться в живом проекте, как выясняется, что она пересекается с cookie-баннером, мешает чату поддержки, выглядит иначе в мобильной версии, не дружит со строгим CSP или пропадает из Django Admin.

В итоге маленькая UI-деталь начинает обрастать условиями. Я решил собрать их в отдельный Django-пакет — django-scroll-to-top

Когда трёх строк JavaScript достаточно

Для небольшого сайта, где нет сложной верстки, админки, CSP и требований к повторному использованию, самый простой вариант действительно выглядит примерно так:

Это нормальное решение. Не всегда стоит тянуть пакет ради одной кнопки.

Но в реальном Django-проекте быстро появляются дополнительные вопросы:

• когда именно показывать кнопку: после 300 пикселей, одного экрана или только при прокрутке вверх;
• что делать на коротких страницах;
• как не перекрыть cookie-баннер, чат, toast-уведомления или нижнюю мобильную навигацию;
• как дать пользователю закрыть кнопку;
• как не сломать клавиатурную навигацию и режим reduced motion;
• как сделать отдельное оформление для сайта и Django Admin;
• как не заставлять проект добавлять unsafe-inline в Content Security Policy;
• как позволить редактору или администратору изменить цвет, положение и иконку без нового деплоя.

Именно в этот момент «три строки JavaScript» превращаются в отдельный компонент.

Что я хотел получить

Цель была не в том, чтобы сделать ещё одну стрелку в правом нижнем углу. Хотелось собрать переиспользуемый компонент со следующими свойствами:

1. Подключение сайта одной template-тегом.
2. Отдельная поддержка обычных страниц и стандартного Django Admin.
3. Настройка внешнего вида через админку, а не через постоянную правку CSS.
4. Без jQuery, CDN, фронтенд-фреймворка и обязательной сборки.
5. Безопасная работа при строгой CSP.
6. Прогрессивное улучшение: без JavaScript остаётся обычная ссылка в начало страницы.
7. Возможность жить рядом с другими фиксированными элементами интерфейса.

Пакет в итоге хранит обычные настройки установки в settings.py, а визуальное поведение — в базе данных. Это позволяет менять кнопку через Django Admin, публиковать новую версию настроек и при необходимости откатываться на предыдущую. В проекте есть отдельные профили для публичного сайта и Django Admin, а ревизии могут быть черновыми, опубликованными или архивными.

Быстрое подключение

Базовый сценарий начинается с установки:

В settings.py добавляем приложение. Если нужна поддержка стандартной админки, пакет должен идти раньше django.contrib.admin:

Включаем области, где должна работать кнопка:

Для публичной части добавляем URLConf пакета:

А в общий шаблон сайта — один тег:

На стандартном Django Admin ничего дополнительно вставлять не нужно: пакет использует обычный механизм разрешения шаблонов Django. Если же в проекте переопределён admin/base_site.html тег можно добавить вручную в блок footer

Настройка без превращения админки в редактор CSS

Мне не хотелось хранить в базе шаблоны, произвольный CSS или JavaScript. Это неудобно для сопровождения и создаёт лишнюю поверхность для ошибок.

Поэтому визуальная часть собрана из контролируемых вариантов:

• круг, квадрат, скруглённый квадрат или pill;
• заливка solid, outline, soft, ghost, glass или gradient;
• положение в любом углу экрана;
• отдельные размеры для desktop и mobile;
• светлая и тёмная тема;
• встроенные иконки, иконки от разработчика или загружаемые SVG;
• настройки тени, границы, opacity и focus ring.

Что происходит, когда рядом есть cookie-баннер или чат

Нижний правый угол страницы редко бывает свободен. Там часто живут:

• cookie-баннер;
• компактная кнопка после закрытия баннера;
• чат поддержки;
• кнопка обратного звонка;
• мобильная навигация;
• toast-уведомления.

Пакет умеет рассматривать такие элементы как препятствия. Для этого можно пометить элемент атрибутом:

Дальше для кнопки можно выбрать поведение: игнорировать препятствия, сдвинуться вдоль края, попробовать другой угол или скрыться, если безопасного места не осталось.

Для сложных виджетов есть отдельный адаптер: он может отслеживать появление и исчезновение элементов, например компактного launcher после закрытия cookie-баннера. При этом ни cookie-пакет, ни чат не становятся зависимостями django-scroll-to-top

Доступность — не отдельная галочка в конце

У кнопки есть понятное имя для screen reader, поддержка клавиатуры, видимый focus-visible, минимальный размер области нажатия и режим prefers-reduced-motion.

Если пользователь отключил анимации на уровне системы, плавная прокрутка не будет навязываться. Если JavaScript не загрузился, кнопка остаётся обычной ссылкой на начало документа.

Полный независимый аудит WCAG 2.2 AA и тестирование масштабирования 200% и 400% пока находятся в roadmap, поэтому называть компонент полностью сертифицированным по WCAG было бы неправильно. Но структурные требования — клавиатурная доступность, фокус, reduced motion, forced-colors и безопасная работа без JavaScript — уже заложены в компонент и покрываются тестами.

CSP и загружаемые SVG

В корпоративных проектах часто нельзя просто добавить inline-скрипт и включить unsafe-inline ради одной кнопки.

По умолчанию компонент использует same-origin CSS и JavaScript. Для него подходит политика такого вида:

Настраиваемые цвета и размеры отдаются не через inline-стили, а через версионированный stylesheet endpoint. Это позволяет сохранить простой контракт с одним template-тегом и не ослаблять CSP.

Отдельно пришлось подумать о загружаемых SVG. Админ не рендерит исходный файл как есть: SVG проходит санитарную обработку. Скрипты, обработчики событий, внешние ресурсы, встроенные документы и небезопасные namespace отклоняются. Для загружаемых иконок также хранится информация об авторе, источнике и лицензии.

Ревизии, публикация и откат

Одна из самых полезных вещей в пакете — не сама кнопка, а жизненный цикл её настроек.

Можно создать черновик, посмотреть результат в live preview, опубликовать изменения или вернуться к предыдущей версии. Это особенно удобно, когда кнопку настраивает не разработчик, а контент-менеджер или дизайнер.

У ревизий есть три состояния:

• draft — редактируемый черновик;
• published — текущая активная конфигурация;
• archived — сохранённая версия для отката.

Где пакет уместен, а где нет

django-scroll-to-top имеет смысл, когда кнопка нужна в нескольких проектах, должна работать в Django Admin, настраиваться без деплоя или жить в окружении со строгими требованиями к CSP и интерфейсу.

Для лендинга на одну страницу проще и правильнее написать несколько строк самостоятельно. Это будет быстрее, понятнее и дешевле в сопровождении.

Но если такая маленькая деталь начинает повторяться в нескольких продуктах, появляется необходимость поддерживать мобильную версию, доступность, независимые настройки для сайтов и админки, то отдельный компонент уже перестаёт быть избыточным.

Сейчас пакет выпущен как beta-версия 0.2.0, требует Python 3.10+ и поддерживает Django 4.2 LTS, 5.x и 6.0. Лицензия — MIT.

Исходный код, документация и примеры использования доступны в GitHub-репозитории проекта.

Пакет опубликован в PyPI под именем django-scroll-to-top.

Обратная связь, баг-репорты и предложения по интеграции с кастомными Django Admin-темами приветствуются в Issues.

Эта статья — подробная хроника эволюции программистов: какие языки и технологии они осваивали, как менялись их рабочие места, методы обучения и даже само восприятие профессии. Мы разберем ключевые этапы, от первых веб-гигантов до эпохи совместного программирования с ИИ, и попробуем представить, что ждет нас дальше.

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

Этот кейс хорошо иллюстрирует дух эпохи: отсутствие готовых безопасных решений заставляло программистов изобретать велосипеды. Многие подобные наработки позже легли в основу ORM-библиотек, но тогда они рождались в муках — через пробелы в безопасности и километры самописного кода.

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Это в корне неправильный подход. Устаревшие фреймворки и библиотеки не отвечают текущим требованиям к производительности, масштабируемости и адаптивности. Они не успевают за новейшими парадигмами и функциями, что неизбежно отражается на качестве создаваемых продуктов.

В нашем обзоре — 10 библиотек JavaScript, которым в 2025 году пора сказать «До свидания». Для каждого продукта из антирейтинга мы подобрали альтернативные варианты.

Фреймворки, которые утратили актуальность в 2025 году

jQuery

Это одна из первых библиотек JavaScript, которая из-за инерционного мышления все еще входит в некоторые списки самых популярных инструментов разработки. Пользователи ценят jQuery за кроссбраузерную поддержку, лаконичный синтаксис и простые алгоритмы взаимодействия с DOM.

Почему прогеры продолжают пользоваться библиотекой? Чисто технически jQuery присутствует во множестве сайтов, сделанных 10-15 лет назад (тогда этот код стал альтернативой VanillaJS). Библиотека создавалась, чтобы сделать язык более гибким и удобным в разработке.

Сегодня многие преимущества jQuery утратили свою актуальность — например, создание кода, работающего на всех браузерах. Теперь платформы стандартизированы, что делает кроссбраузерные решения библиотеки ненужными.

Кроме того, современные нативные API JavaScript серьезно улучшились — для подавляющего большинства задач, которые раньше выполнял jQuery, достаточно ванильного JS. Новейшие методики обеспечивают все манипуляции с DOM и взаимодействие веб -страницы с сервером (AJAX-запросы), поэтому необходимость в библиотеке отпадает.

В 2025 пришло время отпустить jQuery — его применение сейчас может привести к замедлению загрузки веб-страниц и приложений, а уж этого бы нам точно не хотелось.

Чем заменить

Нативного API JavaScript в ряде случаев будет достаточно для разработки, а для всех остальных ситуаций есть новые версии высокопроизводительных фреймворков React, Vue и Angular.

Lodash

Когда-то эта универсальная библиотека утилит считалась почти обязательной для каждого проекта на JavaScript. Здесь есть String — функция преобразования для обрезки и переноса в верхний регистр; Object — утилита для расширения и слияния; Array — для сжатия и изменения; многие другие фичи, включая глубокое клонирование объектов и манипуляции с массивами данных.

Библиотека Lodash помогала программистам писать более компактный, чистый и простой в обслуживании и поддержке код, конвертировать данные в различные форматы, выполнять математические операции. В настоящее для большинства таких операций утилиты не требуются.

Чем заменить

Сегодня многие функции, представленные в Lodash, есть в новой спецификации JavaScript E56. Оператор spread (…), методы Array (map, reduce, filter и прочие) решают те же задачи, которые некогда решал Lodash. В число главных недостатков библиотеки входит также ее большой вес — импорт всего одной функции увеличивает накладные расходы проекта.

Moment.js

Долгое время эта библиотека была основным инструментом для работы с датами. Ее сильными сторонами были:

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

Сейчас эта библиотека стала слишком тяжелой — даже в мини-формате она занимает 66 КБ, что излишне нагружает устройства, отражается на производительности и быстрой работе UX-функций. Есть более легкие пакеты с теми же функциями.

Чем заменить

Современная альтернатива — date-fns — набор функций для работы с датами на JavaScript, который не входит в библиотеки и работает независимо. Предусматривает модульный импорт — вы можете взять из пакета только то, что требуется для работы, тем самым снижая нагрузку.

Ещё один вариант — Luxon — новая библиотека для работы с датами, созданная командой Moment. Этот инструмент изначально позиционировался как замена предыдущему продукту компании как более мощное, современное и удобное средство. Здесь работа с часовыми поясами реализована без дополнительных расширений, применяется современный подход к написанию кода.

Кроме того, JavaScript Temporal API позволяет работать с датами и временем напрямую, не используя сторонние библиотеки. Поэтому любое из указанных трех решений делает применение Moment.js избыточным и ненужным.

RequireJS

Долгое время библиотека была для JavaScript-разработчиков основным инструментом для управления зависимостями. Технология асинхронного определения модулей (AMD) обеспечивала эффективную асинхронную загрузку файлов. Модульный принцип не использовался в других библиотеках и инструментах, что создавало ощущение эксклюзива.

Это был самый эффективный способ взаимодействия с зависимостями, особенно ценный в работе с большими приложениями. Совместимость со всеми популярными браузерами, включая Firefox, Safari, Chrome, Opera, а также веб-продуктами на Node, была еще одной сильной стороной библиотеки.

С появлением модулей в ES6 RequireJS утратила статус уникального инструмента. В новой спецификации JavaScript реализован нативный способ определения и импорта модулей. Такой подход делает синтаксис более интуитивным, ускоряет и упрощает разработку.

При этом RequireJS в сравнении с более свежими аналогами слишком сложен в настройке и применении. Он требует от прогеров ручной настройки загрузчика и управления путями зависимостей, что повышает риск ошибок и отнимает кучу времени. Современные загрузчики более расторопные и автоматизированные.

Чем заменить

Помимо ES6, с модулями успешно работает сборщик Webpack, компилируя их в единый файл. Это еще более эффективный инструмент, совместимый с TypeScript и Node.js. При запуске программа обрабатывает модули, выстраивает граф зависимостей между ними и на его основе генерирует общий файл.

У этого бендлера есть дополнительные продвинутые возможности — например, разделение кода, горячая замена модулей в реальном времени, а также операция tree shaking (встряхивание дерева), то есть удаление мертвого кода из продукта. Webpack делает работу с зависимостями более рациональной и полностью заменяет тяжелый и устаревший RequireJS.

Backbone.js

Одна из первых библиотек JS (выпущена в 2010), основанная на шаблоне проектирования Model-View-Controller. Предназначена, в основном, для разработки пользовательских интерфейсов и структурирования веб-приложений.

Некогда Backbone.js считался легковесным и функциональным инструментом, который упрощал работу с кодом, улучшал синхронизацию приложения с сервером и позволял создавать эффективный клиентский код.

Со временем у фреймворка стали проявляться ограничения. Например, отсутствие механизма двусторонней привязки данных. Такая опция есть у многих современных библиотек, поэтому разработчикам не приходится при каждом обновлении или изменении модели вручную настраивать DOM и множить шаблонный код. Все прогеры в курсе, что ручные операции существенно повышают риск ошибок.

Кроме того, в Backbone.js нет собственного шаблонизатора, что вынуждает применять другие библиотеки типа Handlebars.js.

Чем заменить

Достойных вариантов замены достаточно. Это React с его архитектурой, основанной на компонентах, и виртуальным DOM. Это и Vue.js с двусторонней привязкой данных и гибкой архитектурой. Это также универсальный Angular с теми же функциями.

Modernizr

Библиотека обнаружения особенностей HTML5 и CSS3 в браузере пользователя. В свое время была крайне полезной и обеспечивала работу приложений в разных браузерах.

С появлением транпислеров (программ, которые переводят части кода с одного языка программирования на другой) необходимость в Modernizr существенно снизилась. Более того, использование этого инструмента чревато увеличением расходов на приложения. Разработчикам приходится задействовать множество тестов на обнаружение функций, что замедляет загрузку.

Чем заменить

Компилятор (транспилер) JavaScript Babel успешно решает задачу преобразования современного кода в формат, совместимый со старыми версиями браузеров. Кроме того, Babel — полифил, то есть способен заполнять пробелы в скрипте с целью добавления новых функций.

MooTools

Объектно-ориентированный фреймворк, некогда популярный и безальтернативный. MooTools содержит комплект утилит для работы с DOM, событиями и AJAX-запросами. Сильными сторонами библиотеки был объектно-ориентированный подход и лаконичный синтаксис. Разрабы, предпочитающие писать элегантный и ясный код, были от MooTools в восторге.

Однако постепенно все преимущества фреймворка нивелировались — сообщество так и не дождалось существенных обновлений и перешло на более прогрессивные инструменты. В сравнении с ними MooTools занимает много места, что негативно сказывается на приложениях, где важна производительность (а сегодня она важна везде).

Чем заменить

В современной версии Vanilla JavaScript реализована большая часть функций, представленных в MooTools, в том числе методы для работы с DOM и для обработки событий.

Что касается полноценных библиотек, то MooTools без проблем заменят React или Vue.js. Это простые в освоении и использовании прогрессивные фреймворки для разработки пользовательских интерфейсов.

Script.aculo.us

Библиотека визуальных эффектов и методов управления пользовательским интерфейсом. Была популярна у разработчиков, работающих с анимацией и интерактивными опциями в приложениях. Сильные стороны Script.aculo.us — простота в применении, обширный ассортимент возможностей — перетаскивание, сортировка, слайдеры и т.д.

Отсутствие значительных обновлений и большой вес были факторами, которые ослабили позиции Script.aculo.us в сообществе. Если в 2025 году в мире еще остались программисты, которые пользуются этой библиотекой, им точно пора осваивать новые инструменты.

Чем заменить

GreenSock — более мощная, быстрая и универсальная библиотека анимации с огромным выбором эффектов и элементов управления. Работает на стороне клиента и сервера, совместима со всеми браузерами.

Anime.js — еще один гибкий и адаптивный инструмент. Подходит новичкам, поскольку его просто настраивать и легко использовать.

Underscore.js

Библиотека утилит, которая годами удерживала лидирующие позиции в разработке на JavaScript. Эксперты называли ее «швейцарским ножом разработчика» за большой выбор функций и массу возможностей.

Однако с этим инструментом произошло то же, что и другими библиотеками утилит. Большинство функций, которые были представлены в Underscore.js, теперь реализованы в ES6.

Чем заменить

Новая спецификация JavaScript E56+ поддерживает методы функционального программирования, позволяет манипулировать объектами и массивами данных. Таким образом, все функции Underscore.js доступны непосредственно на JavaScript без всяких посредников. Вывод — переносите код на E56+, он станет чище и проще в поддержке.

Axios

Библиотека для отправки запросов HTTP из браузера или Node.js. Поддерживает множество методов запросов (Get, Put, Delete и другие), загрузку и отправку файлов. Сильные стороны — удобный интерфейс, поддержка Promise API (способ организации асинхронного кода).

Несмотря на популярность Axios и его относительную свежесть, эта библиотека стремительно теряет позиции, поскольку появились новые инструменты с более расширенным функционалом.

Чем заменить

Fetch API превосходит конкурента по простоте и гибкости. Он выполняет те же задачи, но оснащен дополнительными функциями — потоковой передачей, отменой запросов, улучшенной обработкой ошибок.

Замена устаревших библиотек новыми — не только погоня за трендами и стремление к прогрессу, но и возможность создавать более производительные, легкие и экономичные веб-страницы и приложения.

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

Делитесь в комментариях, на какие библиотеки перешли! Ну а если хотите детальнее разобраться во всех аспектах Java и JavaScript, заходите в наш тг-канал.

В ночь с четверга на пятницу, 2 октября, у нас падал сайт. Примерно с трёх ночи до десяти утра многие страницы не открывались вообще.

Причина оказалась простой: мы тестировали новые рассылки в боте. Для этого нужно подключаться к продакшен базе и получать свежие посты. Бот не закрывал MySQL-соединение и мы быстро достигли лимита в 255 открытых дескрипторов (ограничение managed MySQL от DO). Я закрыл подключение для бота и минут через 15 база данных разрешила к себе подключаться.

Выводы — настраивайте больше алертов на неочевидные метрики. Количество подключений не приводит к перегрузке по памяти или ЦП, и мы не смогли отловить состояние текущим мониторингом для принятия превентивных действий. Ну и пишите качественный код, не забывайте закрывать открытые соединения с чем бы то ни было.

Из хорошего: мы увеличили базовый шрифт на сайте с 16 до 17 пикселей, читать статьи стало приятнее. Это потянуло за собой увеличение и других шрифтов, а также корректировки по отступам и в целом вёрстке. Изменение лучше заметно на мобильных:

Ещё мы наконец победили проблемы с CLS и даже написали про это отдельную статью, которая может помочь и вам:

Я сделал для нашего сайта несколько приятных обновлений. Одно из них вы можете увидеть, если кликните по любому изображению прямо в этой статье.

В ходе нашей борьбы с jQuery пришла очередь избавиться от библиотеки просмотра изображений Lightbox, но увеличение картинки при клике мы терять не хотели. И среди нескольких кандидатов на замену мы выбрали библиотеку Photoswipe.

Что получили в итоге:

1. Самобытную библиотеку просмотра изображений, с возможностью настройки под наши требования.
2. Увеличение картинок происходит с красивой анимацией и поддержкой адаптивности.
3. В скорости загрузки особых изменений нет, но это минус одна зависимость от jQuery, а значит на дальней дистанции мы ожидаем получить прирост скорости.
4. В скором времени на основе этой библиотеки появятся галереи.

Работать в медиа не всегда просто. Часто тебе нужно искать баланс между тем, что ты сам хочешь транслировать, что хотят читать люди, на что у тебя есть ресурсы. Усложняет дело то, что редко получается получить прямой фидбек. Ты можешь посмотреть на техническую информацию: сколько просмотров, как долго люди остаются на странице, как много людей уходит, не дочитав материал. Ты смотришь на эти цифры и пытаешься понять: нравится или не нравится, что именно нравится, что стоит повторить, а чего избегать.

Иногда мы всё-таки получаем живой фидбек — через комментарии. Но чаще всего он бывает негативным, потому что люди склонны скорее писать об ошибках, чем хвалить, потому что если всё ок — чего писать-то? Тем удивительнее для меня было то, что когда мы запустили свои комментарии на сайте и начали появляться первые комментарии, многие из них были положительными! Люди благодарили за материалы, писали, что им понравилось, что материал пригодился. В это было так сложно поверить, что я даже заподозрила в этом атаку каких-то дружелюбных ботов ?

В этих итогах месяца я бы хотела сказать спасибо всем, кто писал нам комментарии, всем, кто читает наши статьи и участвует в жизни нашего сайта. Спасибо всем, кто высказывает своё мнение: и отрицательное — потому что оно показывает, в чём мы можем стать лучше, — и положительное, потому что оно даёт нам силы становиться лучше.

Доброго нам всем месяца и новых успехов.

Зачем 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-кода, который мы отправляем браузерам. Одна из вещей, за которыми мы постоянно следим, — технический долг, порой вырастающий из некогда полезных зависимостей, которые потеряли свою актуальность по прошествии времени.

Когда очередь дошла до jQuery, мы сравнили его с развивающимся веб-стандартом в браузерах и поняли, что:

• Шаблон $(selector) можно легко заменить на querySelectorAll();
• Переключение CSS-классов теперь можно осуществить с помощью Element.classList;
• CSS теперь поддерживает создание анимации в таблицах стилей, а не в JavaScript;
• $.ajax-запросы можно выполнять с помощью Fetch Standard;
• Интерфейс addEventListener() достаточно стабилен для кроссплатформенного использования;
• Шаблон делегирования событий легко инкапсулировать с помощью легковесной библиотеки;
• С эволюцией JavaScript часть синтаксического сахара jQuery устарела.

Кроме того, синтаксис цепочек команд не удовлетворял нашим представлениям о коде, который мы хотели бы писать в будущем. Например:

Такой синтаксис прост в написании, однако по нашим стандартам не очень хорошо передаёт намерения автора. Сколько элементов 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, использованный для отображения модальных диалогов, в элемент <details-dialog>.

Наша общая философия прогрессивного улучшения относится и к пользовательским элементам. Это значит, что мы стараемся хранить как можно больше контента в разметке и только добавлять поведение поверх неё. Например, <local-time> по умолчанию показывает исходную временную метку, но с улучшением может переводить время в местный часовой пояс, а <details-dialog>, расположенный внутри элемента <details>, интерактивен даже без JavaScript, но может быть улучшен до расширенных возможностей доступа.

Вот пример того, как можно реализовать элемент <local-time>:

Один из аспектов 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»

Мы разбили оригинальную картинку на разделы, но если вам удобнее использовать один большой файл, то его можно скачать здесь.

Селекторы

Атрибуты / CSS

Манипуляции с DOM

Обход элементов

События

Эффекты

Ajax

Возможности самого jQuery

PDF-файл со всеми разделами шпаргалки, собранными вместе:

Ссылка на PDF для тех, у кого не работает встраивание PDF в браузере.

Благодарим Роба Менинга, автора сайта WebsiteSetup, за предоставленный материал.

Текущая версия 3.1.1, вышедшая в сентябре 2016 года, исправила множество багов, добавила новые методы и удалила избыточные, также изменив поведение некоторых функций. Давайте разберемся в нововведениях, которые были представлены в этой версии.

Методы скрытия и отображения

Для лучшей совместимости с адаптивным дизайном jQuery3 была усовершенствована, получив возможность скрытия нескольких элементов. Тесты показали, что новая версия справляется с этим на 2% быстрее, чем предыдущая.

Кроме того, методы .hide(), .show() и .toggle() будут ориентироваться на inline-стили. Эта особенность позволит корректно работать с функцией display, что позволит правилам CSS изменяться динамически в зависимости от таких событий, как изменение разрешения окна и ориентации экрана.

Методы wrapAll() и unwrap()

В jQuery 2 метод .wrapAll() при передаче функции в качестве аргумента вёл себя точно так же, как и метод .wrap(). Это изменили — теперь .wrapAll(function) вызывает функцию и использует строковое представление результата как обёртку коллекции.

В jQuery 3 также появился опциональный параметр-селектор метода unwrap(). Это нововведение позволяет передавать методу строковое значение, которое содержит выражение селектора.

Полосы прокрутки высоты и ширины теперь учитываются

В jQuery 2 вызов $(window).width() возвращал ширину содержимого, не учитывая полосы прокрутки, добавленные браузером, когда содержимое превышало размеры элемента. Для того, чтобы предоставить возможность измерения, эквивалентную CSS-медиазапросу, $(window).outerWidth() и $(window).outerHeight() теперь возвращают ширину и длину с учётом полос прокрутки. Это эквивалентно свойству DOM window.innerWidth.

Поведение data()

В jQuery 3 поведение метода data() было немного изменено, чтобы он подходил под спецификации Dataset API. Теперь он переводит имена свойств в верблюжью нотацию.

При использовании старой версии вы получите следующий результат:

В jQuery 3 вы получите:

Как вы заметили, название параметра переведено в верблюжью нотацию, в то время как в старых версиях параметр оставался в нижнем регистре с дефисом.

Поддержка SVG при операциях с классами

jQuery до сих пор не полностью поддерживает SVG, но методы наподобие .hasClass() или .addClass(), которые управляют CSS-классами, могут быть использованы для работы с SVG. Вы можете изменять или находить классы в SVG, затем применять стили к классам, используя CSS.

Фильтры скрытия и отображения

jQuery 3 изменяет смысл фильтров :visible и :hidden. Он воспринимает элементы как :visible, если у них есть хоть какие-то окна макета, включая те, которые имеют нулевую ширину и длину. Для примера, элемент br и строковые элементы без содержимого будут выделены фильтром :visible.

Если вы имеете следующую HTML-страницу:

и запускаете выражение:

то в jQuery 2, вы получите результат 0, а в третьей версии результат будет равен 3.

jQuery больше не округляет параметры высоты и ширины

Теперь jQuery возвращает дробные значения .width() и .height() вместо целого числа, если браузер поддерживает это. Для пользователей, которым нужна субпиксельная точность (например, при дизайне веб-сайтов), это может быть полезным.

Например, у вас есть 3 элемента с шириной, равной одной третьей (33.333333%), внутри контейнера шириной 100px:

Если вы запросите ширину дочернего элемента:

то получите значение 33.33333, что будет являться более точным результатом.

Дополнительный уровень защиты

Дополнительный уровень был добавлен для защиты от межсайтового скриптинга (XSS). Разработчикам теперь нужно уточнять dataType:”script” в опциях методов $.ajax() и $.get(). Это предотвращает возможность атак. Предоставляем пример кода:

Неприменимый хеш

jQuery 3 возвращает синтаксическую ошибку, если строка селектора состоит лишь из хеша, вроде jQuery("#") или .find("#"). В старой версии $("#") возвращал пустое множество, а .find("#") — ошибку.

Новый метод для выделения строк

Новый метод jQuery.escapeSelector() позволяет вам выделить любую строку или символ, которые имеют определенное значение в CSS-селекторах.

Например, если элемент на странице имеет id “abc.xyz”, то он не может быть выбран методом $("abc.xyz"), т.к. селектор будет распознан как элемент с id “abc”, и классом “xyz”. Однако он может быть выбран новой функцией $("#" + $.escapeSelector("abc.xyz")).

Аргументы jQuery.when()

В jQuery 3 при добавлении методом then() аргумента к $.when(), он возвращает его promise-версию. Это расширяет возможности для ввода, включая промисы Bluebird и промисы ES6, что дает возможность писать более сложные асинхронные обратные вызовы.

Хеш в URL

Теперь функция jQuery.ajax() больше не удаляет хеш в URL, если он присутствует. Однако, вам придется удалять его вручную до отправки запроса, если сервер на другом конце соединения не может обработать URL с хешем.

Deferred-объекты совместимы с JS-промисами

Deferred’ы — это объекты которые можно соединять цепными обратными вызовами. jQuery 3 сделал их совместимыми с новыми стандартами Promises/A+. Также есть ключевое изменение в функции .then(). Любое исключение, выбрасываемое в рамках обратного вызова .then(), теперь конвертируется в отклоняемое значение. Непромисообразные значения, возвращенные обработчиком отклонений, меняются на выполняемые значения.

Устаревший deferred-метод:

Новый стандарт поведения Promises/A+:

Новый API для анимации

jQuery 3 использует API requestAnimationFrame() для работы с анимацией. Этот API воспроизводит анимации плавнее и быстрее, затрачивая меньше вычислительного времени. Он используется лишь в тех браузерах, которые поддерживают этот API. Для старых же браузеров, таких как Internet Explorer 9, jQuery использует старый API в качестве запасного варианта.

jQuery 3 работает в строгом режиме

Большинство браузеров, поддерживающих jQuery3, используют строгий режим (strict mode). Новая версия была создана с учётом это. Несмотря на то, что jQuery 3 была написана в строгом режиме, вашему коду не обязательно использовать его. Следовательно, вам не нужно переписывать уже существующий код, если вы желаете перейти на новую версию. Однако есть одно исключение: некоторые версии ASP.NET не совместимы из-за строгого режима.

Новая сигнатура методов get и post

jQuery получила новые сигнатуры сервисных функций $.get() и $.post() для единообразия с $.ajax().

Оператор цикла for…of

jQuery 3 поддерживает оператор цикла for..of, который имеется в спецификации ECMAScript 6. Это позволяет вам запускать цикл по итерируемым объектам, таким как Map, Set, Array и т.д.

Оператор цикла for..of может быть использован для замены синтаксической конструкции $.each( ). Предположим, что вы хотите применить имя к каждому вводимому элементу страницы.

Код на jQuery 2 выглядит так:

Но код на jQuery 3 будет иметь следующий вид:

jQuery

Очень приятный курс, проходить который можно, даже не зная, что такое jQuery вообще. Если что, jQuery — библиотека для JavaScript, с помощью которой можно находить и, например, изменять различные элементы HTML. Впрочем, это пояснение лишнее — курс начинается с весёлой песни, которая рассказывает про то, что такое jQuery.

Затем песню сменяет ведущий, который рассказывает теорию. Ведущий очень живой, слушать его приятно. Вдобавок, всё, что он говорит, сопровождается иллюстрациями. Слайды к тому, что он говорил, можно позже скачать.

Лекция ведущего сменяется практическими заданиями — с возможностью запросить подсказки. За просмотр подсказок условные баллы не снимаются, зато снимаются за просмотр ответов (такая возможность, естественно, тоже предусмотрена).

Задания сменяются новой теорией от ведущего, теория — снова практикой. В целом курс создан не для глубинного обучения jQuery, а для изучения основ синтаксиса и понимание общих принципов работы.

Github

Этот курс построен несколько иначе, чем предыдущий. Курс построен так, будто вам нужно запушить свой проект на Github — сначала даётся объяснение того, что на данном этапе нужно сделать, а чуть ниже — команда, которая это выполняет. Для перехода к следующему уроку эту команду необходимо перепечатать в терминал и выполнить. Результат работы команды вы можете увидеть в импровизированном диспетчере файлов. В общем-то, чаще всего к подобным самоучителям прибегают, именно когда появляется срочная необходимость выложить свой проект на Github. Лучшего способа, чем проделать все шаги самому под чутким руководством милого Октокота, наверное, нет. Ну, разве что наше руководство по быстрому старту с git.

Оформление заданий

Ruby

В этом туториале каждый урок строится достаточно простым образом — программа сообщает вам, как делается в Ruby то или иное действие, и немного теории. Переход к следующему уроку осуществляется, когда вы выполните это (или аналогичное действие) в консоли справа. Курс достаточно интересный, к тому же система довольно сносно шутит (например, сначала предлагает вам выполнить 40.reverse(), а потом сообщает, что перевернуть можно только строку, а число нельзя. Если вы, конечно, не поднесёте к монитору зеркало :D)

Первый урок на tryruby

А какие интерактивные самоучители знаете вы? Пишите в комментариях, лучшими из предложенных мы пополним статью.

Также некоторые объекты были обновлены для совместимости со стандартами Promises/A+ и ES2015 Promises. Важно помнить, что новая версия библиотеки не поддерживает IE 6-8 версий.

После релиза окончательной версии jQuery 3.0 она станет единственной поддерживаемой версией jQuery. Ветки 1.12 и 2.2 будут получать критические обновления, но никаких нововведений или изменений в них уже не будет.

Инструкцию по обновлению до новой версии можно прочитать здесь.

В новой версии нас ждет несколько новых фич и некоторое улучшение производительности, достигнутое за счет того, что при определенных ситуациях будут использоваться предкомпилированные Sizzle-селекторы. Кроме того:

• Появилась поддержка манипуляции над SVG-элементами.
• Добавили новую сигнатуру к AJAX-ярлыкам, которая дает возможность использовать символы и итераторы в параметрах объектов.
• Метод jQuery.unique(), после удаления дубликатов, теперь еще и сортирует.

Разработчики также пообещали, что jQuery 3.0 выйдет довольно скоро, но не уточнили когда именно.