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

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

Краткая история jQuery


Джон Резиг (John Resig) создал первую версию библиотеки в 2005-м, а опубликовал в 2006-м, на мероприятии под названием BarCampNYC. На официальном сайте jQuery автор написал:

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

У jQuery два главных достоинства. Первое — это удобный API для манипулирования веб-страницами. В частности, он предоставляет мощные методы для выбора элементов. Выбирать можно не только по ID или классам, jQuery позволяет писать сложные выражения, например, чтобы выбирать элементы на основе их взаимосвязей с другими элементами:

// Select every item within the list of people within the contacts element
$('#contacts ul.people li');

Со временем механизм выбора превратился в отдельную библиотеку Sizzle.

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

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

// If Mozilla is used
if ( jQuery.browser == "mozilla" || jQuery.browser == "opera" ) {
        // Use the handy event callback
        jQuery.event.add( document, "DOMContentLoaded", jQuery.ready );

// If IE is used, use the excellent hack by Matthias Miller
// http://www.outofhanwell.com/blog/index.php?title=the_window_onload_problem_revisited
} else if ( jQuery.browser == "msie" ) {

        // Only works if you document.write() it
        document.write("<scr" + "ipt id=__ie_init defer=true " + 
                "src=javascript:void(0)><\/script>");

        // Use the defer script hack
        var script = document.getElementById("__ie_init");
        script.onreadystatechange = function() {
                if ( this.readyState == "complete" )
                        jQuery.ready();
        };

        // Clear from memory
        script = null;

// If Safari  is used
} else if ( jQuery.browser == "safari" ) {
        // Continually check to see if the document.readyState is valid
        jQuery.safariTimer = setInterval(function(){
                // loaded and complete are both valid states
                if ( document.readyState == "loaded" || 
                        document.readyState == "complete" ) {

                        // If either one are found, remove the timer
                        clearInterval( jQuery.safariTimer );
                        jQuery.safariTimer = null;

                        // and execute any waiting functions
                        jQuery.ready();
                }
        }, 10);
}

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

Позднее jQuery облегчила внедрение более сложных технологий, таких как анимации и Ajax. Библиотека фактически превратилась в стандартную для веб-сайтов зависимость. И сегодня она обеспечивает работу огромной доли интернета. W3Techs считает, что 74 % сайтов сегодня используют jQuery.

Контроль за развитием jQuery также стал более формализованным. В 2011-м команда cоздала jQuery Board. А в 2012-м jQuery Board преобразилась в jQuery Foundation.

В 2015-м jQuery Foundation влился в Dojo Foundation, чтобы создать JS Foundation, который затем объединился с Node.js Foundation в 2019-м для создания OpenJS Foundation, в рамках которого jQuery была одним из "пробивных проектов."

Меняющиеся обстоятельства


Однако в последние годы jQuery подрастеряла свою популярность. GitHub убрал библиотеку из фронтенда своего сайта. Bootstrap v5 избавится от jQuery, потому что это его «крупнейшая клиентская зависимость для обычного JavaScript» (на данный момент размером 30 Кб, минифицированная и запакованная). Несколько тенденций в веб-разработке ослабили позицию jQuery как необходимого инструмента.

Браузеры


По ряду причин, различия и ограничения браузеров стали менее важны. Во-первых, улучшилась стандартизация. Основные разработчики браузеров (Apple, Google, Microsoft и Mozilla) совместно разрабатывают веб-стандарты в рамках Web Hypertext Application Technology Working Group.
Хотя браузеры ещё отличаются друг от друга в ряде важных моментов, у вендоров хотя бы есть средство для поиска и создания общей базы вместо перманентной войны друг с другом. Соответственно, API браузеров обрели новые возможности. К примеру, Fetch API способен заменять Ajax-функции из jQuery:

// jQuery
$.getJSON('https://api.com/songs.json')
    .done(function (songs) {
        console.log(songs);
    })

// native
fetch('https://api.com/songs.json')
    .then(function (response) {
        return response.json();
    })
    .then(function (songs) {
        console.log(songs);
    });

Методы querySelector и querySelectorAll дублируют средства выбора из jQuery:

// jQuery
const fooDivs = $('.foo div');

// native
const fooDivs = document.querySelectorAll('.foo div');

Манипулировать классами элементов теперь можно с помощью classList:

// jQuery
$('#warning').toggleClass('visible');

// native
document.querySelector('#warning').classList.toggle('visible');

На сайте You Might Not Need jQuery перечислено ещё несколько ситуаций, в которых код jQuery можно заменить нативным кодом. Некоторые разработчики всегда придерживаются jQuery, потому что просто не знают о новых API, но когда узнают, начинают реже использовать эту библиотеку.

Использование нативных возможностей позволяет повысить производительность страниц. Многие эффекты анимации из jQuery теперь можно реализовать гораздо эффективнее с помощью CSS.

Вторая причина заключается в том, что браузеры обновляются гораздо быстрее, чем раньше. В большинстве из них применяется «вечнозелёная» стратегия обновления, за исключением Apple Safari. Они могут обновляться в фоновом режиме без привлечения пользователя и не привязаны к обновлениям ОС.

Это означает, что новые возможности браузеров и исправления багов распространяются гораздо быстрее, и разработчикам не нужно ждать, пока доля Can I Use достигнет приемлемого уровня. Они могут уверенно использовать новые фичи и API без загрузки jQuery или полифилов.

Третья причина заключается в том, что Internet Explorer приближается к состоянию полной неактуальности. IE уже давно является бичом веб-разработки во всём мире. Характерные для него баги были широко распространены, а поскольку IE доминировал в 2000-х и не использовал «вечнозелёную» стратегию обновления, до сих пор часто встречаются его старые версии.

В 2016-м Microsoft ускорила вывод IE из эксплуатации, прекратив поддерживать десятую и более ранние версии, ограничившись поддержкой IE 11. И всё чаще веб-разработчики могут позволить себе роскошь игнорирования совместимости с IE.

Даже jQuery перестал поддерживать IE 8 и ниже начиная с версии 2.0, вышедшей в 2013-м. И хотя в некоторых случаях ещё требуется поддержка IE, к примеру, на старых сайтах, однако эти ситуации возникают всё реже.

Новые фреймворки


С момента появления jQuery было создано множество фреймворков, в том числе современные лидеры React, Angular и Vue. У них есть два важных преимущества перед jQuery.

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

С другой стороны, компоненты React, Angular и Vue позволяют тесно связать HTML, код и даже CSS. Как мы разделяем кодовую базу на много самодостаточных функций и классов, так и возможность разделить интерфейс на повторно используемые компоненты упрощает сборку и сопровождение сложных сайтов.

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

В jQuery вы явно прописываете шаги для совершения каких-либо изменений. А в декларативном фреймворке вы говорите: «Согласно этим данным, интерфейс должен выглядеть так». Это может сильно облегчить написание кода без багов.

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

Когда использовать jQuery?


Так когда же следует использовать jQuery?

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

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

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

Даже если мне понадобится что-то более мощное, я поищу специализированную библиотеку, например, axios для Ajax или Animate.css для анимаций. Это будет проще, чем загружать всю jQuery ради небольшой функциональности.

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

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

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

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

Взгляд в будущее


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

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

Кому-то не нравится интенсивность устаревания инструментов для веб-разработки, но для меня это свидетельство быстрого прогресса. jQuery позволила нам много делать лучше. То же самое верно и для её преемников.

Комментарии (14)


  1. kutensky
    23.09.2019 13:35

    По поводу поддержки IE 11… Не понятно когда вообще исчезнет необходимость его поддержки. К сожалению, Win10 всё ещё использует его как предустановленный браузер, и конца его поддержки пока не видно. А потому всё ещё приходится делать хаки и отказываться от некоторых новых фишек.


    1. vmarunin
      23.09.2019 13:58

      Разве не Edge используется? Нет, IE в недрах ещё живёт, но до него не так просто докопаться


      1. dimka11
        23.09.2019 19:25

        Его можно запустить через пуск, иногда его открывают другие программы.

        Ради интереса запустил, впервые за последние года 2 обнаружил тулбар со ссылками яндекса :)


    1. Wolches
      24.09.2019 10:27

      Не понятно когда вообще исчезнет необходимость его поддержки.

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


  1. murzix
    23.09.2019 14:19

    Прогресс в сайтостроении тормозят «злые админы», иначе сложно объяснить почему на b2b сайтах пользователей с IE меньше не становится

    image


  1. CoolWolf
    23.09.2019 16:11

    2009 год:
    — Я сделал слайдер на чистом JS
    — О_о (непонимающий осуждающий взгляд)

    2019 год:
    — Я сделал слайдер на jQuery
    — О_о (непонимающий осуждающий взгляд)

    Эх, как молоды мы были :)


  1. kikiwora
    23.09.2019 17:45

    iPad OS (iOS 13 на iPad) теперь определяет себя как
    «Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko)»

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

    Отключается в опциях Safari. Но мало кто будет отключать в реальности — никто не захочет урезать функционал.

    Это вызывает целый ряд проблем на сайтах которые написаны с использоанием платформ-детекторов (что плохо само по себе).

    Но способ определить такое чудо как мобилу всё же существует, поскольку маков с мульти-тачем пока что не существует:

    let isIOS = /iPad|iPhone|iPod/.test(navigator.platform) || (navigator.platform === 'MacIntel' && navigator.maxTouchPoints > 1)

    В любом случае, если вы используете платформ-детекторы, то вы пишете код который пахнет (code that smells) — это плохой подход.

    Используйте вместо детекта платформы feature detections.
    Проверяете фичу — работает, используете, нет работает — делаете fallback или выводите сообщение с извинениями.

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

    Лучше сайт который работает везде но не полностью чем тот который работает не везде но полноценно

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

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

    Responsive дизайн — будущее. Он сам подгонится под нужный размер экрана.


    1. Ghost_nsk
      24.09.2019 09:16

      Крсиво все написано, но в том же Safari периодически встречаются баги, от которых невольно вспоминаешь веселые времена IE6, «ну просто он такой вот».


    1. Aleksei_Segodin
      24.09.2019 11:07

      Есть довольно простой способ отделить тачскрины от устройств с обычным курсором, не запариваясь с размерами окна или типом браузера:

      let regular = window.matchMedia('(pointer:fine)');
      let touch = window.matchMedia('(pointer:coarse)');
      
      if (regular.matches) {
        // обычный курсор
      } else if (touch.matches) {
        // тач-скрин
      } else {
        // устройство без курсора, оно же pointer:none
      }


      https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pointer
      https://caniuse.com/#search=pointer%3Acoarse


  1. potan
    23.09.2019 20:18

    «Императивный подход плохо масштабируется, но его освоить проще, чем декларативный подход других библиотек.»
    Спорное утверждение. На старой работе, когда фронтендер был в отпуске, мне приходилось заглядывать в js-ный код (сначала с jQuery, потом с каким-то фреймвоком, кажется он назывался Ext4). Хотя я был уже достаточно опытным бекендером на C++ и Scheme, понять, что и как там работает мне было очень тяжело. Но когда мне понадобилось сделать небольшой фронт самому, я посмотрел на Elm и разобрался за пару дней. Декларативность этого языка и фреймвока очень помогла его быстрому изучению.


  1. funca
    23.09.2019 22:32
    +1

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


  1. botyaslonim
    24.09.2019 00:51
    +1

    30 килобайт jQuery на фоне типичных бандлов для лэндингов в 3-5 Мб кажется теперь таким милым, пушистым… короче, это преимущество!


  1. piton_nsk
    24.09.2019 17:50

    А так, просто тестируйте на всех устройствах и решайте проблемы по мере поступления.

    Проблема в том что тестировать на всех устройствах и браузерах это совсем не просто.


  1. AriesUa
    24.09.2019 17:50

    Если бы не jQuery мы не увидели новое API в браузерах. Именно некоторые фичи были перенесены с jQuery в браузер.

    Стоит отдать должное — jQuery сделала небольшую революцию в JS.