bala.js — убийца jQuery в менее чем 400 символах кода *

  • Tutorial
* Это шутка.

image
(картинка позаимствована где-то в интернете)

[ Репозиторий ]

Всем привет.

Уже давно прошли времена обязательной поддержки 6, 7, 8 Ослов и неизбежного использования jQuery, DOM API постепенно приводится к единому виду, но я всё так же часто встречаю на просторах интернета утверждения о том, что VanillaJS — это длинная колбаса.

Мол, зачем мне писать вот так:
document.querySelector('.selector');

Если я могу написать вот так:
$('.selector');

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

// selects one node matched given selector
function $(selector, ctx) {
	return (ctx || document).querySelector(selector);
}

// selects all nodes matched given selector
function $$(selector, ctx) {
	return [].slice.call((ctx || document).querySelectorAll(selector));
}

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

Но я совершенно несогласен с тем, что для обычной выборки нужно подклюать что-то большое (Zepto, jQuery).

«Движение» против использования jQuery и за использование нативных методов DOM существует уже несколько лет. Вспомним два самых известных сайта youmightnotneedjquery и vanilla-js. Оба сразу отталкивают новичка устаревшими альтернативами. vanilla-js показывает ужасные примеры использования AJAX и анимаций, второй грешит только беспощадным XMLHttpRequest. Оба сайта ни слова не говорят о Fetch API.

Хотя, если присмотреться, и с анимациями у второго не всё гладко. В качестве альтернативы они предлагают воспользоваться transition, хотя CSS Animations существуют давно и, самое главное, Web Animations JavaScript API уже имплементирован в Хроме и Файерфоксе и неплохо полифилится для других браузеров.

***

Для того, чтоб получить небольшую DOM библиотеку с минимальным необходимым набором методов, я когда-то сделал библиотеку, с шуточным названием balalaika.js. Напомню, балалайка — jQuery-подобная микробиблиотека, с очень небольшим набором методов: on, off, is, extend.

Но и она устарела. Метод is потерял свою актуальность, так как метод matches стал кроссбраузерным. extend самоуничтожился, так как в JavaScript пришел Object.assign, on и off просто-напросто не нужны, по причине, озвученной выше: фреймворки.

Я решил немного обновить эту библиотеку, выпилив все методы и оставив только функциональность, отвечающу за выборку элементов. Так как это изменение полностью ломает совместимость с балалайкой, было решено вынести её в отдельный проект с другим названием «bala» — обрубленное старое название (как и библиотека), — «пуля» по-испански.

Кроме всего прочего, целью bala.js является улучшение того, что сейчас иногда называют «плагинами к VanillaJS». Я очень люблю библиотеки без зависимостей, но почти все они предлагают инициализировать скрипт с передачей DOM Element.

myAwesomeLib(document.getElementByID('block'));

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

Что добавлено?


Крайне часто, при выборке, требуется только одна нода (например, для вызова appendChild). Но каждый раз запрашивать нулевой элемент выборки никому не нравится.
$('.selector')[0].appendChild(node);

Поэтому, была добавлена симпатичная альтернатива в виде статичного метода $.one, который работает в точности так же, как и основная функция, но возвращает нулевой элемент или null
// всего одним символом  больше, а выглядит на тысячу символов лучше
$.one('.selector').appendChild(node); 

$.one, кроме всего, служит двум целям: не создавать дополнительную переменную (в таких библиотеках их обычно две: $$ и $) и оставить возможность симпатичного импорта.

import $ from 'balajs';

var $ = require('balajs');


Что осталось от Балалайки?


Возможность передать в функцию всё, что угодно: селектор, узел, массив, NodeList, jQuery и любой другой array-like объект
$('.one, two')
$(document.querySelectorAll('.selector'));
$(document.body);
$(element.children);
$(jQuery('.selector'));
$([document.querySelector('.one'), document.querySelector('.two')])

Поиск элемента в другом элементе
var elements = $('.my-selector', element);

DOM ready
$(function() {
  alert('DOM is ready');
});

Не забывайте, что вместо использования DOM ready можно просто указать скрипты в конце тега body
    ...
    <script src="app.js"></script>
  </body>
</html>

Парсинг
var div = $('<div><span class="yeah"></span></div>');

Парсинг контекстных элементов
Для персинга элементов, требующих контекст, нужно передать имя тега-родителя (он создается динамически), например, для парсинга td нужно передать tr, для парсинга tr нужно передать tbody, для парсинга option нужно передать select.
var cells = $('<td>foo</td><td>bar</td>', 'tr');

Плагины
Расширять bala.js можнно как и любую другую jQuery-подобную библиотеку.
$.fn.toggle = function(boolean) {
  this.forEach(function(item) {
    item.hidden = boolean;
  });
};

$('.button').toggle(false); // hides all buttons


Как использовать?


Как глобальную переменную на странице
<script>
$=function(d,e,c,f,g){c=function(a,b){return new f(a,b)};f=function(a,b){e.push.apply(this,a?a.nodeType||a==window?[a]:""+a===a?/</.test(a)?((g=d.createElement(b||"q")).innerHTML=a,g.children):(b&&c(b)[0]||d).querySelectorAll(a):/f/.test(typeof a)?/c/.test(d.readyState)?a():d.addEventListener("DOMContentLoaded",a):a:e)};c.fn=f.prototype=e;c.one=function(a,b){return c(a,b)[0]||null};return c}(document,[]);
</script>

<script>
    $(function() {
        alert($('.my-selector').length);
    });
</script>

Как локальную переменную в IIFE
(function(win, $) {
    // your code starts here
    $(function() {
        alert($('.my-selector').length);
    });
  // your code ends here
})(window, function(d,e,c,f,g){c=function(a,b){return new f(a,b)};f=function(a,b){e.push.apply(this,a?a.nodeType||a==window?[a]:""+a===a?/</.test(a)?((g=d.createElement(b||"q")).innerHTML=a,g.children):(b&&c(b)[0]||d).querySelectorAll(a):/f/.test(typeof a)?/c/.test(d.readyState)?a():d.addEventListener("DOMContentLoaded",a):a:e)};c.fn=f.prototype=e;c.one=function(a,b){return c(a,b)[0]||null};return c}(document,[]));

Можно установить bala.js с помощью NPM
npm install --save balajs

Больше примеров


Перебор
True-way
for(let element of $('.button')) {
  console.log(element);
}

или old-school-way
$('.button').forEach(function(element) {
  console.log(element);
});

Добавление стилей
$('.my-selector').forEach(function(element) {
    element.style.color = 'red';
});

или, если нужно изменить стиль только для одного элемента:
$.one('.my-selector').style.color = 'red';

Делегирование событий
С методом closest не нужно использовать страшный while.
$('.my-selector').forEach(function(element) {
  element.addEventListener('click', function(evt) {
    if(this.contains(evt.target.closest('.delegated-selector'))) {
      alert('yep!');
    }
  });
});

или так
$.one('.my-selector').addEventListener('click', function(evt) {
  if(this.contains(evt.target.closest('.delegated-selector'))) {
    alert('yep!');
  }
});

Удаление элементов
$('.my-selector').forEach(function(element) {
    element.remove();
});

Удаление одного элемента
$.one('.my-selector').remove();

Вам может понадобиться полифил DOM4 для методов element.remove и element.closest.

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

Вам всё еще нужен jQuery?

Если да, ниже еще два примера.

Анимации

С помощью Web Aimations API можно прописывать анимации прямо в JS коде (они будут многократно быстрее, чем таковые из jQuery, благодаря GPU ускорению).

// код позаимствован из гугловской статьи
$.one('.my-selector').animate([
  {transform: 'translate(' + snowLeft + 'px, -100%)'},
  {transform: 'translate(' + snowLeft + 'px, ' + window.innerHeight + 'px)'}
], {
  duration: 1500,
  iterations: 10,
  delay: 300
});


Само собой, это работает и без всяких библиотек (не счтиая того, что вам может понадобиться полифилл Web Animations API).

Ajax
А вот пример обращения к серверу. Fetch API элегантно заменяет устрашающий XMLHttpRequest.
fetch('user.json')
  .then(function(response) {
    return response.json();
   })
  .then(function(user) {
    console.log(user);
  })
  .catch(alert);

Вам может понадобиться полифил Fetch API.

Всё еще хотите подключить jQuery? Серьезно?

Да, для поддержки старых Internet Explorer и Webkit-based мобильных браузеров вам придется подключить полифилы. Но не спешите кидаться какашками и вспомните, что Internet Explorer, с недавних пор, ведет себя хорошо, имплементируя самые невероятные фичи раньше, чем это делают люди занимающиеся Blink и V8, обещая в скором времени отказаться от поддержки всех версий до 11; люди покупают новые айфоны с обновленным сафари…

А еще, предлагаю ознакомиться с этим сервисом: polyfill.io. Ребята полифилят фичи глядя на User-Agent посетителя страницы. Спасибо chico и RReverser за находку.

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

Подробнее
Реклама
Комментарии 193
  • +71
    убийца jQuery
    может понадобиться полифил Fetch API
    может понадобиться полифил DOM4
    может понадобиться полифилл Web Animations API
    Откуда вы такие берётесь?

    метод matches стал кроссбраузерным
    Вы называете кроссбраузерными методы, работающие в Android-браузере и IE только через префиксы? Серьёзно?

    Да, для поддержки старых Internet Explorer и Webkit-based мобильных браузеров вам придется подключить полифилы
    То есть обязательно.

    Internet Explorer, с недавних пор, ведет себя хорошо <…> обещая в скором времени отказаться от поддержки всех версий до 11
    Это вы про браузер с 6 режимами эмуляции, который не пишет в юзер-агенте свою версию?
    люди покупают новые айфоны с обновленным сафари
    Очень мило. Осталось рассказать об этом прочим пользователям

    Итого
    Вы предлагаете вместо старой проверенной и надёжной jQuery, которая умеет почти всё, что вообще может придти в голову, использовать библиотеку с 4 методами и 3 (три) полифила для неё.
    Я ничего не упустил?
    • +45
      Злой у вас комментарий какой-то.
      • +68
        Добро пожаловать на Хабр
        • 0
          Ну уж как есть.
          • +3
            Давайте правде в глаза смотреть, ваша библиотека + все полифилы:
            1. легче чем jquery?
            2. удобней чем jquery?
            3. функциональней чем jquery?

            Представьте себе что вам советуют вместо одного инструмента использовать 6? Неужели это удобней? Вы забыли описать самое главное — какие преимущества?
            • –4
              1. легче чем jquery?
              Зависит от пдерживаемых браузеров.
              2. удобней чем jquery?
              Это холиварный вопрос. Для меня — да.
              3. функциональней чем jquery?
              Да.
              Представьте себе что вам советуют вместо одного инструмента использовать 6? Неужели это удобней?
              Да. В качестве параллели могу пивести PostCSS. В в нем нет ничего, нужно юзать плагины а свой вкус. В SASS есть всё. Но всё больше людей используют PostCSS (в том числе и я). Да и полифилы вряд ли можно назвать инструментами. Скорее, это — костыли для старых браузеров.
              Вы забыли описать самое главное — какие преимущества?
              Какие преимущества нативного DOM? Окей.
              1. Максимальная скорость работы кода.
              2. Полный контроль над работой DOM.
              3. Отсутствие зависимостей.
              4. Меньший размер результирующего файла.
              5. Полифилы можно выпилить со временем, библиотеку — нет.
          • +3
            Да, для поддержки старых Internet Explorer и Webkit-based мобильных браузеров вам придется подключить полифилы
            То есть обязательно

            Совсем не обязательно. Поддерживаем на некоторых наших проектах только IE11+ и в ус не дуем.
            • +7
              Такие проекты есть, но они скорее исключение. Обычно это что-то некоммерческое или рассчитанное на относительно узкую аудиторию. Для типичного коммерческого сайта это неприемлемо почти всегда. И в первую очередь — андроиды 4.x.
              • –8
                Крупные, коммерческие сайты предпочитают обзовестись специализированным ПО под андройды и иосы.
                • +5
                  Во-первых, я не говорил «крупные» — и мелкие коммерческие тоже. Они не могут себе позволить разбрасываться пользователями.
                  Во-вторых, я знаю немало людей, которые используют vk, fb, lj и далее по списку — через браузер.
                  • –7
                    А я знаю не мало людей, которые используют через браузер и «плюются», потому что не удобно.
                    • +6
                      Есть и такие. Но что это меняет в контексте данного разговора? Ничего.
                      Нативное приложение это, несомненно, хорошо и полезно — но:
                      а) оно далеко не всегда есть
                      б) даже если оно есть, это недостаточная причина, чтобы полностью забить на сайт
                      • –2
                        а) оно далеко не всегда есть

                        Далего не всегда есть — это аргумент, чтобы пилить мобильную версию сайта, которой менее удобно пользоваться, чем ПО?
                        б) даже если оно есть, это недостаточная причина, чтобы полностью забить на сайт

                        Что значит «полностью забить на сайт»? Я не предлагал написать ПО и вернуть сайт в 2000чные, или по вашему отказ от jQuery сопостовим с «забиванием на сайт»? Как то сильно вы любите эту либу )
                        • +1
                          Хватит демагогии.

                          Я имел в виду, что это не причина, чтобы отказываться от поддержки нетоповых, но всё-таки довольно распространенных браузеров (IE10 и старые Андроиды).
                          А уж как эта поддержка будет сделана, на jQuery или чем-то ещё — вопрос второй.

                          А поддерживать сейчас только «IE11+ и в ус не дуть» — это всё-таки удел меньшинства сайтов, как бы кому-то не хотелось доказать обратное.
                          • 0
                            IE10 распространённый браузер? Я давно не видел статистики по нему меньше процента
                            • 0
                              1,5%: gs.statcounter.com/#desktop+tablet-browser_version_partially_combined-ww-monthly-201509-201511-bar
                              и, внезапно, там и IE8 целых 2% имеет
                              • 0
                                Я не буду спорить насчёт правдивости этой статистики, так как у меня нет никаких данных на этот счёт.

                                Просто отмечу что:
                                1) Есть другая статистика, который тоже на первых строчках в гугле по запросу «browser statistic»: http://www.w3schools.com/browsers/browsers_explorer.asp

                                2) Мы в своём продукте (SPA) поддерживаем IE11+ и жалоб пока нет.
                                • 0
                                  1) Есть другая статистика, который тоже на первых строчках в гугле по запросу «browser statistic»: www.w3schools.com/browsers/browsers_explorer.asp

                                  Стоит отметить, что статистика w3schools.com основана лишь на посетителях этого сайта, которые по большей части являются веб-разработчиками. Статистика statcounter.com идет с тысяч сайтов где установлен их виджет для аналитики, поэтому, скорее всего, более точно отображает «среднего пользователя».
                              • 0
                                Сейчас посмотрел статистику одного своего сайта (совершенно обычный небольшой сайт по продаже автокомплектующих) — десятка имеет 4%.
                                А суммарно IE c 8 по 10 — около 7%.
                                Вполне ощутимо.

                                Конечно, если судить по «модно-молодежным» сайтам типа соцсетей и хабра, то там скорее всего будет сильно иначе. Но надо хоть иногда выглядывать в реальный мир обычных людей.
                                • 0
                                  Пример статистики с боевого сайта, проекта посвященного ММО игре:
                                  image

                                  Так что не надо пожалуйста про нераспространенной IE;)
                                  • +1
                                    Против MSIE 11 вроде как никто не возражал. Без 11 версии на ИЕ приходится уже незначительные 1.5%.
                                    Для полноты картины хотелось бы увидеть еще статистику доходов по браузерам. А то окажется, что эти 1.5% генерят 0.000001% прибыли, тогда вообще о чем речь.
                                    • 0
                                      Ключевые слова тут — «MMO игра». То есть пользователи — молодежь. Давайте еще статистику ЛОРа посмотрим и сделаем по нему глобальный вывод о популярности IE :)
                                      На сайтах с более разнообразной аудиторией доля IE больше в разы (например, см. мой комментарий чуть выше).
                                      • 0
                                        Вы, видимо, не так поняли смысл моего коммента, даже на сателлитном сайте ммо игры, доля ослика ощутимо велика.
                                  • +2
                                    Причина отказа от поддержки каких-то браузеров всегда одна (на коммерческих проектах) — решение менеджмента о её целесообразности. Грубо, если целевых пользователей IE 8-10 5%, а их поддержка удорожит разработку на 6%, то «IE11+ и в ус не дуть». Иди другой вариант: если замедление работы сайта из-за поддержки IE8-10 отпугнёт 6% пользователей, то тоже «IE11+ и в ус не дуть». То есть два фактора основных: сколько будет стоить поддержка и как она повлияет на нормальных пользователей.
                                    • 0
                                      Это всем известно. Но на практике отказываться от ie9-10 обычно особого смысла нет.
                                      Во-первых, они как правило не влекут какого-то чудовищного усложнения поддержки (это же не ie6 прости хоспади). Да, код будет менее чистым и красивым, но каких-то особых трудностей не будет. Хотя конечно бывает что влекут, в специфичных случаях.
                                      Во-вторых, репутационные потери. Заходит человек на сайт и видит, что он поломан. Он будет винить себя и свой браузер? Да ни в жизнь, он решит что сайт плохой и компания нищебродская.
                                      С андроидами так же.
                                      • +1
                                        Подобные вопросы вечны. Помнится стоял вопрос «отказываемся от поддержки ie <6 или нет». С тех пор у меня аргументы не изменились — это бизнес-решение, по которому мы, технари, можем лишь дать оценку затрат на поддержку устаревших клиентов в двух случаях (с деградацией и нет), плюс оценку затрат на «эмуляцию» современных и будущих пользовательских фич, внедрение которых будет сильно затруднено из необходимости совместимости. Ну и текущую статистику, если нет специально обученных людей. А там бизнес-решает.
                                        • 0
                                          Не совсем.
                                          Я убежден, что по умолчанию вопрос «надо ли поддерживать браузер X?» всегда имеет ответ «да».
                                          И только конкретные весомые причины могут сменить его на «нет».
                                          А то выше были рассуждения типа +6% издержек уже могут перекрыть -5% посетителей — так вот это недостаточно. Это примерно как не пускать в самолет людей ростом выше 195 и тяжелее 120 — ну а чо? Их же всего пара процентов, примем «оптимальное» бизнес решение.

                                          Достаточные причины:
                                          — издержки растут очень сильно (несколько десятков процентов и более)
                                          — доля браузера пренебрежимо мала (пара процентов это мала, но не пренебрежимо)
                                          — аудитория проекта очень четко очерчена (например сисадмины)
                                          • 0
                                            издержки растут очень сильно

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

                                            это бизнесу решать, какая пренебрежимо мала, а какая нет.
                                            • 0
                                              рассуждения типа +6% издержек уже могут перекрыть -5% посетителей — так вот это недостаточно
                                              Кому недостаточно? Вам? Вы отвечаете за издержки проекта и его окупаемость?
                                              • 0
                                                Недостаточно для человеческого отношения к клиенту/посетителю (см. выше пример про самолет).
                                                • 0
                                                  Ну вы уж определитесь — или вы про человеческое отношение к пользователю (и тут я с вами полностью согласен) или вы про бизнес, где любые решения на проекте имеют свою стоимость в деньгах (к сожалению).
                                                  • 0
                                                    Все в комплексе, не надо разделять.
                                                    В магазине есть удобные клиенты (пришел и, ничего не спрашивая, оставил 100500 денег) и неудобные (30 минут ездил по ушам, хотя по нему изначально понятно, что он не собирался покупать). Логично же второго просто выгнать? Но так же не делается (почему-то).
                          • 0
                            Такие проекты есть, но они скорее исключение.


                            И, конечно, у вас есть подтверждения этому?
                        • +9
                          Я проигнорирую фразу «Откуда вы такие берётесь?» и постараюсь ответить.
                          Вы называете кроссбраузерными методы, работающие в Android-браузере и IE только через префиксы? Серьёзно?

                          Да, действительно. Вот вам решение:
                          Element.prototype.matches = Element.prototype.matches || Element.prototype.webkitMatchesSelector || Element.prototype.msMatchesSelector;
                          


                          То есть обязательно.

                          Зависит от задачи. Если нужно поддерживать старые ослы, то будьте добры подключить полифилы. Это не сложнее чем подключение библиотеки.

                          Это вы про браузер с 6 режимами эмуляции, который не пишет в юзер-агенте свою версию?

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

                          Вы предлагаете вместо старой проверенной и надёжной jQuery, которая умеет почти всё, что вообще может придти в голову, использовать библиотеку с 4 методами и 3 (три) полифила для неё.

                          Я предлагаю функцию с нулём методов, которую можно использовать с полифилами, если того требует ваша задача. Если не нравится, то можно юзать querySelector[All]. Цель поста — не навязать кому-то мою разработку, а призвать пользователей юзать DOM API вместо библиотек.

                          DOM API тоже умеет воти всё, что вообще может прийти в голову и даже больше. Буду капитаном, но его используют разработчики библиотек, в том числе, разработчики jQuery.
                          • +1
                            Да, действительно. Вот вам решение:
                            Отлично. Больше странного кода для бога странного кода. Хотя нет, для этого лучше сделать ещё один полифилл. Хотя нет, лучше не делать полифиллы, не писать странный код, а пользоваться jQuery — стандартом де факто.
                            Зависит от задачи. Если нужно поддерживать старые ослы, то будьте добры подключить полифилы. Это не сложнее чем подключение библиотеки.
                            Если мы говорим про веб-разработку, то поддерживать надо всё, что поддерживается в пределах бюджета. И использование jQuery улучшает этот процесс.
                            Если вы пишете проект с долгосрочной поддержкой, полифилы в будущем можно удалить, а от библиотеки избавиться не получится, не переписывая код.
                            Согласен с вами. В теории (идеальном мире). На практике такого почти никогда не происходит — всё равно приходится переписывать.
                            Я предлагаю функцию с нулём методов, которую можно использовать с полифилами, если того требует ваша задача
                            Вы предлагает код, который почти ничего не делает и предлагаете его расширять нужными полифилами. И в чём разница с использованием jQuery с кастомными плагинами?
                            Цель поста — не навязать кому-то мою разработку, а призвать пользователей юзать DOM API вместо библиотек
                            DOM API — чудесно, но неюзабельно в реальных проектах без полифилов. А с полифилами выгода от переключения на него весьма сомнительна.
                            DOM API тоже умеет воти всё, что вообще может прийти в голову и даже больше. Буду капитаном, но его используют разработчики библиотек, в том числе, разработчики jQuery.
                            Иначе говоря, «это уже было в Симпсонах» — он уже используется в jQuery и преимущество от его использования уже есть и ваша библиотека не нужна.
                            • +1
                              А если так переформулировать «Иначе говоря, «это уже было в Симпсонах» — он уже используется в вашей библиотекеке и преимущество от его использования уже есть и jQuery не нужна»

                              Есть две библиотеки, делающие плюс-минус одинаковые вещи, плюс одна из них делает ещё кучу вещей (естественно ценной оверхидов по памяти, трафику, процессору). Зачем мне эта куча, если есть такая, которая делает ровно то, что нужно? Какие у jQuery преимущества перед bala.js в области применения последней?
                              • +3
                                Какие у jQuery преимущества перед bala.js в области применения последней
                                Допустим (я в это не верю, но допустим что так бывает), у вас действительно нет потребности ни в чём, кроме выборки DOM-элементов. Тогда вы правы — специализированная библиотека (например, bala.js) справится с этой задачей лучше. Более того, это Unix-way.

                                Но на моей практике все эти замечательные «мне тут только пару элементов в доме выбрать» постепенно приходят к «ну вот тут ещё нужно выбиралку дат сделать», «вон там неплохо бы сделать вкладки» и «вот тут нужен ползунок с двумя рукоятками». И в этот момент все предыдущие маленькие решения выкидываются и ставится jQuery, потому что он это всё делает хорошо.
                                • 0
                                  Или не выкидываются, а продолжают работать, если разработчик предпочитает Unix-way :)
                                  • +2
                                    И имеет под рукой хорошую библиотеку Unix-way модулей или резиновые сроки/бюджет.
                                  • +1
                                    Это, кстати, единственный юз-кейс, когда мне приходилось подключать jQuery. Очень много инструментов требуют зависимости от jQuery либо из-за лени или отсутствия знаний разработчика, либо из-за того, что инструмент достаточно древний. Сейчас не знаю, как с этим дела, надеюсь, лучше.
                                    • +1
                                      из-за лени или отсутствия знаний разработчика
                                      Это называется «удешевление и стандартизация разработки».
                                      • 0
                                        Нередко такое «удешевление» идёт без ведома ответственных за стоимость людей.
                          • +10
                            $ это гораздо больше чем document.querySelectorAll (именно All), например:

                            $('.xyz').append('<xyz />')
                            

                            И совершенно сразу пропадает желание вручную писать:

                            [].forEach.call(
                              document.querySelectorAll('.xyz'),
                              function (node) {
                                node.insertAdjacentHTML('beforeend', '<xyz />');
                              }
                            );
                            

                            А ещё там может быть не строка, а DOM элемент, или jQuery объект, тогда нужно будет добавить несколько условий и мы в итоге закончим тем, что напишем реализацию абсолютно аналогичную оной из jQuery. Вопрос: ЗАЧЕМ???

                            Перестаньте убивать jQuery, это бесперспективно, займитесь лучше проблемами, которые не были решены должным образом.
                            Инструменты нужно использовать там, где им место.
                            • +1
                              И совершенно сразу пропадает желание вручную писать

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

                              Если говорить о bala.js, то с Babel или без него (в случае поддержки только современных браузеров, например, при создании приложения под Electron), вы получете такой код:
                              for(let node of $('.xyz')) {
                                node.insertAdjacentHTML('beforeend', '<xyz />');
                              }
                              
                              • 0
                                напишем реализацию абсолютно аналогичную оной из jQuery

                                Вы настолько хорошо знакомы с внутренностями jQuery, что делаете такие мастабные выводы? Как вы считаете, насколько похудеет jQuery если лишить ее поддержки «особенностей» ie? А если еще отказаться от «особенностей» мобильных платформ?
                                • +4
                                  Если говорить об объеме в символах — то около 10% jQuery 3.0 можно будет вырезать, навскидку.
                                  Я уже давно использую версию 3.0, там древние версии IE по большей части вырезаны, как и старые версии мобильных браузеров.
                                  А по поводу внутренностей — там каждый символ на счету и очень тщательная проверка всех изменений.
                                  К примеру, из последнего: github.com/jquery/jquery/commit/eaa3e9f0cfc68083556cf61195821d90e369f646
                                  Рефакторинг чтобы сохранить дополнительные 21 байт. При этом не страдает читабельность, чего не скажешь про bala.js.

                                  Я к тому, что написать односимвольное сокращение для document.querySelector может любой, но даже самые типичные потребности идут гораздо дальше этого.
                                  • 0
                                    jQuery source viewer james.padolsey.com/jquery
                                    • –8
                                      Писал на ванильном джесе и пришел скорее к backbonejs, нежели к jquery. Что я сделал не так?
                                      • +7
                                        А ничего, что он использует jQuery?) backbonejs.org/#View-dollar
                                        • +3
                                          Вы не услышали мой комментарий. Я сказал что пришел скорее к backbonejs, нежели к jquery. Это означает, что структура моего решения позволила отказаться от вермишели jquery, но не позволила отказаться от архитектуры MV*.

                                          Если уж вы решили поделиться ссылкой, то поведую вам, что BackboneJS не зависит и не использует jQuery. jQuery для BackboneJS это всего навсего одна из реализации некоторого функционала. Его можно легко заменить на ZeptoJS или на свою ванильную реализацию, BackboneJS от этого не пострадает.
                                  • +1
                                    Просто как вариант:

                                    Array
                                        .from(document.querySelectorAll('.xyz'))
                                        .forEach(node => 
                                            node.insertAdjacentHTML('beforeend', '<xyz />')
                                        );
                                    
                                    • +1
                                      Я на LiveScript тоже компактнее пишу, специально написал на JS канонический вариант чтобы все поняли.
                                      Но это транспайлеры, суть от этого не меняется, это гораздо менее удобно чем jQuery. Для одноразового использования можно и нужно, но постоянно писать такой код — это слишком много визуального шума, читать такую простыню сложно.
                                  • +1
                                    • +1
                                      О ней я и говорил в посте, когда писал о двух переменных ($, $$). Если брать примеры с главной страницы, то всё это можно сделать средствами, которые я описал (анимация, fetch).
                                  • 0
                                    Предупреждал же, что микро-пакетные решения гораздо удобнее, чем фреймворки. Когда пакет устаревает, его можно выкинуть, заменив на ванильную реализацию, при этом остальные пакеты остаются в строю.
                                    • 0
                                      Я не понимаю, как это касается Матрешки, там всё по-прежнему на месте.
                                      • 0
                                        Ну что касается Матрешки это ваше дело, я говорю об устаревании функционала. Сборная солянка из микро-пакетов более гибкая в этом плане.
                                    • +4
                                      Бала — это ещё и «ребёнок» по-казахски:)
                                      • +1
                                        И по-татарски (видимо, и на любом тюркском языке). До пассажа про «е-» всерьез и думал, что это ассоциативный ряд «ребёнок» — «маленький» — «маленький фреймворк».
                                        • +1
                                          Пожалуй, уберу эту «шутку», извините за неё.
                                      • +5
                                        У меня только один вопрос: Вы всегда пишите минифицированный код сразу?
                                        • 0
                                          Так сильно сжать код, при этом сделав его читабельным — достаточно сложно. Я попробую расставить табы, спасибо за мысль.
                                          • 0
                                            Так, вроде, лучше.
                                          • +2
                                            Вы же в курсе, что x.querySelector(y) это не то же самое, что jQuery запрос с контекстом?

                                            Я про то, что querySelector всегда мэтчит от корня (документа), а не от указанного контектса. И обычно это НЕ то, что нужно.
                                            • +1
                                              Лично я не в курсе. То есть x.querySelector(y) делает поиск от корня и уже потом фильтрует?
                                              Не могли бы рассказать об этом подробнее?
                                              • 0
                                                www.w3.org/TR/selectors-api

                                                Even though the method is invoked on an element, selectors are still evaluated in the context of the entire document.


                                                Это API использует тот же движок, что и браузер при работе с CSS селекторами. По-сути, этим и обусловлено такое поведение.
                                                • +1
                                                  Ок, но я не вижу в этом ничего ужасного.
                                                  Пусть этот метод не настолько оптимален на сколько мог бы быть, но если профилировщик не показывает что его вызов является узким местом, то почему бы его не использовать.
                                                  • 0
                                                    Я ничего не говорил про проблемы. Лишь дал ответ на ваш вопрос.
                                                    Изначально формулировка (от другого человека) говорила о том, что реализация в jQuery будет отличаться от
                                                    element.querySelector()
                                                    

                                                    • 0
                                                      Проблема не в производительности, а в том, что результат не тот, что обычно нужен (если у вас есть контекст).
                                                • +2
                                                  Есть же http://zeptojs.com/ уже?
                                                  • 0
                                                    Это большая библиотека (хорошая, кстати), таких очень много. bala.js селектит элементы на странице, не более того.
                                                  • +3
                                                    А мне кажется, что попытки «свержения» «библиотек 'де-факто'» это своеобразный двигатель прогресса. В большинстве больших проектов жиквери уже не нужно — всё делает фреймвёрк, а в малых проектах жиквери и не нужно, можно обойтись «408 символами кода» ( finom ).
                                                    • –5
                                                      всё делает фреймвёрк
                                                      Да, в основном потому что jQuery встроен почти во все фреймворки.
                                                      • +2
                                                        Быть встроенным в и быть зависимым от — разные вещи
                                                        • 0
                                                          Хм, спорное утверждение.
                                                          • 0
                                                            Аргументирую. jQuery не встроен, например в Angular, React+Flux, Polymer. В других более мелких проектах есть возможность подключить пяток необходимых микро-библиотек, которые являются обертками поверх XMLHttpRequest аналоги $.ajax, сахаром для работы с DOM, Promises. Я считаю утверждение «jQuery встроен почти во все фреймворки» спорным, потому как почти каждый современный популярный фреймверк не тянет jQuery с собой и не зависит от этой библиотеки.
                                                            • 0
                                                              jQuery не встроен, например в Angular
                                                              В Ангуляр встроен jQlite — тот же jQuery, но без дублируемых ангуляром функций.
                                                              • 0
                                                                Это не тот же jQuery. Это ограниченный набор функций. Где нет ни методов для работы с XMLHttpRequest, ни промисов. Поэтому часто рядом с ангуляром подключают еще и jQuery.
                                                                • +1
                                                                  jQuery в angular-проект подключают явно не для ajax'а с промисами, ведь в ангуляре есть свои реализации.
                                                                  • 0
                                                                    Окей, теперь с Ангуляром у меня все стало на места. Согласен, Ангуляр является плохим примером фреймверка «без jQuery».
                                                                    Ну хорошо, продолжу Ext.Js (кстати довольно старый фреймверк, активно юзается в энтерпрайзе), Sencha Touch, Vue.js, Riot.js (последние два не столь популярны, но новы и известны в узких кругах).
                                                                    • +1
                                                                      Да нет, хороший пример. jQuery в ангуляре почти не нужен. ИМХО, его стоит подключать либо когда нужен какой-то jq-плагин, у которого нет достойных аналогов в виде ангуляр-модуля (или на чистом js), либо когда нужна какая-то прям очень сложная работа с DOM, с которой ангуляровские средства не справятся.
                                                                      С другой стороны, чаще всего в большом проекте какая-то библиотека всё-равно захочет jq себе в зависимости. А ангуляр умеет детектировать наличие jquery и использовать его заместо jqlite.
                                                      • –5
                                                        Я очень надеюсь что когда-нибудь авторов всех подобных поделок закроют в соответствующие лечебные заведения, а пока скрестил пальцы чтобы ни один идиот не додумался использовать этот велосипед где-то сложнее, чем на любительском homegrown-проекте.

                                                        Если бы я прийдя на проект увидел, что тут используется такое, был бы крайне недоволен.
                                                        • +2
                                                          Какое «такое»?
                                                          • 0
                                                            «Такое» = дополнительный велосипед, в который мне надо залезть, чтобы быть уверенным что я понимаю как он работает. Вместо того, чтобы просто тоже самое на чистом js.
                                                            • 0
                                                              Где для вас грань между «велосипедом» и «промышленным стандартом де-факто» типа jQuery? Только то, понимаете ли ві лично как оно работает? Или вы вообще не используете сторонний код?
                                                              • –1
                                                                Не нужно разводить демагогию, вы отлично знаете где эта грань: спросить у новичка, полгода-года работающего в отрасли, слышал/работал он с этой библиотекой/фреймворком или нет.
                                                                • 0
                                                                  Если новичок пришёл работать на один проект, то он и 5 лет может проработать на одном стэке технологий.
                                                                  • 0
                                                                    Нужно уметь продавать технологии на проект, убеждать, что это лучше для разширения и все такое. Но не городить все, что видишь новое.
                                                                • 0
                                                                  Поясняю.

                                                                  Минус этой вещи в том, что для ее использования требуется запомнить очередной API. Будь он хоть сто раз интуитивным, я сейчас не знаю это API и не хочу ео изучать. Я знаю jQuery/Zepto/подставьте_по_вкусу, которое умеет тоже самое.

                                                                  Если рассматривать этот код как пару функций, то ну что сказать — молодец автор, написал еще разок пару сто раз написанных функций. Можно скопипастить и использовать.

                                                                  А можно просто взять известную всем библиотеку или кусок ее кода не меняя ее API и ничего не выдумывая!
                                                                  Больше чем такие «убийцы jQuery» меня вымораживают разве что кадры, верстающие собственные grid layouts вместо того чтобы взять готовый из bootstrap или другой подходящей библиотеки.
                                                                  • 0
                                                                    Ну вот я не знаю API jQuery, вы не знаете, например, API prototype. Мне без разницы изучать на проекте jQuery или bala. А вам есть разница изучать prototype или bala?
                                                                    • –1
                                                                      Все фронт-энд разрабочики знают jQuery API, не надо прикидываться дурачком
                                                                      • –1
                                                                        я бы не был столь голословным, я знаю jq api только на уровне селекторов и некоторых очевидных методов. Не у всех фронэендеров задачи сводятся к jq.
                                                                        • +1
                                                                          А в этой статье разве не селекторы и не очевидные методы?

                                                                          Ребята, не стоит рассказывать сказки на IT-ресурсе, если человек не знает jQuery API на уровне описанных в статье вещей или не знает где в два клика взять документацию по этому API, то никакой он не фронт-энд разработчик.
                                                                        • +1
                                                                          Не все. Это факт.
                                                                          • +1
                                                                            Факт — это ваши слова? Или может есть что-то поубедительнее? А то я тоже так могу: jQuery знают все фронт-энд разработчики все. Это факт.
                                                                            • +1
                                                                              У меня вот есть кое-что поубедительнее. За последний год я провел ~60 интервью на позицию фронт-энд разработчика. Все, кто не знал jQuery API на уровне селекторов, установки событий, $.ready, $.ajax и прочего из статьи(совершенно дежурные вопросы, самый минимум) были совсем новичками, которых нельзя назвать готовыми к работе девелоперами. Максимум это уровень интернов.
                                                                              • –2
                                                                                Может чуть поменьше провел, но несколько человек не знали jQuery. Нюанс: они пошли на фронтендеров с бэкенда и декстопа и после азов js сразу начали учить Ангуляр.
                                                                                • 0
                                                                                  И в чем тут аргумент? В первом ангуляре используется jQuery API. В нем все это есть кроме анимаций по-моему.

                                                                                  Даже если и не знали, то это максимум уровень junior developer в таком случае. Это совершенно не показательно в качестве аргументации.
                                                                                  • +2
                                                                                    А если уж совсем быть честными, то никакие это не джуниор девелоперы, это бекендщики которые чуть-чуть почитали про фронтенд разработку. Это не делает их фронтенд-разработчиками автоматически. Ими делает практический опыт на реальных задачах, в процессе обретения которого человек по-любому столкнется с jQuery.
                                                                                    • –1
                                                                                      Откуда такая уверенность, что по-любому столкнется? Сколько процентов проектов, по-вашему, использует jQuery?
                                                                                      • 0
                                                                                        Моя уверенность основана на знаниях нескольких фактов плюс на том, что я вижу своими глазами. Факт первый — рынок фронт-енд разработки, и в мире, и везде, завязан на энтерпрайз. Быть крутым стартапером на последнем тех. стеке, быть понтовым контрибьютером в какой нить babel или что там у rock и делать свое «фи» на публику — это конечно круто, но погоду на рынке делаете не вы, ребята.

                                                                                        В энтерпрайзе 90% проектов тянут за собой легаси. До появления SPA-фреймворков наличие в этом легаси коде jQuery мне кажется вам сложно будет оспорить — он был везде. После появления SPA-фреймворков он был вытеснен тоже не сразу, backbone был очень популярен еще 2-3 года назад, и у него в жестких зависимостях jQuery. Если человек учит первый ангуляр, он обязательно столкнется с упоминанием jQuery в документации.

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

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

                                                                                        Когда-то я 5 лет работал на фрилансе верстальщиком, затем фронт-ентщиком. Думаю мое утверждение, что фриланс это тоже достаточно крупный рынок, хотя и с низкоквалифицированными специалистами в качестве исполнителей вас не удивит. Так вот, jquery там везде.

                                                                                        Вы лучше скажите, где его нет, и мы сравним размеры областей приведенных мной, и ваши примеры.
                                                                                        • 0
                                                                                          Факт первый — рынок фронт-енд разработки, и в мире, и везде, завязан на энтерпрайз.


                                                                                          Что вы называете завязкой на ентерпрайз?

                                                                                          До появления SPA-фреймворков наличие в этом легаси коде jQuery мне кажется вам сложно будет оспорить — он был везде

                                                                                          Не везде. Он постепенно занял лидирующие позиции, и как раз в легаси jQuery можно и не встретить, а встретить кого-то из его когда-то равных конкурентов типа prototype.

                                                                                          и у него в жестких зависимостях jQuery.

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

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

                                                                                          По моей личной статистике, использование jquery в проекте часто говорит о низкой квалификации разработчиков. Либо об отношении к проекту как к одноразовой задаче, которую будет поддерживать кто-то другой.
                                                                                          • –1
                                                                                            Что вы называете завязкой на ентерпрайз?

                                                                                            Я называю завязкой на энтерпрайз завязку на энтерпрайз. UI для крупных корпоративных приложений, если не понятно. В UI для корпоративных приложений старше пары лет, а то и свежих, jquery есть практически везде. Причем тут квалификация разработчиков, если мы говорим о фактах, о том что есть?

                                                                                            Не везде. Он постепенно занял лидирующие позиции...

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

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

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

                                                                                            По моей личной статистике, использование jquery в проекте часто говорит о низкой квалификации разработчиков

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

                                                                                            Казалось бы, что мешает открыть 50 вакансий от крупных компаний и посмотреть есть там в требованиях на вакансию jQuery или нет. Но нет, вам надо упорно продолжать выставлять себя идиотом.
                                                                                            • +1
                                                                                              Я называю завязкой на энтерпрайз завязку на энтерпрайз. UI для крупных корпоративных приложений, если не понятно.

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

                                                                                              Даже в 2005-м году?
                                                                                              человек, изучавший популярнейшие в мире фреймворки для SPA сталкивался с jQuery и соответствнно знаком с его API на уровне вещей описанных в статье.

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

                                                                                              О, уже переходы на личности, да с искажением фактов. Перечитайте мои комменты: в них я говорил, что к нам на вакансию веб-разработчиков, приходят HTML/CSS верстальщики, поверхностно работавшие с jQuery и потому считающие себя уже разработчиками, а не верстальщиками.
                                                                                              • –1
                                                                                                >Перечитайте мои комменты: в них я говорил, что к нам на вакансию веб-разработчиков, приходят HTML/CSS верстальщики, поверхностно работавшие с jQuery и потому считающие себя уже разработчиками, а не верстальщиками.

                                                                                                Можно подумать вас об этом кто-то спрашивал.

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

                                                                                                Мои тезисы:

                                                                                                1. Если вы решаете задачу, которая сто раз решена до вас, используйте хотя бы известный API.
                                                                                                2. API jQuery на уровне, описанном в статье знает любой фронт-энд разработчик.
                                                                                                3. Если человек не сталкивался с задачами на jQuery на уровне описанных в статье методов в статье, не считая бессмысленных здесь анимаций разве что — он не фронт-энд разработчик.
                                                                                                4. Верстальщик, умеющий плагины jQuery — это не фронт-энд разработчик.
                                                                                                • +1
                                                                                                  Мои тезисы:

                                                                                                  1. Обычно это имеет мало смысла. Только если разработчики «оригинала» не хотят развивать его в желаемом направлении, например не спешат отказываться от груза BC.

                                                                                                  2. Ложь.

                                                                                                  3. Ложь

                                                                                                  4. О чём я вам и толкую который день.
                                                                                                  • –1
                                                                                                    Вы просто херовый фронтенд-разработчик, вот у вас и бомбит:)
                                                                                                    • +1
                                                                                                      Бомбит то как раз у Вас, от осознания того факта что фронтенд можно делать без jquery :D
                                                                                                      • –2
                                                                                                        Лол. Я умею фронтенд даже без js.
                                                                                        • +1
                                                                                          На этот-то вопрос, как раз-таки, ответ есть.
                                                                                          trends.builtwith.com/javascript/jQuery
                                                                                          • 0
                                                                                            69% сайтов самых посещаемых сайтов в мире, по статистике Libscore.
                                                                                            • +1
                                                                                              Довольно далеко от 100%.
                                                                                      • –1
                                                                                        Я не знаю жуквери API так как не пользовал его уже года 3. Разве что базовую работу с селекторами вспомню. О, печаль-беда, я новичок и мой уровень — максимум уровень интерна :( Ох уж эти UI/UX инженеры, считающие, что жуквери это и есть JS.
                                                                                        • –1
                                                                                          Если вы использовали jQuery API, вы его знаете. Чисто для справки, на своих проектах я не использую jQuery, только для создания прототипов на скорую руку. Чем еще померяемся?
                                                                                          • 0
                                                                                            Чем еще померяемся?

                                                                                            Какие странные у вас желания.

                                                                                            Если я что-то не вспомню — значит я этого уже не знаю. Ферштейн?
                                                                                            • –1
                                                                                              Странная логика для человека, считающего себя программистом.

                                                                                              Если я что-то реально знал, но забыл, то это не значит что я этого не знаю. Это значит, что я знаю, но забыл. Что можно достаточно быстро освежить память, а не учить заново. Ферштейн?

                                                                                              Как можно изучить фреймворк и забыть? Такое бывает только если прочитал в интернете пару статей или книжку и не применял толком на практике. Скажите уж честно тогда — и не знали вы jQeury API. Что там можно забыть не понимаю.
                                                                                              • 0
                                                                                                Ага. Я уже не должен счить себя программистом и вру о том, что пользовал жуквери. Так и запишем.

                                                                                                Не много ли вы на себя берёте с такими-то утверждениями? :)

                                                                                                > Как можно изучить фреймворк и забыть?

                                                                                                Если учитывать количество фреймворков, которые мучал — легко и просто. А ещё жуквери не фрейморк.
                                                                                                • –2
                                                                                                  А вы не много на себя берете, начиная разговор с пассажа про UI/UX, считающих, что жуквери это и есть JS?

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

                                                                                                  Так вот, может быть у вас есть какая-нибудь своя статистика? Или только гордая позиция «я не такой, значит твои аргументы говно»? Отмазки «знал, но забыл» я слышал десятки раз, это всегда означает одно — нихрена ты, дорогой, и не знал.
                                                                                                  • –2
                                                                                                    Я занимаюсь версткой и фронт-енд разработкой тоже не мало лет и тоже пощупал немало библиотек. Но я, блин, не представляю как можно забыть jQuery API.

                                                                                                    Так что да, давайте вы тихо сольетесь и сведете тред в срач «jquery фреймворк или библиотека». Меня это устроит.
                                                                                                    • +1
                                                                                                      А вы не много на себя берете, начиная разговор с пассажа про UI/UX, считающих, что жуквери это и есть JS?

                                                                                                      Не много. Логичный вывод из ваших предыдущих комментариев.

                                                                                                      Я привел аргументацию

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

                                                                                                      нихрена ты, дорогой, и не знал.

                                                                                                      А вот за это можо (и нужно) по лицу при встрече. Запомним.

                                                                                                      Я занимаюсь версткой

                                                                                                      Оно и видно.

                                                                                                      Итак, значит я не тяну даже на юниора? :(
                                                                                                      • –2
                                                                                                        Защитан.
                                                                                                        • +1
                                                                                                          Ага. Хоть за языком верстальшик следить пока и не научился, но «щитать», похоже, учится, хоть и не ясно что. Того и гляди начнет JS осваивать.
                                                                                          • +2
                                                                                            Знали бы вы сколько мы отсеяли ведущих JS разработчиков, с 5+ годами работы, которые валятся на элементарных тестах на знание js. Мы скорее наймем человека который не знает jquery, потому что он реально что то знает и что то делал, а не гуглил последние 5ть лет нужный плагин в интернете.

                                                                                            Кидайте поменьше говна на вентилятор, есть проекты для которых jquery и нафиг не нужен, а с развитием новых стандартов эта тенденция только расширяется.
                                                                                            • –1
                                                                                              Вы там с rock бухаете что ли на пару? Где я вообще говорил что jQuery это хорошо?
                                                                                              Повторяю для особо тупых — по лично моим данным за год из примерно шестидесяти опрошенных девелоперов ни один человек, не знавший jQuery не оказался профессиональным фронт-энд разработчиком. Так понятно?

                                                                                              Ни один человек их опрошенных, не знавший jQuery, не оказался профессиональным веб-разработчиком, может быть так понятно? А?
                                                                                              • 0
                                                                                                Не, не понятно, капсом писать надо.

                                                                                                Мы вам говорим, что лично ваша статистика это не показатель дел в отрасли, у нас в компании jquery почти не используется и по лично моей статистике люди которые не знают jquery оказываются куда более компетентней людей которые его знают. Но Вы конечно и дальше можете тут биться в истерике и доказывать правоту вашей статистики.
                                                                                                • –1
                                                                                                  Не пользуются и никогда про jQuery не слышали? Что, реально? И какой опыт клиентской разработки у сотрудников вашей компании? И что вы такое делаете, может быть это нишевая вещь? Я ведь привел не просто статистику, а указал ее источник — энтерпрайз разработка.

                                                                                                  Естественно если у вас филиал FirefoxOS, вы не используете jquery. Но даже разработчики оттуда знают о нем. Приходилось общаться
                                                                                                  • 0
                                                                                                    Речь не идет о полном не знании jq, естественно о его существовании слышали все, но насколько глубоко знают люди апи jq? А самое главное, является ли это показателем уровня разработчика. Для меня большинство юзкейсов jquery это: получить элемент по селектору, снять/навесить обработчик, поманипулировать с dom и поставить снять класс. Но в jquery куда больше методов, только мне до них дела нет, и я их не знаю или не использую. А все то что чаще всего используется уже реализовано на уровне стандарта, так вот и вопрос, так ли он необходим этот jquery?

                                                                                                    Основной проект у нас 100M+ пользователей, да на основном проекте используется jq, но он там встроен в вреймворк и больше является рудиментом, 99% кода который пишут фронтенд разработчики никак не связан с jq.

                                                                                                    Так же есть ряд других проектов, в которых ситуация с jq такая же, а в некоторых он не используется вовсе.

                                                                                                    Что касается моих наблюдений об интервьюируемых мной людях, то очень часто к нам приходят люди которые имеют большой опыт работы фронтенд разработки на jq и странным образом они не могут объяснить такие простые вещи, как: чем отличаются GET от POST запросы, не знают как работают куки, не могут объяснить как распространяются события в браузере и я уже молчу про такие вещи как, замыкания, прототипы, ссылочные типы. Так кто же все эти люди которые много лет программировали фронтенд на jq?
                                                                                                    • 0
                                                                                                      А почему вы говорите о полном знании API? Я не говорил о полном знании API. Я в самом начале сказал, что то что написал автор поста плохо, потому что уже есть в jQuery с его известным каждому и хорошо документированным API. А в его код надо как минимум лезть и смотреть что он делает. Также я попытался объяснить что этот примитивный API известен абсолютно любому человеку, считающему себя фронтенд-разработчиком.

                                                                                                      Насчет наблюдений, опять же, почему вы считаете, что к нам не приходят точно такие же люди с 5+ лет опыта в резюме и знанием jquery без понимания js, где я такое говорил? Раз вы с Питера, то скорее всего одни и те же люди и ходят. Таких отсеивают в любой адекватной конторе. Только вот почему вы сами описали ситуацию, сами на нее мне пожаловались, а теперь вопросы по ней задаете мне, как будто я тут с чем то был не согласен?

                                                                                                      Что вы мне доказываете-то, я не могу понять?
                                                                                                      • 0
                                                                                                        Когда человек горит «я знаю API jQuery», то подразумевается, что он знает его весь, что на вопрос о любом методе он ответит хотя бы «этот метод делает то-то, но в детали я не вникал», а не «я знаю что $ позволяет получить элмент по селектору» — это даже я знаю, хотя jQuery не знаю.
                                                                                                        • +1
                                                                                                          >то подразумевается, что он знает его весь

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

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

                                                                                                          Я выше не поленился и ответил на ваш вопрос об областях применения. Ответ-то ждать?
                                                                                                          • 0
                                                                                                            Другими словами ни одной организации не надо, чтобы исполнитель знал API. А если соискатель утверждает, что знает, но не может ответить о назначении случайно выбранного метода из API, то на его резюме ставится пометка «завышает знания», а уж потом эйчары разбираются враньё это или искреннее заблуждение. В любом случае неточность формулировок — большой минус для разработчика, основной задачей которого является трансляция неформализованных требований в однозначно понимаемые исполнительным устройством команды.

                                                                                                            Где в документации описано «это основные методы, а это не основные», «эти параметры основные, их нужно знать, а эти неосновные, не грех и в документацию заглянуть»? Или вы называете методы основными исключительно по тому, как часто лично вы их используете или видите?

                                                                                                            • –1
                                                                                                              > то на его резюме ставится пометка «завышает знания»
                                                                                                              Если в вашей организации принято так делать, это многое говорит о вашей организации.

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

                                                                                                              Вот мой вопрос: habrahabr.ru/post/273751/#comment_8717205, по делу есть что сказать?
                                                                                                      • 0
                                                                                                        Я не поленился и прошелся еще раз по статье: что, кто то из тех кто минимально сталкивался с jQuery не знает про $() / $()[0]? Кто-то не знает как в jQuery посесить обработчик любого события?

                                                                                                        Полифил fetch() извините, конечно, но это такая вещь которую перед использованием стоит проверить даже если библиотека сто раз проверенная и точно знать ее тонкости, не шлет ли лишних заголовков или еще какой фигни, что именно она возвращает и т.д. Тот кто пользуется fetch() уже выбрал полифил, тот кто не пользуется — сомневаюсь что захочет использовать полифил из этого странного набора DOM-манипуляций, работы сданными и анимациями. В конце концов в том же jQuery $.ajax возвращает промисы.

                                                                                                        CSS-анимации. Зачем тут вообще они нужны? Причем тут анимации?

                                                                                                        Если вы открываете чужой код и видите $('li').forEach(...), какие у вас первые мысли? Лично у меня первые мысли, что это кто-то подключил очередной велосипед

                                                                                                        Если вы манипулируете DOM в проекте напрямую, и на этом проекте больше чем 1 человек, то в какой то момент вам обязательно придет в голову мысль «а не плохо было бы как в jquery»… Но уже надо будет переписать кучу кода, потому что автор этого набора говнокодера не утрудил себя соответствием jQuery API
                                                                                                    • +3
                                                                                                      >люди которые не знают jquery оказываются куда более компетентней людей которые его знают
                                                                                                      Сказки.
                                                                                                      • 0
                                                                                                        Личная статистика собеседований по вакансиям типа «junior web developer»:

                                                                                                        Большинство тех, кто знает jquery лучше меня, не знают ни javascript, ни какой-нибудь другой ЯП, при словах «паттерны», «принципы проектирования» — абсолютно непонимающие лица. По сути верстальщики, для которых jquery — расширение HTML/CSS. Они могут делать многое на фронте, но они не программисты.

                                                                                                        Большинство тех, кто знает javascript, знает какой-нибудь другой ЯП, знает хотя бы про трезвенные архитектуры, MVC, могут объяснить с достаточно детализацией что происходит от момента нажатия enter в адресной строке до вывода страницы в браузере.

                                                                                                        Большинство тех, кто хоть как-то знает только javascript, «знает» jquery на уровне вызова $(selector) и $.ajax(settings), их использовали на практике, но не могут толком объяснить, что эти функции возвращают.
                                                                                                        • –2
                                                                                                          «Большинство» — это не статистика. Это во-первых. Статистика — это нормальные цифры и понятные методы исследования.
                                                                                                          А во-вторых — я понял, что вы такой единственный уникум, который и JS в целом знает, и другие ЯП, и в jQuery ориентируется. Больше таких людей нет.
                                                                                                          • 0
                                                                                                            Более 50% соискателей. Так лучше?
                                                                                                          • +1
                                                                                                            Личная статистика где? Куда вы людей набираете? У вас большая компания или стартап? Или у вас своя студия и вы клепаете сайты-визитки? Если большая компания, что вы там делаете?

                                                                                                            Вы реально не понимаете, что от этого зависит ваша статистика? Если у вас не большая компания или не стартап с большим количеством денег, то к вам такие программисты и идут. А вы затем начинаете выдавать свои данные за какую-то статистику.
                                                                                                            • 0
                                                                                                              Хотя, если у вас верстальщики могут делать многое на фронте, то в принципе и так понятно что вы делаете.
                                                                                                              • 0
                                                                                                                Не у нас верстальщики могут многое делать на фронте, а к нам на вакансию разработчиков, приходят верстальщики, которые с помощью HTML/CSS и jQuery могут многое сделать в области визуализации пользовательских интерфейсов.
                                                                                                                • –1
                                                                                                                  Мне начинает казаться, у вас просто не хватает компетенции чтобы понять о чем я говорю. Верстальщик — это не фронтенд-разработчик. Про верстальщиков тут никто не говорил, вы сами их сюда приплели и теперь используете как аргумент.

                                                                                                                  Вот минимум для фронтендщика, который был полгода назад. Если вас удивляют эти требования, то ваши знания устарели.
                                                                                                              • 0
                                                                                                                Ентерпрайз, финансы. Так понятнее?

                                                                                                                Не за какую-то, а за личную.
                                                                                    • 0
                                                                                      Если бы я прийдя на проект увидел, что тут используется такое, был бы крайне недоволен.

                                                                                      Ни слова больше! Автор, срочно удаляй «подобную поделку» из всех реп!
                                                                                    • –1
                                                                                      Помимо всего вышесказанного одно из преимуществ JQuery, которое сложно победить — JQuery раздается через гугловский CDN и скорее всего уже лежит у пользователя в кеше браузера, а вашу библиотечку еще скачать надо.
                                                                                      • 0
                                                                                        Это не библиотека, а одна функция и её скачивать (подключать через script) не надо.
                                                                                        • +1
                                                                                          Вы не совсем поняли мою мысль. Реализовать кусок функциональности JQuery в 408 символах это конечно красиво, только надо понимать, что это дополнительные 408 символы, которые по сути дублируют существующую функциональность. Даже если проблемы реализации через год-два исчезнут, это не изменит того, что библиотека (функция, whatever) решает проблему, которой нет.
                                                                                        • +1
                                                                                          Вы используете 5% жиквери, но при этом боитесь закачать «лишние» 408 символов кода?
                                                                                          • +2
                                                                                            До появления jQuery люди песни слагали ( https://www.youtube.com/watch?v=vTTzwJsHpU8 ), о проблемах при написании фронтенда, jQuery эту проблему решила, вдобавок сильно приятнее сделав синтаксис и т.п. Вы мне предлагаете взять поделку, которая использует подобный синтаксис, но при этом вместо решения проблем, наоборот добавляет кучу новых… конечно боюсь!
                                                                                          • +3
                                                                                            CDN — спорное преимущество. Для конечного пользователя он может быть недоступен по разным причинам (блокировка, неполадки на сервере) и тогда веб-приложение сломается.
                                                                                            На проде надёжнее всю статику (js/css) загнать в 1 файл (с таймштампом или чем-то подобном в имени), который и будет лежать в кэше, пока не протухнет или не обновится (при обновлении меняется имя -> никто из пользователей не будет тянуть неактуальную версию из кэша). Плюс, есть много готовых вариантов для сборщиков, чтобы организовать такое.