Это, кстати, единственный юз-кейс, когда мне приходилось подключать jQuery. Очень много инструментов требуют зависимости от jQuery либо из-за лени или отсутствия знаний разработчика, либо из-за того, что инструмент достаточно древний. Сейчас не знаю, как с этим дела, надеюсь, лучше.
Представьте себе что вам советуют вместо одного инструмента использовать 6? Неужели это удобней?
Да. В качестве параллели могу пивести PostCSS. В в нем нет ничего, нужно юзать плагины а свой вкус. В SASS есть всё. Но всё больше людей используют PostCSS (в том числе и я). Да и полифилы вряд ли можно назвать инструментами. Скорее, это — костыли для старых браузеров.
Вы забыли описать самое главное — какие преимущества?
Какие преимущества нативного DOM? Окей.
1. Максимальная скорость работы кода.
2. Полный контроль над работой DOM.
3. Отсутствие зависимостей.
4. Меньший размер результирующего файла.
5. Полифилы можно выпилить со временем, библиотеку — нет.
Зависит от задачи. Если нужно поддерживать старые ослы, то будьте добры подключить полифилы. Это не сложнее чем подключение библиотеки.
Это вы про браузер с 6 режимами эмуляции, который не пишет в юзер-агенте свою версию?
Вы описываете проблемы, не предлагая никакого решения. А решение такое: подключать полифилы безусловно и не пользоваться polyfill.io, если страницу посещает много таких пользователей. Если вы пишете проект с долгосрочной поддержкой, полифилы в будущем можно удалить, а от библиотеки избавиться не получится, не переписывая код.
Вы предлагаете вместо старой проверенной и надёжной jQuery, которая умеет почти всё, что вообще может придти в голову, использовать библиотеку с 4 методами и 3 (три) полифила для неё.
Я предлагаю функцию с нулём методов, которую можно использовать с полифилами, если того требует ваша задача. Если не нравится, то можно юзать querySelector[All]. Цель поста — не навязать кому-то мою разработку, а призвать пользователей юзать DOM API вместо библиотек.
DOM API тоже умеет воти всё, что вообще может прийти в голову и даже больше. Буду капитаном, но его используют разработчики библиотек, в том числе, разработчики jQuery.
Создание сервера сборки, к сожалению, штука очень трудозатратная. Если еще интересуетесь фреймворком, я могу предложить вот эту штуку. Вся функциональность, отвеающая за классы там отсутствует (хотя, много лишнего может быть для вас).
О ней я и говорил в посте, когда писал о двух переменных ($, $$). Если брать примеры с главной страницы, то всё это можно сделать средствами, которые я описал (анимация, fetch).
И совершенно сразу пропадает желание вручную писать
Для небольшого проекта такой код приемлем. Для большого — юзайте фреймворки, иначе получете макароны.
Если говорить о bala.js, то с Babel или без него (в случае поддержки только современных браузеров, например, при создании приложения под Electron), вы получете такой код:
for(let node of $('.xyz')) {
node.insertAdjacentHTML('beforeend', '<xyz />');
}
Мне, как разработчику своего велосипеда фреймворка такое поведение тоже не ясно. Любой фреймворк, на мой взгляд, должен ставить цель расширить круг полезных инструментов, а не монополизировать рынок.
Я немного сомневаюсь в этом тесте. Рендеринг (или серверный пререндеринг) большого количества элементов вызывает тормоза страницы, которые решаются костылями, типа этого. Может, сделаете многократную перерисовку меньшего числа элементов?
Просто мысли в слух: в идеале хотелось бы получить альтернативу jsperf, который объективно замеряет скорость операций. В jsperf я разочеровался после этого теста. Консольный тест с jsperf расходится в 450 раз!
Это холиварный вопрос. Для меня — да.
Да.
Да. В качестве параллели могу пивести PostCSS. В в нем нет ничего, нужно юзать плагины а свой вкус. В SASS есть всё. Но всё больше людей используют PostCSS (в том числе и я). Да и полифилы вряд ли можно назвать инструментами. Скорее, это — костыли для старых браузеров.
Какие преимущества нативного DOM? Окей.
1. Максимальная скорость работы кода.
2. Полный контроль над работой DOM.
3. Отсутствие зависимостей.
4. Меньший размер результирующего файла.
5. Полифилы можно выпилить со временем, библиотеку — нет.
Да, действительно. Вот вам решение:
Зависит от задачи. Если нужно поддерживать старые ослы, то будьте добры подключить полифилы. Это не сложнее чем подключение библиотеки.
Вы описываете проблемы, не предлагая никакого решения. А решение такое: подключать полифилы безусловно и не пользоваться polyfill.io, если страницу посещает много таких пользователей. Если вы пишете проект с долгосрочной поддержкой, полифилы в будущем можно удалить, а от библиотеки избавиться не получится, не переписывая код.
Я предлагаю функцию с нулём методов, которую можно использовать с полифилами, если того требует ваша задача. Если не нравится, то можно юзать querySelector[All]. Цель поста — не навязать кому-то мою разработку, а призвать пользователей юзать DOM API вместо библиотек.
DOM API тоже умеет воти всё, что вообще может прийти в голову и даже больше. Буду капитаном, но его используют разработчики библиотек, в том числе, разработчики jQuery.
Для небольшого проекта такой код приемлем. Для большого — юзайте фреймворки, иначе получете макароны.
Если говорить о bala.js, то с Babel или без него (в случае поддержки только современных браузеров, например, при создании приложения под Electron), вы получете такой код:
велосипедафреймворка такое поведение тоже не ясно. Любой фреймворк, на мой взгляд, должен ставить цель расширить круг полезных инструментов, а не монополизировать рынок.Мне нравится идея изоляции CSS, но я не понимаю, зачем такие костыли.
Вьюху можно назвать «байндингами».
Просто мысли в слух: в идеале хотелось бы получить альтернативу jsperf, который объективно замеряет скорость операций. В jsperf я разочеровался после этого теста. Консольный тест с jsperf расходится в 450 раз!