(картинка позаимствована где-то в интернете)
[ Репозиторий ]
Всем привет.
Уже давно прошли времена обязательной поддержки 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.
Комментарии (175)
nazarpc
22.12.2015 23:34+10$ это гораздо больше чем document.querySelectorAll (именно All), например:
$('.xyz').append('<xyz />')
И совершенно сразу пропадает желание вручную писать:
[].forEach.call( document.querySelectorAll('.xyz'), function (node) { node.insertAdjacentHTML('beforeend', '<xyz />'); } );
А ещё там может быть не строка, а DOM элемент, или jQuery объект, тогда нужно будет добавить несколько условий и мы в итоге закончим тем, что напишем реализацию абсолютно аналогичную оной из jQuery. Вопрос: ЗАЧЕМ???
Перестаньте убивать jQuery, это бесперспективно, займитесь лучше проблемами, которые не были решены должным образом.
Инструменты нужно использовать там, где им место.
Finom
22.12.2015 23:42+1И совершенно сразу пропадает желание вручную писать
Для небольшого проекта такой код приемлем. Для большого — юзайте фреймворки, иначе получете макароны.
Если говорить о bala.js, то с Babel или без него (в случае поддержки только современных браузеров, например, при создании приложения под Electron), вы получете такой код:
for(let node of $('.xyz')) { node.insertAdjacentHTML('beforeend', '<xyz />'); }
Delphinum
23.12.2015 00:56напишем реализацию абсолютно аналогичную оной из jQuery
Вы настолько хорошо знакомы с внутренностями jQuery, что делаете такие мастабные выводы? Как вы считаете, насколько похудеет jQuery если лишить ее поддержки «особенностей» ie? А если еще отказаться от «особенностей» мобильных платформ?nazarpc
23.12.2015 02:48+4Если говорить об объеме в символах — то около 10% jQuery 3.0 можно будет вырезать, навскидку.
Я уже давно использую версию 3.0, там древние версии IE по большей части вырезаны, как и старые версии мобильных браузеров.
А по поводу внутренностей — там каждый символ на счету и очень тщательная проверка всех изменений.
К примеру, из последнего: github.com/jquery/jquery/commit/eaa3e9f0cfc68083556cf61195821d90e369f646
Рефакторинг чтобы сохранить дополнительные 21 байт. При этом не страдает читабельность, чего не скажешь про bala.js.
Я к тому, что написать односимвольное сокращение для document.querySelector может любой, но даже самые типичные потребности идут гораздо дальше этого.Delphinum
23.12.2015 03:49-8Писал на ванильном джесе и пришел скорее к backbonejs, нежели к jquery. Что я сделал не так?
xGromMx
23.12.2015 04:25+7А ничего, что он использует jQuery?) backbonejs.org/#View-dollar
Delphinum
23.12.2015 14:49+3Вы не услышали мой комментарий. Я сказал что пришел скорее к backbonejs, нежели к jquery. Это означает, что структура моего решения позволила отказаться от вермишели jquery, но не позволила отказаться от архитектуры MV*.
Если уж вы решили поделиться ссылкой, то поведую вам, что BackboneJS не зависит и не использует jQuery. jQuery для BackboneJS это всего навсего одна из реализации некоторого функционала. Его можно легко заменить на ZeptoJS или на свою ванильную реализацию, BackboneJS от этого не пострадает.
liksu
24.12.2015 00:35+1Просто как вариант:
Array .from(document.querySelectorAll('.xyz')) .forEach(node => node.insertAdjacentHTML('beforeend', '<xyz />') );nazarpc
24.12.2015 01:21+1Я на LiveScript тоже компактнее пишу, специально написал на JS канонический вариант чтобы все поняли.
Но это транспайлеры, суть от этого не меняется, это гораздо менее удобно чем jQuery. Для одноразового использования можно и нужно, но постоянно писать такой код — это слишком много визуального шума, читать такую простыню сложно.
Delphinum
23.12.2015 00:49Предупреждал же, что микро-пакетные решения гораздо удобнее, чем фреймворки. Когда пакет устаревает, его можно выкинуть, заменив на ванильную реализацию, при этом остальные пакеты остаются в строю.
Regis
23.12.2015 03:03+2Вы же в курсе, что x.querySelector(y) это не то же самое, что jQuery запрос с контекстом?
Я про то, что querySelector всегда мэтчит от корня (документа), а не от указанного контектса. И обычно это НЕ то, что нужно.
some_x
23.12.2015 08:48+1Лично я не в курсе. То есть x.querySelector(y) делает поиск от корня и уже потом фильтрует?
Не могли бы рассказать об этом подробнее?
Fr3nzy
23.12.2015 10:36Even though the method is invoked on an element, selectors are still evaluated in the context of the entire document.
Это API использует тот же движок, что и браузер при работе с CSS селекторами. По-сути, этим и обусловлено такое поведение.some_x
23.12.2015 11:15+1Ок, но я не вижу в этом ничего ужасного.
Пусть этот метод не настолько оптимален на сколько мог бы быть, но если профилировщик не показывает что его вызов является узким местом, то почему бы его не использовать.Fr3nzy
23.12.2015 14:22Я ничего не говорил про проблемы. Лишь дал ответ на ваш вопрос.
Изначально формулировка (от другого человека) говорила о том, что реализация в jQuery будет отличаться от
element.querySelector()
dolphin4ik
23.12.2015 12:47+3А мне кажется, что попытки «свержения» «библиотек 'де-факто'» это своеобразный двигатель прогресса. В большинстве больших проектов жиквери уже не нужно — всё делает фреймвёрк, а в малых проектах жиквери и не нужно, можно обойтись «408 символами кода» ( finom ).
Ohar
23.12.2015 14:31-5всё делает фреймвёрк
Да, в основном потому что jQuery встроен почти во все фреймворки.
jMas
23.12.2015 16:05Хм, спорное утверждение.
jMas
24.12.2015 12:24Аргументирую. jQuery не встроен, например в Angular, React+Flux, Polymer. В других более мелких проектах есть возможность подключить пяток необходимых микро-библиотек, которые являются обертками поверх
XMLHttpRequestаналоги$.ajax, сахаром для работы с DOM, Promises. Я считаю утверждение «jQuery встроен почти во все фреймворки» спорным, потому как почти каждый современный популярный фреймверк не тянет jQuery с собой и не зависит от этой библиотеки.Ohar
24.12.2015 13:59jQuery не встроен, например в Angular
В Ангуляр встроен jQlite — тот же jQuery, но без дублируемых ангуляром функций.jMas
24.12.2015 19:55Это не тот же jQuery. Это ограниченный набор функций. Где нет ни методов для работы с XMLHttpRequest, ни промисов. Поэтому часто рядом с ангуляром подключают еще и jQuery.
bromzh
24.12.2015 21:04+1jQuery в angular-проект подключают явно не для ajax'а с промисами, ведь в ангуляре есть свои реализации.
jMas
24.12.2015 21:14Окей, теперь с Ангуляром у меня все стало на места. Согласен, Ангуляр является плохим примером фреймверка «без jQuery».
Ну хорошо, продолжу Ext.Js (кстати довольно старый фреймверк, активно юзается в энтерпрайзе), Sencha Touch, Vue.js, Riot.js (последние два не столь популярны, но новы и известны в узких кругах).bromzh
24.12.2015 21:49+1Да нет, хороший пример. jQuery в ангуляре почти не нужен. ИМХО, его стоит подключать либо когда нужен какой-то jq-плагин, у которого нет достойных аналогов в виде ангуляр-модуля (или на чистом js), либо когда нужна какая-то прям очень сложная работа с DOM, с которой ангуляровские средства не справятся.
С другой стороны, чаще всего в большом проекте какая-то библиотека всё-равно захочет jq себе в зависимости. А ангуляр умеет детектировать наличие jquery и использовать его заместо jqlite.
Synoptic
23.12.2015 12:58-5Я очень надеюсь что когда-нибудь авторов всех подобных поделок закроют в соответствующие лечебные заведения, а пока скрестил пальцы чтобы ни один идиот не додумался использовать этот велосипед где-то сложнее, чем на любительском homegrown-проекте.
Если бы я прийдя на проект увидел, что тут используется такое, был бы крайне недоволен.VolCh
23.12.2015 13:13+2Какое «такое»?
Synoptic
23.12.2015 22:22«Такое» = дополнительный велосипед, в который мне надо залезть, чтобы быть уверенным что я понимаю как он работает. Вместо того, чтобы просто тоже самое на чистом js.
VolCh
24.12.2015 11:29Где для вас грань между «велосипедом» и «промышленным стандартом де-факто» типа jQuery? Только то, понимаете ли ві лично как оно работает? Или вы вообще не используете сторонний код?
Ohar
24.12.2015 12:12-1Не нужно разводить демагогию, вы отлично знаете где эта грань: спросить у новичка, полгода-года работающего в отрасли, слышал/работал он с этой библиотекой/фреймворком или нет.
Synoptic
24.12.2015 22:21Поясняю.
Минус этой вещи в том, что для ее использования требуется запомнить очередной API. Будь он хоть сто раз интуитивным, я сейчас не знаю это API и не хочу ео изучать. Я знаю jQuery/Zepto/подставьте_по_вкусу, которое умеет тоже самое.
Если рассматривать этот код как пару функций, то ну что сказать — молодец автор, написал еще разок пару сто раз написанных функций. Можно скопипастить и использовать.
А можно просто взять известную всем библиотеку или кусок ее кода не меняя ее API и ничего не выдумывая!
Больше чем такие «убийцы jQuery» меня вымораживают разве что кадры, верстающие собственные grid layouts вместо того чтобы взять готовый из bootstrap или другой подходящей библиотеки.VolCh
25.12.2015 13:47Ну вот я не знаю API jQuery, вы не знаете, например, API prototype. Мне без разницы изучать на проекте jQuery или bala. А вам есть разница изучать prototype или bala?
Synoptic
25.12.2015 14:35-1Все фронт-энд разрабочики знают jQuery API, не надо прикидываться дурачком
zxcabs
25.12.2015 16:26-1я бы не был столь голословным, я знаю jq api только на уровне селекторов и некоторых очевидных методов. Не у всех фронэендеров задачи сводятся к jq.
Synoptic
25.12.2015 18:07+1А в этой статье разве не селекторы и не очевидные методы?
Ребята, не стоит рассказывать сказки на IT-ресурсе, если человек не знает jQuery API на уровне описанных в статье вещей или не знает где в два клика взять документацию по этому API, то никакой он не фронт-энд разработчик.
VolCh
25.12.2015 16:55+1Не все. Это факт.
Synoptic
25.12.2015 18:08+1Факт — это ваши слова? Или может есть что-то поубедительнее? А то я тоже так могу: jQuery знают все фронт-энд разработчики все. Это факт.
Synoptic
25.12.2015 18:33+1У меня вот есть кое-что поубедительнее. За последний год я провел ~60 интервью на позицию фронт-энд разработчика. Все, кто не знал jQuery API на уровне селекторов, установки событий, $.ready, $.ajax и прочего из статьи(совершенно дежурные вопросы, самый минимум) были совсем новичками, которых нельзя назвать готовыми к работе девелоперами. Максимум это уровень интернов.
VolCh
25.12.2015 19:40-2Может чуть поменьше провел, но несколько человек не знали jQuery. Нюанс: они пошли на фронтендеров с бэкенда и декстопа и после азов js сразу начали учить Ангуляр.
Synoptic
25.12.2015 19:54И в чем тут аргумент? В первом ангуляре используется jQuery API. В нем все это есть кроме анимаций по-моему.
Даже если и не знали, то это максимум уровень junior developer в таком случае. Это совершенно не показательно в качестве аргументации.
Synoptic
25.12.2015 20:00+2А если уж совсем быть честными, то никакие это не джуниор девелоперы, это бекендщики которые чуть-чуть почитали про фронтенд разработку. Это не делает их фронтенд-разработчиками автоматически. Ими делает практический опыт на реальных задачах, в процессе обретения которого человек по-любому столкнется с jQuery.
VolCh
25.12.2015 20:58-1Откуда такая уверенность, что по-любому столкнется? Сколько процентов проектов, по-вашему, использует jQuery?
Synoptic
25.12.2015 21:12Моя уверенность основана на знаниях нескольких фактов плюс на том, что я вижу своими глазами. Факт первый — рынок фронт-енд разработки, и в мире, и везде, завязан на энтерпрайз. Быть крутым стартапером на последнем тех. стеке, быть понтовым контрибьютером в какой нить babel или что там у rock и делать свое «фи» на публику — это конечно круто, но погоду на рынке делаете не вы, ребята.
В энтерпрайзе 90% проектов тянут за собой легаси. До появления SPA-фреймворков наличие в этом легаси коде jQuery мне кажется вам сложно будет оспорить — он был везде. После появления SPA-фреймворков он был вытеснен тоже не сразу, backbone был очень популярен еще 2-3 года назад, и у него в жестких зависимостях jQuery. Если человек учит первый ангуляр, он обязательно столкнется с упоминанием jQuery в документации.
Сейчас с приходом react и серьезно изменившимся отношением к ручной манипуляции DOM я согласен, jquery может не понадобиться.
Теперь о том, что я вижу своими глазами. Я работаю в организации, в которой я по работе общаюсь с командами, работающими над совершенно разными проектами — от фармакологии и банков до звонилок. Я общаюсь с коллегами из других организаций такого плана. Я нигде не видел, чтобы не было jquery, кроме одного свежего небольшого проекта на react.
Когда-то я 5 лет работал на фрилансе верстальщиком, затем фронт-ентщиком. Думаю мое утверждение, что фриланс это тоже достаточно крупный рынок, хотя и с низкоквалифицированными специалистами в качестве исполнителей вас не удивит. Так вот, jquery там везде.
Вы лучше скажите, где его нет, и мы сравним размеры областей приведенных мной, и ваши примеры.VolCh
28.12.2015 12:51Факт первый — рынок фронт-енд разработки, и в мире, и везде, завязан на энтерпрайз.
Что вы называете завязкой на ентерпрайз?
До появления SPA-фреймворков наличие в этом легаси коде jQuery мне кажется вам сложно будет оспорить — он был везде
Не везде. Он постепенно занял лидирующие позиции, и как раз в легаси jQuery можно и не встретить, а встретить кого-то из его когда-то равных конкурентов типа prototype.
и у него в жестких зависимостях jQuery.
В хорошем фремйворке всё равно, что в зависимостях, он предоставляет более высокий уровень абстракции. Более того, некоторые могут работать с несколькими низкоуровневыми «бэкендами» прозрачно для пользователя.
Другое дело, что на популярность jQuery сильно повлиял тот фактор, что некоторые локальные решения, да и глобальные решения имели зависимость от jQuery, и когда вставал вопрос «что использовать для задачи такой-то jQuery или *?», то ответ был «в принципе без разницы, но jQuery у нас уже есть в зависимостях» (что впоследствии часто приводило к проблемам, когда один компонент использовал одну версию jQuery, а другой — другую).
По моей личной статистике, использование jquery в проекте часто говорит о низкой квалификации разработчиков. Либо об отношении к проекту как к одноразовой задаче, которую будет поддерживать кто-то другой.Synoptic
28.12.2015 13:24-1Что вы называете завязкой на ентерпрайз?
Я называю завязкой на энтерпрайз завязку на энтерпрайз. UI для крупных корпоративных приложений, если не понятно. В UI для корпоративных приложений старше пары лет, а то и свежих, jquery есть практически везде. Причем тут квалификация разработчиков, если мы говорим о фактах, о том что есть?
Не везде. Он постепенно занял лидирующие позиции...
Постепенно занял лидирующие позиции? В какой реальности? Prototype не был ему равным конкурентом никогда, он всегда имел гораздо меньший процент использования, не надо сочинять. Кроме того,
В хорошем фремйворке всё равно, что в зависимостях, он предоставляет более высокий уровень абстракции.
Причем тут хороший или не хороший? Вам говорят — человек, изучавший популярнейшие в мире фреймворки для SPA сталкивался с jQuery и соответствнно знаком с его API на уровне вещей описанных в статье. О чем тут спорить? Причем тут уровень абстракции, что вы несете?
По моей личной статистике, использование jquery в проекте часто говорит о низкой квалификации разработчиков
По вашей личной статистике — вполне может быть и так. Судя по вашим комментариям, если вы верстальщиков считаете фронт-энд разработчиками, невысокого уровня специалист. Вероятно и контора такая, поэтому такие люди к вам и идут. А вы потом экстраполируете свои наблюдения на всех.
Казалось бы, что мешает открыть 50 вакансий от крупных компаний и посмотреть есть там в требованиях на вакансию jQuery или нет. Но нет, вам надо упорно продолжать выставлять себя идиотом.VolCh
28.12.2015 13:58+1Я называю завязкой на энтерпрайз завязку на энтерпрайз. UI для крупных корпоративных приложений, если не понятно.
То есть вы сейчас говорите о приложениях, к которым у обычного смертного и доступа-то нет?
Постепенно занял лидирующие позиции? В какой реальности? Prototype не был ему равным конкурентом никогда, он всегда имел гораздо меньший процент использования, не надо сочинять.
Даже в 2005-м году?
человек, изучавший популярнейшие в мире фреймворки для SPA сталкивался с jQuery и соответствнно знаком с его API на уровне вещей описанных в статье.
Даже если первая часть вашего утверждения правда, то вторая из неё не следует автоматически.
По вашей личной статистике — вполне может быть и так. Судя по вашим комментариям, если вы верстальщиков считаете фронт-энд разработчиками, невысокого уровня специалист.
О, уже переходы на личности, да с искажением фактов. Перечитайте мои комменты: в них я говорил, что к нам на вакансию веб-разработчиков, приходят HTML/CSS верстальщики, поверхностно работавшие с jQuery и потому считающие себя уже разработчиками, а не верстальщиками.Synoptic
28.12.2015 14:08-1>Перечитайте мои комменты: в них я говорил, что к нам на вакансию веб-разработчиков, приходят HTML/CSS верстальщики, поверхностно работавшие с jQuery и потому считающие себя уже разработчиками, а не верстальщиками.
Можно подумать вас об этом кто-то спрашивал.
Повторяю последний раз, уже даже не для вас, вы не поймете. А просто чтобы завершить эту клоунаду.
Мои тезисы:
1. Если вы решаете задачу, которая сто раз решена до вас, используйте хотя бы известный API.
2. API jQuery на уровне, описанном в статье знает любой фронт-энд разработчик.
3. Если человек не сталкивался с задачами на jQuery на уровне описанных в статье методов в статье, не считая бессмысленных здесь анимаций разве что — он не фронт-энд разработчик.
4. Верстальщик, умеющий плагины jQuery — это не фронт-энд разработчик.VolCh
28.12.2015 14:12+1Мои тезисы:
1. Обычно это имеет мало смысла. Только если разработчики «оригинала» не хотят развивать его в желаемом направлении, например не спешат отказываться от груза BC.
2. Ложь.
3. Ложь
4. О чём я вам и толкую который день.
Apathetic
25.12.2015 22:49+1На этот-то вопрос, как раз-таки, ответ есть.
trends.builtwith.com/javascript/jQuery
rock
25.12.2015 19:55-1Я не знаю жуквери API так как не пользовал его уже года 3. Разве что базовую работу с селекторами вспомню. О, печаль-беда, я новичок и мой уровень — максимум уровень интерна :( Ох уж эти UI/UX инженеры, считающие, что жуквери это и есть JS.
Synoptic
25.12.2015 20:00-1Если вы использовали jQuery API, вы его знаете. Чисто для справки, на своих проектах я не использую jQuery, только для создания прототипов на скорую руку. Чем еще померяемся?
rock
25.12.2015 20:05Чем еще померяемся?
Какие странные у вас желания.
Если я что-то не вспомню — значит я этого уже не знаю. Ферштейн?Synoptic
25.12.2015 20:08-1Странная логика для человека, считающего себя программистом.
Если я что-то реально знал, но забыл, то это не значит что я этого не знаю. Это значит, что я знаю, но забыл. Что можно достаточно быстро освежить память, а не учить заново. Ферштейн?
Как можно изучить фреймворк и забыть? Такое бывает только если прочитал в интернете пару статей или книжку и не применял толком на практике. Скажите уж честно тогда — и не знали вы jQeury API. Что там можно забыть не понимаю.rock
25.12.2015 20:15Ага. Я уже не должен счить себя программистом и вру о том, что пользовал жуквери. Так и запишем.
Не много ли вы на себя берёте с такими-то утверждениями? :)
> Как можно изучить фреймворк и забыть?
Если учитывать количество фреймворков, которые мучал — легко и просто. А ещё жуквери не фрейморк.Synoptic
25.12.2015 20:22-2А вы не много на себя берете, начиная разговор с пассажа про UI/UX, считающих, что жуквери это и есть JS?
Я привел аргументацию — у меня есть своя личная статистика опрошенных кандидатов в фронтенд-разработчики на различные позиции. Ни один из тех, кто не имел представления о jQuery API не тянул даже на junior. Не потому, что не знал jQuery API, специально отмечу. Никто к кандидатам по поводу знания jQuery или любого другого фреймворка, если он отсутствует к требованию на позицию, никогда не придирается.
Так вот, может быть у вас есть какая-нибудь своя статистика? Или только гордая позиция «я не такой, значит твои аргументы говно»? Отмазки «знал, но забыл» я слышал десятки раз, это всегда означает одно — нихрена ты, дорогой, и не знал.
Synoptic
25.12.2015 20:26-2Я занимаюсь версткой и фронт-енд разработкой тоже не мало лет и тоже пощупал немало библиотек. Но я, блин, не представляю как можно забыть jQuery API.
Так что да, давайте вы тихо сольетесь и сведете тред в срач «jquery фреймворк или библиотека». Меня это устроит.rock
25.12.2015 20:35+1А вы не много на себя берете, начиная разговор с пассажа про UI/UX, считающих, что жуквери это и есть JS?
Не много. Логичный вывод из ваших предыдущих комментариев.
Я привел аргументацию
Потрясающая аргументация — я привёл качестве контраргумента себя, знаю нескольких других разработчиков, далеко не юниоров, что если и вспомнят это — то с трудом — ибо оно не нужно.
нихрена ты, дорогой, и не знал.
А вот за это можо (и нужно) по лицу при встрече. Запомним.
Я занимаюсь версткой
Оно и видно.
Итак, значит я не тяну даже на юниора? :(
zxcabs
26.12.2015 01:25+2Знали бы вы сколько мы отсеяли ведущих JS разработчиков, с 5+ годами работы, которые валятся на элементарных тестах на знание js. Мы скорее наймем человека который не знает jquery, потому что он реально что то знает и что то делал, а не гуглил последние 5ть лет нужный плагин в интернете.
Кидайте поменьше говна на вентилятор, есть проекты для которых jquery и нафиг не нужен, а с развитием новых стандартов эта тенденция только расширяется.Synoptic
26.12.2015 02:00-1Вы там с rock бухаете что ли на пару? Где я вообще говорил что jQuery это хорошо?
Повторяю для особо тупых — по лично моим данным за год из примерно шестидесяти опрошенных девелоперов ни один человек, не знавший jQuery не оказался профессиональным фронт-энд разработчиком. Так понятно?
Ни один человек их опрошенных, не знавший jQuery, не оказался профессиональным веб-разработчиком, может быть так понятно? А?zxcabs
26.12.2015 02:12Не, не понятно, капсом писать надо.
Мы вам говорим, что лично ваша статистика это не показатель дел в отрасли, у нас в компании jquery почти не используется и по лично моей статистике люди которые не знают jquery оказываются куда более компетентней людей которые его знают. Но Вы конечно и дальше можете тут биться в истерике и доказывать правоту вашей статистики.Synoptic
26.12.2015 02:15-1Не пользуются и никогда про jQuery не слышали? Что, реально? И какой опыт клиентской разработки у сотрудников вашей компании? И что вы такое делаете, может быть это нишевая вещь? Я ведь привел не просто статистику, а указал ее источник — энтерпрайз разработка.
Естественно если у вас филиал FirefoxOS, вы не используете jquery. Но даже разработчики оттуда знают о нем. Приходилось общатьсяzxcabs
26.12.2015 02:48Речь не идет о полном не знании jq, естественно о его существовании слышали все, но насколько глубоко знают люди апи jq? А самое главное, является ли это показателем уровня разработчика. Для меня большинство юзкейсов jquery это: получить элемент по селектору, снять/навесить обработчик, поманипулировать с dom и поставить снять класс. Но в jquery куда больше методов, только мне до них дела нет, и я их не знаю или не использую. А все то что чаще всего используется уже реализовано на уровне стандарта, так вот и вопрос, так ли он необходим этот jquery?
Основной проект у нас 100M+ пользователей, да на основном проекте используется jq, но он там встроен в вреймворк и больше является рудиментом, 99% кода который пишут фронтенд разработчики никак не связан с jq.
Так же есть ряд других проектов, в которых ситуация с jq такая же, а в некоторых он не используется вовсе.
Что касается моих наблюдений об интервьюируемых мной людях, то очень часто к нам приходят люди которые имеют большой опыт работы фронтенд разработки на jq и странным образом они не могут объяснить такие простые вещи, как: чем отличаются GET от POST запросы, не знают как работают куки, не могут объяснить как распространяются события в браузере и я уже молчу про такие вещи как, замыкания, прототипы, ссылочные типы. Так кто же все эти люди которые много лет программировали фронтенд на jq?Synoptic
26.12.2015 03:04А почему вы говорите о полном знании API? Я не говорил о полном знании API. Я в самом начале сказал, что то что написал автор поста плохо, потому что уже есть в jQuery с его известным каждому и хорошо документированным API. А в его код надо как минимум лезть и смотреть что он делает. Также я попытался объяснить что этот примитивный API известен абсолютно любому человеку, считающему себя фронтенд-разработчиком.
Насчет наблюдений, опять же, почему вы считаете, что к нам не приходят точно такие же люди с 5+ лет опыта в резюме и знанием jquery без понимания js, где я такое говорил? Раз вы с Питера, то скорее всего одни и те же люди и ходят. Таких отсеивают в любой адекватной конторе. Только вот почему вы сами описали ситуацию, сами на нее мне пожаловались, а теперь вопросы по ней задаете мне, как будто я тут с чем то был не согласен?
Что вы мне доказываете-то, я не могу понять?VolCh
27.12.2015 09:03Когда человек горит «я знаю API jQuery», то подразумевается, что он знает его весь, что на вопрос о любом методе он ответит хотя бы «этот метод делает то-то, но в детали я не вникал», а не «я знаю что $ позволяет получить элмент по селектору» — это даже я знаю, хотя jQuery не знаю.
Synoptic
27.12.2015 18:08+1>то подразумевается, что он знает его весь
Никем это не подразумевается. Ни одной организации не надо, чтобы исполнитель знал назначение каждого метода, для этого есть документация.
Я сто раз объяснил что тут подразумевается. Это знание основных методов, которые покрывают все, что написано в этой статье. Если вам хочется свести разговор в сторону, где можно будет повилять хвостом, у вас этого не получится.
Я выше не поленился и ответил на ваш вопрос об областях применения. Ответ-то ждать?VolCh
28.12.2015 10:33Другими словами ни одной организации не надо, чтобы исполнитель знал API. А если соискатель утверждает, что знает, но не может ответить о назначении случайно выбранного метода из API, то на его резюме ставится пометка «завышает знания», а уж потом эйчары разбираются враньё это или искреннее заблуждение. В любом случае неточность формулировок — большой минус для разработчика, основной задачей которого является трансляция неформализованных требований в однозначно понимаемые исполнительным устройством команды.
Где в документации описано «это основные методы, а это не основные», «эти параметры основные, их нужно знать, а эти неосновные, не грех и в документацию заглянуть»? Или вы называете методы основными исключительно по тому, как часто лично вы их используете или видите?
Synoptic
28.12.2015 11:54-1> то на его резюме ставится пометка «завышает знания»
Если в вашей организации принято так делать, это многое говорит о вашей организации.
Не надо так уныло сливаться, цепляясь за термины. Ведь и я, и вы, и те немногие кто нас читают все прекрасно поняли.
Вот мой вопрос: habrahabr.ru/post/273751/#comment_8717205, по делу есть что сказать?
Synoptic
26.12.2015 03:21Я не поленился и прошелся еще раз по статье: что, кто то из тех кто минимально сталкивался с jQuery не знает про $() / $()[0]? Кто-то не знает как в jQuery посесить обработчик любого события?
Полифил fetch() извините, конечно, но это такая вещь которую перед использованием стоит проверить даже если библиотека сто раз проверенная и точно знать ее тонкости, не шлет ли лишних заголовков или еще какой фигни, что именно она возвращает и т.д. Тот кто пользуется fetch() уже выбрал полифил, тот кто не пользуется — сомневаюсь что захочет использовать полифил из этого странного набора DOM-манипуляций, работы сданными и анимациями. В конце концов в том же jQuery $.ajax возвращает промисы.
CSS-анимации. Зачем тут вообще они нужны? Причем тут анимации?
Если вы открываете чужой код и видите $('li').forEach(...), какие у вас первые мысли? Лично у меня первые мысли, что это кто-то подключил очередной велосипед
Если вы манипулируете DOM в проекте напрямую, и на этом проекте больше чем 1 человек, то в какой то момент вам обязательно придет в голову мысль «а не плохо было бы как в jquery»… Но уже надо будет переписать кучу кода, потому что автор этого набора говнокодера не утрудил себя соответствием jQuery API
Apathetic
26.12.2015 11:41+3>люди которые не знают jquery оказываются куда более компетентней людей которые его знают
Сказки.VolCh
27.12.2015 09:32Личная статистика собеседований по вакансиям типа «junior web developer»:
Большинство тех, кто знает jquery лучше меня, не знают ни javascript, ни какой-нибудь другой ЯП, при словах «паттерны», «принципы проектирования» — абсолютно непонимающие лица. По сути верстальщики, для которых jquery — расширение HTML/CSS. Они могут делать многое на фронте, но они не программисты.
Большинство тех, кто знает javascript, знает какой-нибудь другой ЯП, знает хотя бы про трезвенные архитектуры, MVC, могут объяснить с достаточно детализацией что происходит от момента нажатия enter в адресной строке до вывода страницы в браузере.
Большинство тех, кто хоть как-то знает только javascript, «знает» jquery на уровне вызова $(selector) и $.ajax(settings), их использовали на практике, но не могут толком объяснить, что эти функции возвращают.Apathetic
27.12.2015 14:33-2«Большинство» — это не статистика. Это во-первых. Статистика — это нормальные цифры и понятные методы исследования.
А во-вторых — я понял, что вы такой единственный уникум, который и JS в целом знает, и другие ЯП, и в jQuery ориентируется. Больше таких людей нет.
Synoptic
27.12.2015 18:13+1Личная статистика где? Куда вы людей набираете? У вас большая компания или стартап? Или у вас своя студия и вы клепаете сайты-визитки? Если большая компания, что вы там делаете?
Вы реально не понимаете, что от этого зависит ваша статистика? Если у вас не большая компания или не стартап с большим количеством денег, то к вам такие программисты и идут. А вы затем начинаете выдавать свои данные за какую-то статистику.Synoptic
27.12.2015 18:21Хотя, если у вас верстальщики могут делать многое на фронте, то в принципе и так понятно что вы делаете.
VolCh
28.12.2015 10:39Не у нас верстальщики могут многое делать на фронте, а к нам на вакансию разработчиков, приходят верстальщики, которые с помощью HTML/CSS и jQuery могут многое сделать в области визуализации пользовательских интерфейсов.
Synoptic
28.12.2015 11:51-1Мне начинает казаться, у вас просто не хватает компетенции чтобы понять о чем я говорю. Верстальщик — это не фронтенд-разработчик. Про верстальщиков тут никто не говорил, вы сами их сюда приплели и теперь используете как аргумент.
Вот минимум для фронтендщика, который был полгода назад. Если вас удивляют эти требования, то ваши знания устарели.
Delphinum
23.12.2015 14:54Если бы я прийдя на проект увидел, что тут используется такое, был бы крайне недоволен.
Ни слова больше! Автор, срочно удаляй «подобную поделку» из всех реп!
AleksDesker
23.12.2015 14:19-1Помимо всего вышесказанного одно из преимуществ JQuery, которое сложно победить — JQuery раздается через гугловский CDN и скорее всего уже лежит у пользователя в кеше браузера, а вашу библиотечку еще скачать надо.
Finom
23.12.2015 14:29Это не библиотека, а одна функция и её скачивать (подключать через script) не надо.
AleksDesker
23.12.2015 14:37+1Вы не совсем поняли мою мысль. Реализовать кусок функциональности JQuery в 408 символах это конечно красиво, только надо понимать, что это дополнительные 408 символы, которые по сути дублируют существующую функциональность. Даже если проблемы реализации через год-два исчезнут, это не изменит того, что библиотека (функция, whatever) решает проблему, которой нет.
dolphin4ik
23.12.2015 14:50+1Вы используете 5% жиквери, но при этом боитесь закачать «лишние» 408 символов кода?
AleksDesker
23.12.2015 15:11+2До появления jQuery люди песни слагали ( https://www.youtube.com/watch?v=vTTzwJsHpU8 ), о проблемах при написании фронтенда, jQuery эту проблему решила, вдобавок сильно приятнее сделав синтаксис и т.п. Вы мне предлагаете взять поделку, которая использует подобный синтаксис, но при этом вместо решения проблем, наоборот добавляет кучу новых… конечно боюсь!
bromzh
23.12.2015 16:49+3CDN — спорное преимущество. Для конечного пользователя он может быть недоступен по разным причинам (блокировка, неполадки на сервере) и тогда веб-приложение сломается.
На проде надёжнее всю статику (js/css) загнать в 1 файл (с таймштампом или чем-то подобном в имени), который и будет лежать в кэше, пока не протухнет или не обновится (при обновлении меняется имя -> никто из пользователей не будет тянуть неактуальную версию из кэша). Плюс, есть много готовых вариантов для сборщиков, чтобы организовать такое.Apathetic
24.12.2015 01:18>он может быть недоступен
Я слышал, что для тех разработчиков, что не предусматривают загрузку локальной версии, в аду предусмотрен отдельный котёл.
IonDen
23.12.2015 14:26+2Конкуренция это хорошо, именно она двигает jQuery вперед)
Finom
23.12.2015 18:00+1jQuery развивается сам по себе, никакой конкуренции нет. Предполагаю, что она будет в мейнстриме не меньше пяти лет.
IonDen
23.12.2015 19:05+1jQuery конкурирует с нативным JS, будущим ES2015+ и всеми теми либами-убийцами (вроде той, про которую пост). Так что конкуренции выше крыши. Можно еще вспомнить прошлые годы, когда jQuery вытеснил Prototype.
Finom
25.12.2015 10:59Я имею в виду, сколько бы ни было конкурентов в виде фреймворков, крутых и современных замен, jQuery всегда занимает свою нишу, потому что:
а) Она простая. Любой новичок, который знает CSS может с ней разобраться.
б) Она популярна.
в) Она предсказуема. Взять хотя бы делегированные события, которые невероятно сложно заставить работать так, как обычные события (например, заставить работать stopPtopagation так, как он работает с неделегированными событиями).
А всё остальное (в том числе и bala.js) — для тех, кого достало и для тех, кто хочет писать самый быстрый и самый контроллируемый код, т. е. для более-менее опытных разработчиков. Новички и консерваторы («бородатые» новички) будут на рынке веб разработки всегда.
shtange
23.12.2015 18:49+3Странно видеть так много негативных комментариев о проекте, который далеко не самый бессмысленный и бесполезный. Некоторые комментарии выходят за рамки критики и переходят в разряд откровенных оскорблений (например).
Мне не понятно, как можно «поносить» человека, который пытается что-то делать. Степень успешности/актуальности того, что он делает это вопрос н-ный. Проще всего не делая ничего быть великим экспертом во всем.
Понятно, что часть критических/жестких комментариев автор спровоцировал сам. Спровоцировал, излишне «желтым» заголовком статьи и тем, что навесил на свой проект ярлык «убийца jQuery».
Как бы там ни было — это не повод опускаться до откровенных оскорблений.Finom
23.12.2015 18:53+2Спасибо за добрый комментарий. Об «убийце jQuery» это была шутка, прямо в начале поста есть приписка.
IonDen
23.12.2015 19:09+1Имхо, многие оскорбились тем, что им предложили либу, которая из коробки не умеет почти ничего и требует дополнительных полифилов.
Оптимальная стратегия тут действовать наоборот:
1. Изначально предложить либу, которая будет все уметь сразу
2. Как опцию предложить исключить из сборки те полифилы, которые не интересуют пользователей.shtange
23.12.2015 19:36Насчет либы, которая «может все» — мне кажется, что автор преследовал несколько иные цели…
Сужу по себе. Я к примеру, при разработке проектов в режиме «just for fun» предпочитаю использовать «чистый» JavaScript. Но при этом для удобства, отдельным файлом подключаю дополнительный функционал (пример), где дописываю то что упростит процесс разработки (включая некоторые методы jQuery).
Полагаю, что подобное js-расширение у автора переросло со временем в либу, которую он описал в статье. Просто нужно было явно в статье ограничить зону использования этой библиотеки.
Ohar
24.12.2015 12:18-3Мне не понятно, как можно «поносить» человека, который пытается что-то делать.
С моей точки зрения автор не «пытается что-то делать», а замусоривает информационное пространство очередной невероятной библиотекой, единственным плюсом которой является фатальный недостаток других библиотек. Это не «что-то делать», а явный вред.
Prologos
23.12.2015 20:50+1А мне нравится! И вообще, говорят так «Если Вас не критикуют, значит Вы не добились успеха». И еще мне понравился парсинг через Вашу библиотеку. Но jQuery конечно привычнее будет.
Finom
24.12.2015 15:13Кстати, в защиту jQuery, за последние полгода я заюзал одну функцию из библиотеки — .parseHTML. Ни один парсер, в том числе, нативный (document.implementation.createDocument) не смог так точно распарсить HTML документ, как это сделал jQuery.
Честно говоря, я и предположить не мог, что мой пост вызовет столько срача с пожеланиями мне отправиться в больницу, обвинениями меня во вредительстве, вопросами «откуда вы такие беретесь». Любой инструмент нужно использовать тогда, когда в нём есть необходимость. Для 99% проектов нативный DOM выполняет свою задачу лучше, чем сторонняя библиотека. Это та мысль, которую мне хотелось донести.
Liumee
24.12.2015 21:27+2Доживём ли мы когда-нибудь до того светлого времени, когда все будут писать на легком и удобном ES6, использовать промисы, fetch, все остальные вкусные штучки, которые постепенно приходят в веб-разработку?
Или так и дальше люди будут цепляться за бородатые версии IE, за jQuery, за Flash?zxcabs
25.12.2015 01:58+3Что вам сейчас мешает это делать? Используйте babel, подключайте только те пресеты которые вам необходимы. js сейчас активно развивается, ждать нативных реализация смысла нет, в случае с babel останется только выключать не нужные пресеты и подключать нужные по мере развития языка и браузеров, а не ждать когда там браузеры дорастут до стандарта. Что то мне подсказывает что они будут отставать года так на два.
Ohar
Вы называете кроссбраузерными методы, работающие в Android-браузере и IE только через префиксы? Серьёзно?
То есть обязательно.
Это вы про браузер с 6 режимами эмуляции, который не пишет в юзер-агенте свою версию?
Очень мило. Осталось рассказать об этом прочим пользователям
Итого
Вы предлагаете вместо старой проверенной и надёжной jQuery, которая умеет почти всё, что вообще может придти в голову, использовать библиотеку с 4 методами и 3 (три) полифила для неё.
Я ничего не упустил?
Finom
Злой у вас комментарий какой-то.
notxcain
Добро пожаловать на Хабр
Ohar
Ну уж как есть.
taliban
Давайте правде в глаза смотреть, ваша библиотека + все полифилы:
1. легче чем jquery?
2. удобней чем jquery?
3. функциональней чем jquery?
Представьте себе что вам советуют вместо одного инструмента использовать 6? Неужели это удобней? Вы забыли описать самое главное — какие преимущества?
Finom
Это холиварный вопрос. Для меня — да.
Да.
Да. В качестве параллели могу пивести PostCSS. В в нем нет ничего, нужно юзать плагины а свой вкус. В SASS есть всё. Но всё больше людей используют PostCSS (в том числе и я). Да и полифилы вряд ли можно назвать инструментами. Скорее, это — костыли для старых браузеров.
Какие преимущества нативного DOM? Окей.
1. Максимальная скорость работы кода.
2. Полный контроль над работой DOM.
3. Отсутствие зависимостей.
4. Меньший размер результирующего файла.
5. Полифилы можно выпилить со временем, библиотеку — нет.
Delphinum
Совсем не обязательно. Поддерживаем на некоторых наших проектах только IE11+ и в ус не дуем.
dom1n1k
Такие проекты есть, но они скорее исключение. Обычно это что-то некоммерческое или рассчитанное на относительно узкую аудиторию. Для типичного коммерческого сайта это неприемлемо почти всегда. И в первую очередь — андроиды 4.x.
Delphinum
Крупные, коммерческие сайты предпочитают обзовестись специализированным ПО под андройды и иосы.
dom1n1k
Во-первых, я не говорил «крупные» — и мелкие коммерческие тоже. Они не могут себе позволить разбрасываться пользователями.
Во-вторых, я знаю немало людей, которые используют vk, fb, lj и далее по списку — через браузер.
Delphinum
А я знаю не мало людей, которые используют через браузер и «плюются», потому что не удобно.
dom1n1k
Есть и такие. Но что это меняет в контексте данного разговора? Ничего.
Нативное приложение это, несомненно, хорошо и полезно — но:
а) оно далеко не всегда есть
б) даже если оно есть, это недостаточная причина, чтобы полностью забить на сайт
Delphinum
Далего не всегда есть — это аргумент, чтобы пилить мобильную версию сайта, которой менее удобно пользоваться, чем ПО?
Что значит «полностью забить на сайт»? Я не предлагал написать ПО и вернуть сайт в 2000чные, или по вашему отказ от jQuery сопостовим с «забиванием на сайт»? Как то сильно вы любите эту либу )
dom1n1k
Хватит демагогии.
Я имел в виду, что это не причина, чтобы отказываться от поддержки нетоповых, но всё-таки довольно распространенных браузеров (IE10 и старые Андроиды).
А уж как эта поддержка будет сделана, на jQuery или чем-то ещё — вопрос второй.
А поддерживать сейчас только «IE11+ и в ус не дуть» — это всё-таки удел меньшинства сайтов, как бы кому-то не хотелось доказать обратное.
some_x
IE10 распространённый браузер? Я давно не видел статистики по нему меньше процента
Borz
1,5%: gs.statcounter.com/#desktop+tablet-browser_version_partially_combined-ww-monthly-201509-201511-bar
и, внезапно, там и IE8 целых 2% имеет
some_x
Я не буду спорить насчёт правдивости этой статистики, так как у меня нет никаких данных на этот счёт.
Просто отмечу что:
1) Есть другая статистика, который тоже на первых строчках в гугле по запросу «browser statistic»: http://www.w3schools.com/browsers/browsers_explorer.asp
2) Мы в своём продукте (SPA) поддерживаем IE11+ и жалоб пока нет.
helarqjsc
Стоит отметить, что статистика w3schools.com основана лишь на посетителях этого сайта, которые по большей части являются веб-разработчиками. Статистика statcounter.com идет с тысяч сайтов где установлен их виджет для аналитики, поэтому, скорее всего, более точно отображает «среднего пользователя».
dom1n1k
Сейчас посмотрел статистику одного своего сайта (совершенно обычный небольшой сайт по продаже автокомплектующих) — десятка имеет 4%.
А суммарно IE c 8 по 10 — около 7%.
Вполне ощутимо.
Конечно, если судить по «модно-молодежным» сайтам типа соцсетей и хабра, то там скорее всего будет сильно иначе. Но надо хоть иногда выглядывать в реальный мир обычных людей.
xobotyi
Пример статистики с боевого сайта, проекта посвященного ММО игре:
Так что не надо пожалуйста про нераспространенной IE;)
Blumfontein
Против MSIE 11 вроде как никто не возражал. Без 11 версии на ИЕ приходится уже незначительные 1.5%.
Для полноты картины хотелось бы увидеть еще статистику доходов по браузерам. А то окажется, что эти 1.5% генерят 0.000001% прибыли, тогда вообще о чем речь.
VolCh
Причина отказа от поддержки каких-то браузеров всегда одна (на коммерческих проектах) — решение менеджмента о её целесообразности. Грубо, если целевых пользователей IE 8-10 5%, а их поддержка удорожит разработку на 6%, то «IE11+ и в ус не дуть». Иди другой вариант: если замедление работы сайта из-за поддержки IE8-10 отпугнёт 6% пользователей, то тоже «IE11+ и в ус не дуть». То есть два фактора основных: сколько будет стоить поддержка и как она повлияет на нормальных пользователей.
dom1n1k
Это всем известно. Но на практике отказываться от ie9-10 обычно особого смысла нет.
Во-первых, они как правило не влекут какого-то чудовищного усложнения поддержки (это же не ie6 прости хоспади). Да, код будет менее чистым и красивым, но каких-то особых трудностей не будет. Хотя конечно бывает что влекут, в специфичных случаях.
Во-вторых, репутационные потери. Заходит человек на сайт и видит, что он поломан. Он будет винить себя и свой браузер? Да ни в жизнь, он решит что сайт плохой и компания нищебродская.
С андроидами так же.
VolCh
Подобные вопросы вечны. Помнится стоял вопрос «отказываемся от поддержки ie <6 или нет». С тех пор у меня аргументы не изменились — это бизнес-решение, по которому мы, технари, можем лишь дать оценку затрат на поддержку устаревших клиентов в двух случаях (с деградацией и нет), плюс оценку затрат на «эмуляцию» современных и будущих пользовательских фич, внедрение которых будет сильно затруднено из необходимости совместимости. Ну и текущую статистику, если нет специально обученных людей. А там бизнес-решает.
dom1n1k
Не совсем.
Я убежден, что по умолчанию вопрос «надо ли поддерживать браузер X?» всегда имеет ответ «да».
И только конкретные весомые причины могут сменить его на «нет».
А то выше были рассуждения типа +6% издержек уже могут перекрыть -5% посетителей — так вот это недостаточно. Это примерно как не пускать в самолет людей ростом выше 195 и тяжелее 120 — ну а чо? Их же всего пара процентов, примем «оптимальное» бизнес решение.
Достаточные причины:
— издержки растут очень сильно (несколько десятков процентов и более)
— доля браузера пренебрежимо мала (пара процентов это мала, но не пренебрежимо)
— аудитория проекта очень четко очерчена (например сисадмины)
VolCh
с выходом каждой новой версии каждого популярного браузера издержки растут. Оценочно прогрессия геометрическая.
это бизнесу решать, какая пренебрежимо мала, а какая нет.
Ohar
dom1n1k
Недостаточно для человеческого отношения к клиенту/посетителю (см. выше пример про самолет).
Ohar
Ну вы уж определитесь — или вы про человеческое отношение к пользователю (и тут я с вами полностью согласен) или вы про бизнес, где любые решения на проекте имеют свою стоимость в деньгах (к сожалению).
dom1n1k
Все в комплексе, не надо разделять.
В магазине есть удобные клиенты (пришел и, ничего не спрашивая, оставил 100500 денег) и неудобные (30 минут ездил по ушам, хотя по нему изначально понятно, что он не собирался покупать). Логично же второго просто выгнать? Но так же не делается (почему-то).
VolCh
И, конечно, у вас есть подтверждения этому?
Finom
Я проигнорирую фразу «Откуда вы такие берётесь?» и постараюсь ответить.
Да, действительно. Вот вам решение:
Зависит от задачи. Если нужно поддерживать старые ослы, то будьте добры подключить полифилы. Это не сложнее чем подключение библиотеки.
Вы описываете проблемы, не предлагая никакого решения. А решение такое: подключать полифилы безусловно и не пользоваться polyfill.io, если страницу посещает много таких пользователей. Если вы пишете проект с долгосрочной поддержкой, полифилы в будущем можно удалить, а от библиотеки избавиться не получится, не переписывая код.
Я предлагаю функцию с нулём методов, которую можно использовать с полифилами, если того требует ваша задача. Если не нравится, то можно юзать querySelector[All]. Цель поста — не навязать кому-то мою разработку, а призвать пользователей юзать DOM API вместо библиотек.
DOM API тоже умеет воти всё, что вообще может прийти в голову и даже больше. Буду капитаном, но его используют разработчики библиотек, в том числе, разработчики jQuery.
Ohar
Если мы говорим про веб-разработку, то поддерживать надо всё, что поддерживается в пределах бюджета. И использование jQuery улучшает этот процесс.
Согласен с вами. В теории (идеальном мире). На практике такого почти никогда не происходит — всё равно приходится переписывать.
Вы предлагает код, который почти ничего не делает и предлагаете его расширять нужными полифилами. И в чём разница с использованием jQuery с кастомными плагинами?
DOM API — чудесно, но неюзабельно в реальных проектах без полифилов. А с полифилами выгода от переключения на него весьма сомнительна.
Иначе говоря, «это уже было в Симпсонах» — он уже используется в jQuery и преимущество от его использования уже есть и ваша библиотека не нужна.
VolCh
А если так переформулировать «Иначе говоря, «это уже было в Симпсонах» — он уже используется в вашей библиотекеке и преимущество от его использования уже есть и jQuery не нужна»
Есть две библиотеки, делающие плюс-минус одинаковые вещи, плюс одна из них делает ещё кучу вещей (естественно ценной оверхидов по памяти, трафику, процессору). Зачем мне эта куча, если есть такая, которая делает ровно то, что нужно? Какие у jQuery преимущества перед bala.js в области применения последней?
Ohar
Но на моей практике все эти замечательные «мне тут только пару элементов в доме выбрать» постепенно приходят к «ну вот тут ещё нужно выбиралку дат сделать», «вон там неплохо бы сделать вкладки» и «вот тут нужен ползунок с двумя рукоятками». И в этот момент все предыдущие маленькие решения выкидываются и ставится jQuery, потому что он это всё делает хорошо.
VolCh
Или не выкидываются, а продолжают работать, если разработчик предпочитает Unix-way :)
gaelpa
И имеет под рукой хорошую библиотеку Unix-way модулей или резиновые сроки/бюджет.
Finom
Это, кстати, единственный юз-кейс, когда мне приходилось подключать jQuery. Очень много инструментов требуют зависимости от jQuery либо из-за лени или отсутствия знаний разработчика, либо из-за того, что инструмент достаточно древний. Сейчас не знаю, как с этим дела, надеюсь, лучше.
Ohar
VolCh
Нередко такое «удешевление» идёт без ведома ответственных за стоимость людей.