company_banner

История и наследие jQuery

Автор оригинала: Danny Guo
  • Перевод

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 позволила нам много делать лучше. То же самое верно и для её преемников.
Mail.ru Group
740,45
Строим Интернет
Поделиться публикацией

Комментарии 16

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

        Ради интереса запустил, впервые за последние года 2 обнаружил тулбар со ссылками яндекса :)
        +1
        Не понятно когда вообще исчезнет необходимость его поддержки.

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

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

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

          Эх, как молоды мы были :)
            +1
            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 дизайн — будущее. Он сам подгонится под нужный размер экрана.
              0
              Крсиво все написано, но в том же Safari периодически встречаются баги, от которых невольно вспоминаешь веселые времена IE6, «ну просто он такой вот».
                +1
                Есть довольно простой способ отделить тачскрины от устройств с обычным курсором, не запариваясь с размерами окна или типом браузера:

                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
                  +2
                  И ради всего святого, не нужно посылать юзеров на кастрированые мобильные версии сайтов

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

                  Как по мне — я просто убивать готов тех кто делает Адаптивный ®©™ Единый ®©™ сайт для всех устройств

                  Вот на кой ляд мне качать c мобильника весь этот интерфейс, всю эту кучу либ и фреймворков, картинок, скриптов, и прочего кода, из которых 80% все равно от меня скроется, ибо он же с телефона, покажем ему только то что нужно/вместится на экран

                  Итого я вижу те же 20% что и в мобильной версии, только RAM и CPU на моем устройстве эта страница сожрёт ровно столько же, сколько и полноценная версия для ПК, плюс будет лагать при прокрутках и прочих взаимодействиях, и да, грузиться по GPRS полдня, с шансом при каждом клике не прогрузиться до конца и не работать.

                  Возьмите любой сайт крупного магазина электроники, или стройматериалов. С мобильника (8 ядер, 3 гига RAM) — лаг на лаге, тормозит, если у тебя не то что 3g, если минимум не LTE — будешь ждать интерактивности вплоть до вечности, ибо у каждого скриптика, у каждого кусочка есть нефиговый такой шанс тупо не прогрузиться через GPRS, поломав при этом работу всей остальной страницы.
                  Про EDGE речи вообще нет, браузеры падают в таймаут раньше, чем на странице появится хоть что то. Особенно «весело» это когда ты за городом, как раз возле того тех же стройматериалов/хозтоваров

                  Скучаю по WAP сайтам, когда страница с той же инфой и, зачастую, логикой весила несолько килобайт, и абсолютно не тормозила на старом Сименсе с экраном 101х80 пикселей.
                    0
                    Интернет-магазины делаются на готовых CMS вроде Битрикса, с адским фронтендом и общей тормознутостью, но громадным бизнес-функционалом, который «под ключ» писать очень дорого. В кастомной разработке сложных продуктов (SPA), как правило, все лишние десктопные компоненты исключаются из бандла. В идеале и стили бы, конечно, исключать — но они в основном не съедают много трафика и на производительность влияют слабо.

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

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

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

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

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

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

                          Самое читаемое