Что такое jQuery и почему его называют «забытым»?

jQuery за одну минуту

jQuery — это небольшая библиотека JavaScript, которая упрощает распространённые задачи на веб‑странице — такие как выбор элементов, реакция на клики, изменение текста, показ/скрытие частей страницы и отправка запросов на сервер.

Если вы когда‑то видели код вроде $("button").click(...), это jQuery. Символ $ — просто сокращение для «найти что‑то на странице и сделать с этим что‑то».

О чём эта статья

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

Что обычно имеют в виду под «забытым»

Когда говорят, что jQuery «забыли», обычно не имеют в виду, что он исчез. Под этим чаще понимают:

• его реже используют в новых проектах, потому что современные браузеры уже поддерживают многие функции, которые раньше давал jQuery;\n- он всё ещё широко встречается в старых сайтах (и в некоторых плагинах, темах и админках), потому что работает, знаком, и замена требует времени.

Итак, история не в том, что «jQuery мёртв». Скорее: jQuery перестал быть инструментом по умолчанию и превратился в унаследованную зависимость, которую вы можете получить «в наследство» — и иногда сознательно выбрать.

Почему jQuery был таким важным

До появления jQuery фронтенд‑работа часто сводилась к многократному написанию одних и тех же мелких, утомительных фрагментов кода — а затем к их тестированию в разных браузерах и исправлению несовместимостей. Даже простые цели вроде «найти элемент», «повесить обработчик клика» или «отправить запрос» могли превратиться в набор особых случаев.

Как ощущалась фронтенд‑разработка до jQuery

Много раннего JavaScript‑кода было скорее борьбой со средой, чем созданием фич. Писали код, который работал в одном браузере, а затем добавляли ветки, чтобы он работал в другом. Команды держали собственные «мини‑библиотеки» вспомогательных функций, чтобы выживать в повседневной работе.

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

Различия между браузерами и почему они были важны

Браузеры расходились во мнениях о важных деталях. Методы выбора DOM, обработка событий и даже способы получения размеров элементов могли отличаться. Особенно Internet Explorer имел другие API для событий и XMLHTTP‑запросов, поэтому «стандартный» код не всегда был переносим.

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

Пробел, который заполнил jQuery

jQuery стал популярным потому, что предложил последовательный дружелюбный API, который сглаживал эти различия.

Он делал распространённые задачи значительно проще:

• выбор и манипуляция DOM с помощью селекторов в стиле CSS;\n- обработка событий в кросс‑браузерном виде;\n- анимации и эффекты без ручного управления таймерами;\n- Ajax‑запросы с единым предсказуемым интерфейсом.

Не менее важно: стиль «пиши меньше, делай больше» помогал командам выпускать фичи быстрее и с меньшим количеством браузерных сюрпризов — особенно в эру, когда «современные DOM API» были менее функциональны и широко поддерживаемы.

Основные задачи, в которых помогает jQuery

Настоящая сила jQuery в том, что он не столько придумывал новые идеи, сколько делал общие браузерные задачи последовательными и простыми. В старом фронтенд‑коде вы обычно увидите jQuery для четырёх повседневных задач.

1) Выбор и обход DOM (идея функции $)

Функция $() позволяла «схватить» элементы с помощью селекторов в стиле CSS и затем работать с ними как с группой.

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

2) События: клики/submit/ready

jQuery упростил реакцию на действия пользователя:

• click для кнопок и ссылок;\n- submit для форм;\n- ready чтобы запускать код после загрузки страницы.

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

3) AJAX‑основы (загрузка данных без перезагрузки)

До того, как fetch() стал стандартом, $.ajax(), $.get() и $.post() были простым способом запросить данные и обновить страницу без перезагрузки.

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

4) Эффекты/анимации и простые UI‑хелперы

jQuery популяризовал быстрые UI‑штрихи вроде hide(), show(), fadeIn(), slideToggle() и animate(). Это было удобно для меню, уведомлений и простых переходов — особенно когда поддержку CSS‑анимаций нельзя было воспринимать как должное.

В совокупности эти удобства объясняют, почему в наследном JavaScript‑коде часто встречается $( и почему jQuery так долго оставался инструментом по умолчанию.

Простой пример: jQuery vs современный JavaScript

Репутация jQuery во многом связана с тем, как мало кода надо было писать для обычных UI‑задач — особенно когда различия браузеров были болезненными. Небольшое сравнение наглядно это показывает.

Выбор элемента и обработка клика

jQuery

// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
  e.preventDefault();
  $('.status').text('Saved!');
});

Современный (vanilla) JavaScript

// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');

saveButton?.addEventListener('click', (e) => {
  e.preventDefault();
  if (status) status.textContent = 'Saved!';
});

Читаемость: меньше строк против более ясных API

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

Современный JavaScript чуть более многословен, но он и более явный:

• querySelector и addEventListener явно показывают, что происходит;\n- textContent — это стандартное свойство DOM (нет обёртки библиотеки);\n- опциональная цепочка (?.) и проверки на null делают поведение при отсутствии элементов понятнее.

Что лучше?

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

Нативный JavaScript нагнал jQuery

Долгое время главное преимущество jQuery — предсказуемость. Можно было писать один подход для выбора элементов, навешивания событий или Ajax‑запросов — и это работало в большинстве мест.

Со временем браузеры стандартизировались и улучшались. Многие «обязательные» удобства, которые предлагал jQuery, теперь встроены в JavaScript, так что часто нет нужды в дополнительной библиотеке для базовых задач.

DOM API стали проще и последовательнее

Современные DOM‑методы перекрывают многие шаблоны jQuery:

• document.querySelector() / document.querySelectorAll() заменяют $(...) во многих случаях;\n- element.classList.add() / .remove() / .toggle() покрывают манипуляцию классами;\n- element.addEventListener() заменяет jQuery‑обёртку событий для большинства сценариев.

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

Сетевые запросы перешли на fetch

Там, где раньше часто использовали $.ajax(), fetch() теперь справляется с повседневными запросами с меньшей церемонией, особенно в связке с JSON:

const res = await fetch('/api/items');
const data = await res.json();

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

Лучшее управление асинхронностью: Promises, async/await и модули

jQuery вводил многих в асинхронность через каллбэки и $.Deferred. Сегодня Promises и async/await делают асинхронный код более читабельным, а ES‑модули упрощают организацию кода.

Комбинация — современные DOM API + fetch + возможности языка — устранила большую часть первоначальных причин обращаться к jQuery по умолчанию.

Фреймворки изменили подход к UI

jQuery вырос в эпоху «многостраничных» сайтов: сервер рендерил HTML, браузер загружал страницу, а вы нашпиговывали её поведением — обработчиками, анимациями, Ajax‑встраиваниями.

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

SPA и компонентный UI

React, Vue и Angular популяризовали идею интерфейсов из компонентов — маленьких повторно используемых частей, которые управляют своей разметкой, поведением и состоянием.

В такой модели фреймворк хочет быть источником правды для того, что отображается. Он отслеживает состояние, перерисовывает части UI при изменении состояния и ожидает декларативного описания («когда X истинно — показать Y").

jQuery, напротив, поощряет императивную манипуляцию DOM («найди этот элемент, измени текст, скрой»). Это может конфликтовать с циклом рендеринга фреймворка. Если вы вручную меняете DOM, который контролирует компонент, при следующей перерисовке ваши изменения могут быть перезаписаны — или вы получите трудные для отладки рассогласования.

Инструменты сборки и бандлеры

С приходом SPA команды стали использовать сборщики (Webpack, Rollup, Vite). Вместо простого добавления тегов <script> вы импортируете модули, бандлите только то, что используете, и оптимизируете производительность.

Этот сдвиг сделал разработчиков более чувствительными к зависимостям и размеру бандла. Подключать jQuery «на всякий случай» стало менее естественно, когда каждый килобайт и внешнее обновление важны.

Почему jQuery выглядит неуместно в компонентных приложениях

Можно использовать jQuery внутри фреймворка, но это часто превращается в «островок» — сложный для тестирования, отладки и сопровождения. Поэтому многие команды предпочитают нативные подходы фреймворка вместо императивных скриптов jQuery.

Размер бандла и нагрузка сопровождения

jQuery сам по себе не «огромен», но часто приходит с багажом. Проекты, зависящие от jQuery, накапливают плагины (слайдеры, date‑picker, модальные окна, валидаторы), каждый из которых добавляет сторонний код для загрузки и парсинга. С течением времени страница может отправлять дублирующие утилиты — особенно если фичи добавляли быстро и их никогда не пересматривали.

Большие загрузки — больше работы для браузера

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

Скрытые издержки: смешение стилей и умственная нагрузка

В долгоживущих сайтах часто появляется «гибридная» кодовая база: части на jQuery, новые фичи на фреймворке (React, Vue, Angular) и несколько снитчков на ванильном JS. Такое смешение путает:

• два способа выбирать и обновлять DOM;\n- разные модели событий и жизненных циклов;\n- конкурирующие подходы к состоянию (DOM как состояние vs состояние компонента).

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

Накопление долгов по сопровождению

Команды постепенно уходят от jQuery не потому, что он «перестал работать», а потому что современные проекты оптимизируют размер бандлов и ясность ответственности за UI. По мере роста сайта уменьшение стороннего кода и стандартизация подхода обычно упрощают профилирование производительности, отладку и онбординг.

Почему jQuery всё ещё встречается в старых сайтах

jQuery не просто стал популярным — он стал по умолчанию. Годами это был самый простой способ сделать интерактивные страницы кросс‑браузерно, поэтому он оказался вплетён в шаблоны, сниппеты, туториалы и решения «скопировать‑вставить».

После этого jQuery стало сложно избежать: даже если сайт использовал лишь одну маленькую фичу, часто загружали всю библиотеку, потому что остальной код ожидал её присутствия.

Он встроен в старые плагины и темы

Одна из причин, почему jQuery встречается до сих пор: его успех сделал его «вездесущим» в стороннем коде. Старые UI‑виджеты, слайдеры, лайтбоксы, валидаторы форм и скрипты тем часто писались как jQuery‑плагины. Если сайт зависит от такого компонента, убрать jQuery значит переписать или заменить зависимость — а не просто поменять несколько строк.

WordPress унаследовал его (и сохраняет)

WordPress — большой источник «наследственного» jQuery. Многие темы и плагины, особенно старые, используют jQuery для поведения на фронте, и исторически админ‑панели тоже часто опирались на него. Даже если новые версии движка уходят в сторону современного JS, долгая «хвостовая» база расширений сохраняет jQuery на многих установках.

Унаследованные системы ценят стабильность

Старые сайты часто ориентируются на «не ломать то, что работает». Сохранение jQuery может быть самым безопасным вариантом, когда:

• сайт стабильный и критичен для дохода;\n- времени на тестирование и регрессии мало;\n- в кодовой базе годы мелких фиксов, которые никто не готов перепроверять.

Итак, jQuery не всегда «забывают» — он часто остаётся частью фундамента, на котором построен сайт, а фундамент меняют неохотно.

Когда jQuery всё ещё оправдан

jQuery не «плохой» — он просто реже нужен. Всё ещё есть ситуации, когда оставить (или даже добавить) немного jQuery — самый практичный выбор, особенно если приоритеты — время, совместимость или стабильность, а не архитектурная чистота.

Нужно поддерживать устаревшие браузеры

Если требования включают старые браузеры (особенно старые версии Internet Explorer), jQuery всё ещё может упростить выборку элементов, обработку событий и AJAX без набора полифилов.

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

Быстрые правки в существующей кодовой базе на jQuery

Если сайт уже построен вокруг jQuery, небольшие правки часто быстрее и безопаснее делать в том же стиле, что и остальной код. Смешение подходов создаёт путаницу (два способа для событий, два способа менять DOM), что усложняет сопровождение.

Правило разумности: если вы правите одну‑две страницы и приложение в целом стабильно, латать код с помощью jQuery нормально — просто не разрастайте его в новые подсистемы, которые потом придётся сворачивать.

Небольшие сайты без этапа сборки

Для простого маркетингового сайта или внутреннего инструмента — нет сборщика, транспайлера, фреймворка компонентов — jQuery всё ещё удобен как «один скрипт». Особенно если нужно пару интерактивных фич (меню‑переключатели, простые формы) и вы не хотите внедрять сборщик.

Используется старый плагин, зависящий от jQuery

Многие зрелые плагины (pickers дат, таблицы, лайтбоксы) были построены на jQuery. Если старый плагин критичен для бизнеса и стабилен, оставить jQuery может быть наименьшим риском.

Перед тем как принять решение, проверьте, нет ли поддерживаемой альтернативы без jQuery — или не приведёт ли обновление плагина к переписке, которую проект сейчас не потянет.

Как безопасно уйти от jQuery

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

1) Аудитируйте, что реально используется

Ответьте на три практических вопроса:

• на каких страницах загружается jQuery?;\n- какие плагины от него зависят (слайдеры, date‑picker, валидация)?;\n- какие функции jQuery встречаются в кодовой базе (выборка DOM, события, AJAX, анимации)?

Аудит помогает не заменять то, что не нужно, и выявляет «скрытые» зависимости, например плагин, который тихо использует $.ajax().

2) Заменяйте простые вещи в первую очередь

Чаще всего быстрые победы приходят при замене простых паттернов:

• Селекторы: $(".card") → document.querySelectorAll(".card");\n- Классы: .addClass() / .removeClass() → classList.add() / classList.remove();\n- События: .on("click", ...) → addEventListener("click", ...).

Делайте это малыми PR, чтобы было легко ревью и откат.

3) Спланируйте переход AJAX

Если вы используете $.ajax(), переносите такие вызовы на fetch() (или небольшой HTTP‑хелпер) по одному эндпоинту. Старайтесь, чтобы форма ответа оставалась прежней, тогда остальная часть UI не потребует немедленных изменений.

// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);

// Modern JS
fetch("/api/items")
  .then(r => r.json())
  .then(renderItems);

4) Снизьте риск тестами и поэтапными релизами

Перед удалением jQuery добавьте покрытие для ключевых пользовательских сценариев: отправка форм, динамический контент и т.д. Даже лёгкие проверки (smoke‑тесты в Cypress или чек‑лист QA) поймают регрессии на раннем этапе. Релизьте изменения за флагом функции и следите за аналитикой/ошибками.

Если хотите дополнительную безопасность при рефакторинге, полезны инструменты со снимками и откатом. Например, команды, модернизирующие старые фронты, иногда прототипируют замену с помощью платформ прототипирования и используют snapshot/rollback‑потоки, чтобы итеративно улучшать код, не теряя «известно‑хорошую» версию.

Если нужно помощь в организации плана — смотрите /blog/jquery-vs-vanilla-js для сравнительной базы при рефакторинге.

Типичные подводные камни при миграции

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

Попытка переписать всё сразу

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

Смешение jQuery и компонентного фреймворка в одной зоне UI

Если вы вводите React/Vue/Svelte (даже лёгкую систему компонентов), пока jQuery всё ещё манипулирует теми же DOM‑узлами, вы получите «тянучку UI»: фреймворк перерисовывает и перезаписывает изменения jQuery, а jQuery меняет элементы, которые фреймворк считает своими.

Принцип: определите чёткую границу. Либо:

• держите jQuery в контейнере наследия и монтируйте фреймворк в другом месте, либо\n- мигрируйте весь виджет как единицу, прежде чем добавлять новое поведение.

Различия в делегировании событий

Много старого кода полагается на делегирование, например:

$(document).on('click', '.btn', handler)

Нативный DOM умеет делегировать, но совпадение и ожидания по this/event.target могут поменяться. Частые баги: обработчик срабатывает не для того элемента (из‑за вложенных иконок/спанов) или не срабатывает для динамически добавленных элементов, потому что слушатель навешан не на тот предок. При замене делегирования убедитесь:

• какой элемент считать «нажатой кнопкой» (closest() часто нужен);\n- были ли раньше имена событий (jQuery поддерживает это; в нативном коде нужен другой подход).

Регрессии доступности при замене эффектов

Эффекты jQuery UI и кастомные анимации иногда случайно скрывали проблемы доступности или сами их создавали. При замене анимаций проверьте:

• управление фокусом (куда уходит фокус после открытия/закрытия);\n- ARIA‑состояния (например, aria-expanded на кнопках‑раскрывашках);\n- предпочтения reduced motion (prefers-reduced-motion).

Раннее выявление этих проблем ускорит миграцию и сделает UI надёжнее — ещё до того, как последний $() исчезнет.

Ключевые выводы и следующие шаги

jQuery не «плох». Он решал реальные проблемы — особенно когда браузеры вели себя по‑разному и интерактивные страницы требовали много повторяющегося DOM‑кода. Что изменилось — в большинстве новых проектов он больше не обязателен.

Почему jQuery потерял позицию по умолчанию

Несколько сил перевели его от «инструмента по умолчанию» к «унаследованной зависимости»:

• Современные DOM API улучшились: выбор элементов, управление классами и обработка событий стали проще в нативном JS;\n- Браузерная согласованность выросла: меньше причуд — меньше нужды в слое совместимости;\n- Фреймворки изменили ожидания: React/Vue/Angular продвигают компонентный подход и декларативный рендеринг, где прямая манипуляция DOM менее уместна;\n- Давление на производительность и сопровождение: команды начали больше заботиться о размере бандлов, обновлениях зависимостей и уменьшении «мистического» кода в больших приложениях.

Практические следующие шаги

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

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

• основами DOM и типичными паттернами: /blog/vanilla-js-dom-basics;\n- заменой старых AJAX‑паттернов на современные запросы: /blog/fetch-api-beginners.

Если вы оцениваете, как модернизировать проект быстрее, рассмотрите инструменты для прототипирования и поэтапной поставки. Koder.ai может быть полезен: вы описываете желаемое поведение в чате, генерируете React‑UI и Go/Postgres бэкенд при необходимости и экспортируете исходники, когда готовы интегрировать с существующим кодом.

Если оцениваете инструменты или варианты поддержки, можно также посмотреть здесь: /pricing