Vanilla JS vs jQuery 2.0

Статья навеяна фреймворком Vanilla.js.

Эпоха старых браузеров уходит в небытие, вряд ли сейчас найдется сознательный человек, использующий ie6,7,8, на зло разработчикам и вопреки техническому прогрессу. Возможно, только по необходимости, например корпоративная система написана под IE6, или лентяи админы издеваются над пользователями и не хотят обновлять/устанавливать новые версии. Тем не менее, статистика использования этих браузеров неумолимо стремится к нулю. Собственно и новая версия jQuery 2.0, отказалась поддерживать устаревшие браузеры(IE 6-8). И тут с релизом jQuery возник вопрос, а для чего же тогда нужен jQuery?

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

Разберем основные возможности jQuery:

Движок кроссбраузерных CSS-селекторов Sizzle

Что ж, это вполне отличная вещь, вот только для чего? Я думаю, не одному мне встречались проекты/плагины, в которых используется jQuery в 3 местах, таких как $('#my_element').hide().
И для этого люди используете jQuery и тащат его в зависимостях? Ну что же, это их выбор…

Что же в этом случае предлагает vanilla?
Для javascript разработчиков знакомо document.querySelectorAll, встроенный в браузер и появившийся даже в IE8. can i use
Но тут кому-то может стать жалко символов, чтобы писать это каждый раз, благо javascript гибкий язык и позволяет писать различные конструкции, чем можно и воспользоваться.

var $ = document.querySelectorAll.bind(document) 
// для браузеров, поддерживающих bind или самостоятельно написанный bind(пара строк кода)
var $ = function(selector){ return document.querySelectorAll(selector) } 
// будет работать везде, где поддерживается querySelector


Манипуляции и переход по дереву DOM

Для многих пользователей jQuery, остается загадкой то, что же происходит, когда они пишут $('selector') или проводят манипуляции с DOM.
Во всех своих методах jQuery возвращает свой объект обертку jQuery, что позволяет пользователям библиотеки писать цепочки из jQuery вызовов.

Я думаю, что многим знакома картина в проектах:
  $(this).next().val(ui.item.id);
  $(this).next().next().val(ui.item.line);
  $(this).next().next().next().val(ui.item.id);
  $(this).next().next().next().next().next().val(ui.item.person.birth_date);
  $(this).next().next().next().next().next().next().next().val(ui.item.person.weight);
  $(this).next().next().next().next().next().next().next().next().val(ui.item.person.height);
  $(this).next().next().next().next().next().next().next().next().next().val(ui.item.person.name_translit);

Конечно, многие скажут, что этому коду прямая дорога на одноименный сайт, и будут правы. В идеале, конечно, next(selector). Но следует задуматься, почему кто-то написал его именно так? А ведь это, типичное поведение для jQuery объектов. Но если не придираться к самому коду, ведь вместо next могли быть различные манипуляции с DOM (css,attr,find...), записанные в цепочку вызовов, напрашивается вопрос: для чего такая обфускация кода?

Видимо, некоторые пишут код для машины… а не для людей, которым этот код достанется.

Подобно поведение существует и для методов работы с объектами jQuery (node list, array), методы: each, map и др. Необходимость в этих методах была, когда jQuery реализовывал их для старых IE. Во всех современные браузерах есть нативные методы работы с массивами, forEach, map…

Что касательно самого jQuery, пример кода:
$([1,2,3]).each(function(index, element){
  //do something
})

$([1,2,3]).each(function(i,e){ console.log(this===e) }) // 2


Сразу несколько замечаний, элемент массива передается вторым аргументом, что в итерации по списку глупо и нелогично, потому как сам итератор нужен чаще чем индекс, а индекс и вовсе не нужен, но есть this который ссылается на текущий элемент, причем в данном случае, создавая новый экземпляр переменной Number… что показано во 2 примере, очевидно что this и атрибут — не одно и то же. При попытке сравнить this с числом, без преобразования, получится false.
javascript, позволяет, но если каждый будет делать так, как ему того хочется, мир от этого явно лучше не станет.

И пример vanilla:
[1,2,3].forEach(function(element, index){
  //do something
}, [, context])

Параметры в логичном порядке, есть возможность задать контекст исполнения (this), не делая лишних замыканий.

Для манипуляции над DOM объектами существует довольно обширное API, почитать можно на MDN.

События

jQuery предоставляет с виду удобный EventListener, позволяет добавлять эвенты на элементы, селекторы и даже, на несуществующие на странице элементы (live -> on), к сожалению, абсолютно неподдающиеся дебагу и делающие лишние манипуляции. Например, повесить эвент на странице, где элемент отсутствует.

$(function(){
  $('.elements').bind('event', callback)
})


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

Что касательно live методов, а вы точно уверенны в том, что вы пишете и знаете, как оно работает? По существу, элементы на странице не берутся из воздуха, ни что не мешает повесить события, например в результате ajax запроса или по событию, вызвавшему появление элемента. Вызов обработчика события ускорится в несколько раз.

jQuery здесь всего лишь синтаксический сахар, не более.

В ранних версиях IE, эвенты прикреплялись с помощью attachEvent, что затрудняло работу, а jQuery в свою очередь, делал все автомагически, но теперь все браузеры поддерживают EventListener
element.addEventListener('event', callback)

что всегда можно переопределить, написав короткий метод или удобную обертку над эвентами(на строк 20), если хватит знаний javascript.

Визуальные эффекты

Набор простеньких утилит для эффектов которые не всегда нужны… Альтернатива? написать самостоятельно, лишь то, что Вам нужно, об этом в статье про vanilla. Конечно не повод городить велосипеды, но не тянуть же ради 1 метода всю библиотеку.
var s = document.getElementById('thing').style;
s.opacity = 1;
(function fade(){(s.opacity-=.1)<0?s.display="none":setTimeout(fade,40)})();

jQuery
<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
<script>
$('#thing').fadeOut();
</script>


AJAX

Трудно сейчас представить сайт без ajax. Но что же делает jQuery таким особенным в данном случае?
В предыдущих версиях было очевидно, что ajax запрос должен быть кроссбраузерным и реализовываться по разному, в зависимости от браузера пользователя. Но это в прошлом, теперь jQuery лишь добавляет синтаксический сахар для тех, кто в действительности просто не знает, как создать объект XMLHttpRequest. Спорить трудно, намного короче записать:

$.ajax({
  method: 'get',
  url: 'http://habrahabr.ru/',
  success: function(data){
    // Профит?
  }
})

без учета самой jQuery вроде коротко, но современные браузеры поддерживают нативный XMLHttpRequest:

var r = new XMLHttpRequest();
r.open("GET", "http://habrahabr.ru/", true);
r.onreadystatechange = function () {
  if (r.readyState != 4 || r.status != 200) return;
  // Профит?
};
r.send();

что само по себе не сильно выходит за рамки jQuery.ajax.

JavaScript-плагины

Обширная библиотека плагинов на jQuery, слайдеры, скролеры и тд… Клоны библиотек на любой вкус, по запросу в поиске можно найти десятки, а то и сотни идентичных плагинов, отличающихся ничемреализацией и/или автором.
$('selector').сделать_все_как_надо() решает много вопросов, но кто из авторов библиотек может вам дать 100% гарантии, и если что-то пойдет не так, заказчику явно будет не интересно слушать, что виноват Вася Пупкин, зарелизивший баг.

Конечно, Vanilla это не фреймворк, а самый что ни на есть javascript, позволяющий делать все, что необходимо.
Трудно представить, чем поможет jQuery, если вам необходимо написать какой-нибудь класс на javascript или не найдется нужной либы, а вы, возможно, даже и не слышали, что такое prototype(не фреймворк) и для чего он нужен.

Резюме

В итоге нельзя сказать, что jQuery тяжелый фреймворк (33.6 KB сжатый) в наш цифровой век безлимитных интернетов и мобильных устройств с памятью большей 1Гб. Но в большинстве случаев абсолютно бесполезный довесок, замедляющий работу страницы во много раз(как показывают бенчи примерно 50), без которого можно обойтись. Совсем другая ситуация с плагинами. Складывается впечатление, что разработчики вовсе не хотят сами думать, новый таск — новый плагин в проекте. В итоге кол-во плагинов jQuery (которые могут тянуть разные версии jQuery), раздувает js до 0.5 Мб, а то и больше…

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

Известна точка зрения Никлауса Вирта, которую разделяет часть программистского сообщества: согласно ей, любое расширение языка, не вызванное необходимостью, ухудшает его, так как приводит к усложнению транслятора и, соответственно, к понижению его надёжности и производительности. Одновременно возрастает сложность изучения языка и сложность сопровождения программ. Кроме того, сам факт наличия дополнительных синтаксических средств часто играет провоцирующую роль: он побуждает программиста прибегать к различным синтаксическим трюкам вместо того, чтобы глубже анализировать задачу и реализовывать более эффективные алгоритмы.[wiki]

Порой необходимо задумываться над тем, что вы делаете, работа у программиста такая — думать, вот и постарайтесь.
Речь не идет о том чтобы отказаться от jQuery и писать на vanilla, просто не переоценивать его возможности, бездумно используя, где надо и не надо, думаю все помнят про "как сложить два числа в javascript".

P.S. Скорее всего в меня полетит много камней от пользователей jQuery и комментарии о том, что он (фреймворк) уменьшает время разработки, но хочется надеется на сознательность людей и верить, что программисты знают свою работу и умеют думать своей головой.
Поделиться публикацией

Похожие публикации

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

    +27
    Автор, вы много написали JSa, который работает в браузере?
    По мимо IE, есть и другие браузеры, у которых есть баги и то что работает в Chrome, может по другому работать в Firefox.

    По этому абстракцию нужна. Но уже более тонкая.

    Я согласен что jQuery это очень тяжелая библиотека для этого, но она уже привычна. Брать AtomJS (как пример) и учить его, лишь из-за того что не нужна поддержка старых браузеров?

    Я предпочту узкие места написать на нативном жс, чем писать всё на нативе и в будущем вылавливать фиче-баги.

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

      Однако, согласен, баги имеют место быть, но в современных браузерах, эти отличия составляют по большей части разницу в API и решаются парой строк кода или парой условий. В отличии от старых IE/Opera с различными причудами по добавлению эвентов и ajax запросов и др.., где действительно необходимы эти абстракции, вот только речь идет про jQuery 2.0, в котором абстракции стали просто обертками для общих, нативных методов браузера.
      +24
      var r = new XMLHttpRequest();
      r.open("GET", "http://habrahabr.ru/", true);
      r.onreadystatechange = function () {
        if (r.readyState != 4 || r.status != 200) return;
        // Профит?
      };
      r.send();
      Неглупый, в общем, программист Петя на третьем разе замахается писать одно и то же и напишет обертку для XHR. Естественно, тестировать в старых и экзотических браузерах он не будет, да и зачем?

      var s = document.getElementById('thing').style;
      s.opacity = 1;
      (function fade(){(s.opacity-=.1)<0?s.display="none":setTimeout(fade,40)})();
      Хороший парень Вася на третьем разе замахается писать одно и то же и напишет обертку для эффектов. Естественно, тестировать в старых и экзотических браузерах он не будет, да и зачем?

      var $ = document.querySelectorAll.bind(document) 
      // для браузеров, поддерживающих bind или самостоятельно написанный bind(пара строк кода)
      Примерный семьянин Коля на третьем разе замахается писать одно и то же и напишет обертку для селекторов. Естественно, тестировать в старых и экзотических браузерах он не будет, да и зачем?

      Все эти чудесные парни рано или поздно уйдут на другую работу и возьмут им на замену Ваню (гигантище человек, соль земли, без преувеличения). Посмотрит Ваня на сайт, а там — анимация тормозит, JSONP в Опере 12 не работает, в ИЕ11 очередной баг, проявляющийся только при убывающей луне в четный четверг… Что подумает Ваня о своих чудесных предшественниках, открыв код, я здесь привести не могу, ибо за мат и эвфемизмы забирает НЛО.
        –5
        Давайте я расскажу вам другую историю об этих героях.

        Устраивается Петя на работу в аутсорс фирму, красочное резюме, знает множество технологий среди которых не малое место отведено js и jquery.
        Ему дают свежий проект и ставят задачи, а сделай ка нам автокомплит. Петя программист умный и знает отличный плагин для jq, погуглив, покликав примеры, прикручивает он его к проекту, благополучно притянув в зависимостях одну из версий jquery. И разместив нужную запись в main.js:
        $('.autocmoplete').autocomplete({...})
        За это его ругать не стоит, вещь не из самых простых для начинающих.

        На этом начальство не остановилось и просит сделать драг & дропы, Петя не долго думая вспоминает что для этого есть плагин jquery ui. Но зачем останавливаться на drag & drop, прикручивает Петя весь jquery ui в проект и использует d&d в одном месте.
        Время идет в помощь Пете компания нанимает еще одно программисту Колю, Коля тоже «хороший знаток» javascript и с радостью помогает решать поставленные задачи Пете.

        Таски все интереснее: добавить слайдеры, скролеры, карусели, зумеры, табы, дейтпикеры, маски… и еще с пару дюжин полезностей и красивостей, для которых 2 молодых программиста используют плагины для jquery.
        Местами возникают конфликты с версиями jquery, что они решают подключением различных версия, для разных нужд.
        А потом у двух программистов возникает идея, «мы такие умные и хорошие программисты», давайте сделаем SPA приложение. Подключают для этого Backbone который тащит дополнительно и underscore.
        Бравые ребята ныряют с головой в разработку, прокачивают свои «скилы». Но никакой отдачи от начальства ни повышений? ни поощрений и они увольняются, перейдя в другую компанию на более высокие оклады, они же уже еще и в one page «разбираются».

        Пользователи сайта начинают жаловаться на глюки и тормоза сайта на планшетах/телефонах, да и на нетбуках…

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

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

        И вот первый рабочий день Ваня скачивает проект и что он видит? Горы jquery плагинов, наскоро прикрученный на все Backbone, который еще вовсе не работает как SPA, в сочетании с кучей непонятной фигни. Ваня отлично знает javascript и разобраться с плагинами(на этот момент уже устаревшими, как и версия jquery) для него не представляет труда. Заглядывает в main.js файл в котором видит лишь
        $('.date').datepicker()
        $('#slider').slider()
        $('.photo').zoom()

        и так строк 50
        и еще с десяток вспомогательных файлов, с синтаксисом, как в статей (про next), а также скрытыми вызовами прямо на вьюхах.
        Ваня чувствует себя обманутым, ведь вместо крутого SPA приложения на javascript, получил кучу плагинов jquery.

        Так что же теперь думает Ваня о своих чудесных предшественниках? и считает ли он их программистами?
          +4
          Я правильно понимаю, что вместо того, чтобы за 5 минут прикрутить готовый плагин автокомплита, вы предлагаете потратить несколько часов (в лучшем случае, потому что потом надо будет еще убить время на тестирование) и написать его самому?
            0
            вы читаете между строк?
            За это его ругать не стоит, вещь не из самых простых для начинающих.

            проблемы начинаются дальше, когда на каждую задачу, даже элементарную, прикручивается плагин и их кол-во зашкаливает
              0
              Нет, я не читаю между строк. И не язвлю, в отличие от вас.
              Но я в вашем топике не вижу решения проблемы. Окей, вы говорите, за это его ругать не стоит. Сколько тогда ему можно еще добавить плагинов, чтобы начать его ругать? Какой критерий отсечки, когда надо все бросить и с богатырским рыком переписать все на ваниллу?
                –1
                К сожалению, критерий бывает в виде потери производительности, вот только потом уже поздно что-то менять, или придет кто-то другой, кто не захочет или не сможет поменять, потому как уйдет на это куча времени. Опять таки, зависит от разрабатываемого приложения.
                А решение проблемы, в использовании инструментов с умом.
                  0
                  Все приходит со стажем. Вы просто не сможете молодого программиста, который 2 недели прикручивает плагины на jQuery, за еще 2 недели обучить всей подноготной JavaScript. Поэтому можно только рекомендовать литературу и делать намеки на не-оптимальные участки кода, вести дескуссию. Плохой программист — который начнет с вами спорить и прирекаться. Но к таким нужно относиться по-философски.

                  Ничего в jQuery плохого нет. Есть другие менее распространенные фреймверки, при использовании которых, код становиться на порядок прозрачней, но камнем преткновения всегда выступает jQuery. Почему?
                    0
                    jQ — как самый популярный попадается на пути. Поэтому им и обобщают.
                    Ну и следовательно его знают больше людей, чтобы брать его в сравнение. Ведь глупо будет выглядеть если в статье будет для примера использоваться не известный автору фреймворк.

                    В общем — это плата за популярность. Паровозом он идет :D
            +2
            Nice try.

            k12th всё правильно написал в комментарии выше. Это уже уровень стратегии развития проекта. Стабильность, популярность, экосистема, поддержка и кол-во спецов на рынке гораздо важнее сэкономленных килобайтов (тем более это всё относительно и со временем сойдёт на нет). Единственное, с чем соглашусь, что подключение увесистого jQuery UI ради одного компонента — моветон, если есть возможность найти аналогичный jQ/standalone-компонент.

            Далее вы начали уже мешать архитектуру, фреймворки и UI. А jQuery — это база для кросс-браузерного UI (не путать с jQ UI).

            Так что же теперь думает Ваня о своих чудесных предшественниках? и считает ли он их программистами?
            Если плагины хорошие, грамотно написаны и поддерживаются, то всё неплохо, как минимум. Гораздо хуже было бы, если
            drag & drop, слайдеры, скролеры, карусели, зумеры, табы, дейтпикеры, маски…
            представляли из себя велосипеды не самого лучшего качества, которые никто кроме самих авторов поддерживать не может (и уже не будет). Есть, конечно, вариант, что эти самописные компоненты будут грамотно написаны, оттестированы и заопенсорсены (+ появятся контрибьюторы, соответственно и поддержка). 1) Вопрос: сколько на это потребуется времени? (а время — деньги) 2) Вероятность такого поворота, в контексте вашей версии истории, близится к 0 (пока не придёт Ваня :).

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

            Если веб-приложение тормозит, jQuery стоит в конце списка, где может быть проблема.

            P.S. Есть хорошее английское выражение — «It depends ...». Всё зависит от требований, проекта, браузеров, команды, сроков (!) и т.п. Если проект делается под нормальные браузеры и сроки вменяемые, сами с удовольствием и по возможности делаем standalone-компоненты, там где это уместно.

            Мне лично нравится концепт модульности небольших компонентов/либ проекта Component (что это такое, список плагинов, github) — своего рода unix-way для фронтенда (по большей части), но он пока только набирает обороты.
              +1
              Да, и в контексте вашей версии истории, главный косяк-то в руководстве «аутсорс»-конторы, которое не сумело определить, что товарищ-то пока ещё не совсем опытный для позиции «ведущий фронтендер». Когда в проекте грамотный тимлид и ведущие по своей части, степень бардака резко снижается.
                –2
                Правда ваша, но историю по сути своей и придумывать не пришлось… Сам конечно использую jQ для кроссбраузерности в местах где это действительно нужно, но порой и от него получается непредсказуемое поведение, с различными результатами в разных браузерах.

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

                естественно, но вот код, который написан на нем, как правило, «хорошими знатоками» js… мягка говоря, качественным не назовешь.
                Доводилось видеть, как каждый верстальщикфронтедер, освоивший запись $()… подключает библиотеки и при использовании их, допускает ошибки в js, о которых в любой книге написано с первых строк.
                  0
                  забывая, что речь о jQuery 2.0.
                  Версия мало имеет значения, главное — экосистема, стабильность, преемственность API и далее по списку в моём предыдущем комменте (уже 3-й раз повторил :)

                  естественно, но вот код, который написан на нем, как правило, «хорошими знатоками» js… мягка говоря, качественным не назовешь.
                  &
                  Доводилось видеть… допускает ошибки в js
                  Да всем, на всех языках программирования, доводилось видеть всякое. Это же не повод экстраполировать.

                  В общем, вывод очевиден: дело-то совсем не в инструменте (jQuery), а в не очень опытных падаванах. Чем выше популярность языка, тем чаще встречается «всякое». Суть претензии к jQuery в том, что это «всякое» может вполне себе работать, но тут ведь только от падавана зависит желание учиться как делать правильно (и, в идеале, под присмотром коллег-мастеров).
              0
              Как же это знакомо. Бывает откроешь исходный код какого нибудь супер навороченного ГС, а там содержимое head в виде простыни — длиннее/массивнее body. И это только подключаемое. А вот в качестве бонуса в хедер ещё вставляют сам JS код.
            0
            ejohn.org/blog/thoughts-on-queryselectorall/ — я просто оставлю это здесь. И как написали выше, этих НО накапливается целая кучка. Я не призываю использовать jQuery, но это не отменяет обвязок, которые нельзя просто взять и заменить на натив код.
              0
              нельзя просто взять и заменить на натив код.

              То есть js-фреймворки пишут не на натив js?
                +6
                только на других фреймворках… я проверял!
                  +1
                  Был какой-то хороший фреймворк, который всё умел и который сам с первой версии был собран на себе. Сначала был написан код на языке этого фреймворка, который преобразовывал код в жс. После чего на этом фреймворке написали сам фреймворк и с помощью ручки и бумаги вручную преобразовали его в нативный жс, прогоняя функцию преобразования в голове.
                    0
                    Это лишь легенда, сынок…
                  0
                  Неудачно выразился. Я хотел сказать, что var $ = document.querySelectorAll.bind(document) и подобные замены, не всегда можно использовать как есть.
                    0
                    Это просто пример краткой записи, как альтернатива sizzle, конечно же эта конструкция в большинстве случаев лишена смысла, но не во всех.
                      0
                      Я и говорю, что такая запись не может быть альтернативой и в реальной ситуации приведет к «багам», о чем и написано по ссылке.
                        0
                        В jquery2 реализована модульная система и можно сделать custom build, который содержит только нужное.
                        Также, сделана абстракция querySelector и есть обертка над native вместо sizzle. Подробности: github.com/jquery/jquery/blob/master/src/selector-native.js
                  +1
                  1. var $ = document.querySelectorAll.bind(document) — сильно ограничен в возможностях, т.к. выборка будет всегда с корня; есть ещё такой вариант:
                  var $ = Function.prototype.call.bind(HTMLElement.prototype.querySelectorAll);
                  // use:
                  var somediv = $(document.body, 'div')[10];
                  var spans = $(somediv, 'span');
                  

                  2. jQuery силён своей экосистемой, поддержкой и стандартами. Время, когда большая часть браузеров будет нормальными, совсем скоро, соотвественно и ядро jQ будет весить совсем немного (как Zepto ±).
                    0
                    Спасибо за статью — тема актуальная. Однако что касается визуальных эффектов имеет смысл полагаться на
                    requestAnimationFrame (http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/ или vimeo.com/77905678) вместо timer loops, так как этот именно метод предназначем и оптимизирован для подобных задач.
                    Относительно совместимости — это вопрос компромиса. Девелопер может по-прежнему писать Vanilla JS и использовать shim (скажем, из MDN коллекции, как это делает Лиа Вероу). Опять же проверка совместимости нынче не проблема. Достойный код должен быть густо покрыт тестами в любом случае. И далее в ходе интеграции (по коммиту) когда тесты будут отправлены на www.browserstack.com/ (скажем через bunyip) — отчет покажет определенно насколько кроссбраузеная поддержка имплементации соответсвует ТЗ. Опять же помним о YAGNI — если поддержки IE6 нет в требованиях, держать код поддержки в проекте точно не лучшая идея
                      +1
                      А как же промисы в аяксе? без них не прикольно, когда его много.
                        +7
                        «сам писал на jQuery до того, как освоил javascript… „
                        Для меня это звучит дико. Примерно как “я считал на калькуляторе до того, как освоил арифметику». А jQuery — просто библиотека, позволяющя некоторые вещи делать проще, быстрее и кроссбраузернее. Иногда можно без нее, иногда нужно без нее.
                          0
                          Для меня сейчас тоже звучит дико, но, к сожалению, много кто так и пишет, используя jquery и толком не зная js.
                          +1
                          Раньше в проектах где объем js не превышает сотни строк обходился без jQuery. Проблемы начинались позже. Когда через пару лет возвращался к ним. Приходислось заново открывать код самописных хелперов чтобы понять что-же они делают. Далее добавляется много нового функционала, часть из которого намного проще реализовать плагинами jQuery. В итоге грохаются самописные хелперы и код переписывается.

                          Я только за Vanilla, когда используются только простейшие манипуляции, но я давно уже не сталкивался со случаями, когда ими все ограничивается. Чаще наоборот, одного jQuery мало и приходится использовать другие фреймворки которые работают вместе с ним или заменяют его. Чем дальше, тем больше киентский код становится сложнее серверного.
                            0
                            jQuery — это прекрасная возможность написания спагетти кода. Возврат к комбам из жквери через год намного хуже чем к коду, написанному в виде разбивки на MVC.
                              0
                              а тут не принипиально, Vanilla или jQuery)
                                0
                                Именно, грамотно написанный компонент для страницы, с помощью классов и MVC, будет на много понятен, расширяем и гибок в использовании, чем любой плагин.

                                Поясню:
                                Понятен. По умолчанию компонент разделен на составляющие MVC, каждый решающий свои задачи. Никому в голову не взбредет искать логику модели на вью компоненте и наоборот. И даже по прошествии года/двух, любой человек знающий javascript разберется в нем, чего нельзя сказать о плагинах, которые на этот момент уже устаревают, а новые версии несколько раз переписаны под новые релизы jquery или вовсе больше не поддерживаются и тд… В итоге получаем стек устаревших(возможно с багами) плагинов, обновление которых требует других зависимостей и практически невозможно на крупном проекте, из-за того, что обновление jQuery ломает кучу всего.

                                Расширяем.
                                Если кому-то понадобится дополнить/поменять функционал, достаточно будет наследовать/изменить/дополнить существующий класс или метод, не забыв конечно про тест спеки.

                                Гибкий в использовании.
                                Компоненты, как отдельные сущности и не зависят друг от друга. Использование компонент, не перегружая какие-то базовые вещи, как это делает jquery ($.fn...).
                              –5
                              Поставил бы плюс автору но увы не хватает кармы. Хотя примеры приведены не самые удачные.

                              На моей практике большей части случаев jQuery использовался ради $('#elementId'). Сам же предпочитаю VanillaJS.

                              К слову о том что пишут мол много полезных плагинов у jQuery. Даже если исключить то что многие криво работают так регулярно под конкретные задачи их еще и переписывать надо. В конечном счете регулярно написать «велосипед» в контексте своего проекта куда быстрей и понятней (про понятность подразумевается для тех самых Вань из комментария выше).
                                0
                                Минусы лишь говорят о том сколько людей либо знают фреймворк и не знают сам язык. Либо $(...).сделать_как_надо(); всегда им было достаточно. Но ничего и на вашу улицу придут менеджеры которые скажут что там еще не хватает блекджека и прочих гениальных идей.
                                +4
                                Ок, решено, отказываемся от jquery on, у нас же есть addEventListener.
                                А что с live? Ну мы можем смотреть event.target и сравнивать там, например event.target.className, вроде норм.
                                className состоит из нескольких классов? Не проблема, разобьем строку по пробелам или регуляркой чекнем в конце концов.
                                А что если в целевом элементе есть другие элементы и мы кликнули по ним, ведь в event.target попадет не то что нам нужно? Значит пробежимся по dom'у вверх и сделаем проверку для каждого элемента.
                                Хм, а что если обернуть всё это красиво в функцию, ведь забодаешься всё это каждый раз писать.
                                А вобще, ну его к черту, пойду обратно на jquery
                                  0
                                  className состоит из нескольких классов? Не проблема, разобьем строку по пробелам или регуляркой чекнем в конце концов.

                                  Есть нативный classList, например: element.classList.add('hide'). IE10+
                                    +1
                                    В посте речь о 2.0 где в свою очередь .live() отсутствует.
                                    Deprecated 1.7 / Removed 1.9 пруф.
                                      +1
                                      Я под live подразумеваю возможность в on вешать обработчик на родителя. Потому — что такая фича появилась сначала в live, потом её в delegate перенесли с указанием контекста, а потом в функцию on.
                                        0
                                        Данная функция не работала с элементами, создающимися динамически.

                                        jsfiddle.net/u7DDV/

                                        var b = $('<button>Click</button>');
                                        
                                        b.appendTo('body');
                                        
                                        b.live('click', function() {
                                            alert('Click');
                                        });
                                        

                                        Неплоха практика навешивания обработчика на контейнер через on(selector, listenerFn). Собственно все тот же live().
                                        0
                                        Но jQuery делает именно это в live или добавлении класса. Только он делает попутно слишком много операций для обруливания кейсов, которые обычно не нужны. То есть $('#123') будет заметно медленнее document.getElementById не потому, что sizzle медленный, и не потому, что тут будет большой коллстэк пока мы дойдёт до гет бай ид, а потому, что попутно он проверит — а не стрингу ли мы передали, начинающуюсю и кончающуюся тегом, а не массив ли это. И получается что мы пришли валить деревья очень удобным блестящим швейцарским ножом, который угадывает что сейчас нам нужна пила, пробуя попутно сковырнуть ствол дуба отвёрткой.
                                        +1
                                        Этот пост про Vanilla JS было интересно читать, потому что он был наполнен юмором, и никто его всерьез не воспринял. А вы же предлагаете бред какой-то.

                                        Лет 6 назад, когда я еще в классе 8 был, когда ie7 только только вышел, решил для себя что буду писать на чистом js. Собственно знаний в нем не было никаких, а jquery невзлюбил за то, что каждый, кому не лень, предлагал его как панацею. По началу мне потребовалось совершить несколько манипуляций над стилями элементов, потом повесить несколько обработчик и в общем-то сейчас для подобных целей я бы тоже не стал использовать jquery, но в те времена изрядно намучился, так как никаких querySelectorAll еще не было (хотя по большей части, потому что делал все впервые).

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

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

                                        Через пару лет я на хабре увидел реализацию чата, где с помощью jquery слались ajax-запросы и происходили манипуляции с dom. И вот тогда меня поразило с какой простотой делается то, над чем я убил однажды несколько дней. В тот момент начал его потихоньку использовать, но боязнь к библиотекам осталась. И я писал свои слайдеры, паралаксы и прочее, тратив на это много времени, но делал все это только ради обучения.

                                        В этом году я устроился на работу. И у меня ни разу не возникало дилеммы, скачать ли библиотеку (которая состоит-то из 100 строчек, но зато отлажена) или написать, протестировать и использовать свою функцию (объект) и убить на это времени раз в 50 больше. Так же в проектах различных анимашек, манипуляций с деревом и ajax-запросов, ui-елементов обычно очень много, и клиентский код чаше намного больше серверного. И поэтому помимо jquery и jqueryui обычно подтягивается еще с пару десяток библиотек и плагинов к библиотекам. И иногда из всей этой солянки получается кромешный ад, но тут уже вопросы к построению процесса разработки, архитектуры проекта и прочего, при использовании лишь «Vanilla JS» в подобных проектах и при прочих равных условиях, я уверен, что этот ад был бы в десятки раз хуже.

                                        А вот когда для себя и есть время, то стараюсь писать на чистом js, прорабатывая заранее архитектуру, создавая красивые обертки и велосипеды. И обычно в рамках объектно событийной модели, да там все красиво, понятно и быстро работает. Так же частенько по вечерам почитываю стандарты и различные гайды, и все это повышает скил. Но мне все равно совершенно не понятно, как можно разрабатывать более-менее средний по объему командный проект и не использовать библиотеки, отлаженные и со своим большим сообществом? Точнее понятно, но мне сложно представить заказчика у которого будут подобные требования или который заплатит за такую работу.
                                          –1
                                          Да автор топика молодец!

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

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