Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 193
убийца jQuery
может понадобиться полифил Fetch API
может понадобиться полифил DOM4
может понадобиться полифилл Web Animations APIОткуда вы такие берётесь?
метод matches стал кроссбраузернымВы называете кроссбраузерными методы, работающие в Android-браузере и IE только через префиксы? Серьёзно?
Да, для поддержки старых Internet Explorer и Webkit-based мобильных браузеров вам придется подключить полифилыТо есть обязательно.
Internet Explorer, с недавних пор, ведет себя хорошо <…> обещая в скором времени отказаться от поддержки всех версий до 11Это вы про браузер с 6 режимами эмуляции, который не пишет в юзер-агенте свою версию?
люди покупают новые айфоны с обновленным сафариОчень мило. Осталось рассказать об этом прочим пользователям
Итого
Вы предлагаете вместо старой проверенной и надёжной jQuery, которая умеет почти всё, что вообще может придти в голову, использовать библиотеку с 4 методами и 3 (три) полифила для неё.
Я ничего не упустил?
Злой у вас комментарий какой-то.
Добро пожаловать на Хабр
Ну уж как есть.
Давайте правде в глаза смотреть, ваша библиотека + все полифилы:
1. легче чем jquery?
2. удобней чем jquery?
3. функциональней чем jquery?
Представьте себе что вам советуют вместо одного инструмента использовать 6? Неужели это удобней? Вы забыли описать самое главное — какие преимущества?
1. легче чем jquery?
2. удобней чем jquery?
3. функциональней чем jquery?
Представьте себе что вам советуют вместо одного инструмента использовать 6? Неужели это удобней? Вы забыли описать самое главное — какие преимущества?
1. легче чем jquery?Зависит от пдерживаемых браузеров.
2. удобней чем jquery?Это холиварный вопрос. Для меня — да.
3. функциональней чем jquery?Да.
Представьте себе что вам советуют вместо одного инструмента использовать 6? Неужели это удобней?Да. В качестве параллели могу пивести PostCSS. В в нем нет ничего, нужно юзать плагины а свой вкус. В SASS есть всё. Но всё больше людей используют PostCSS (в том числе и я). Да и полифилы вряд ли можно назвать инструментами. Скорее, это — костыли для старых браузеров.
Вы забыли описать самое главное — какие преимущества?Какие преимущества нативного DOM? Окей.
1. Максимальная скорость работы кода.
2. Полный контроль над работой DOM.
3. Отсутствие зависимостей.
4. Меньший размер результирующего файла.
5. Полифилы можно выпилить со временем, библиотеку — нет.
Да, для поддержки старых Internet Explorer и Webkit-based мобильных браузеров вам придется подключить полифилы
То есть обязательно
Совсем не обязательно. Поддерживаем на некоторых наших проектах только IE11+ и в ус не дуем.
Такие проекты есть, но они скорее исключение. Обычно это что-то некоммерческое или рассчитанное на относительно узкую аудиторию. Для типичного коммерческого сайта это неприемлемо почти всегда. И в первую очередь — андроиды 4.x.
Крупные, коммерческие сайты предпочитают обзовестись специализированным ПО под андройды и иосы.
Во-первых, я не говорил «крупные» — и мелкие коммерческие тоже. Они не могут себе позволить разбрасываться пользователями.
Во-вторых, я знаю немало людей, которые используют vk, fb, lj и далее по списку — через браузер.
Во-вторых, я знаю немало людей, которые используют vk, fb, lj и далее по списку — через браузер.
А я знаю не мало людей, которые используют через браузер и «плюются», потому что не удобно.
Есть и такие. Но что это меняет в контексте данного разговора? Ничего.
Нативное приложение это, несомненно, хорошо и полезно — но:
а) оно далеко не всегда есть
б) даже если оно есть, это недостаточная причина, чтобы полностью забить на сайт
Нативное приложение это, несомненно, хорошо и полезно — но:
а) оно далеко не всегда есть
б) даже если оно есть, это недостаточная причина, чтобы полностью забить на сайт
а) оно далеко не всегда есть
Далего не всегда есть — это аргумент, чтобы пилить мобильную версию сайта, которой менее удобно пользоваться, чем ПО?
б) даже если оно есть, это недостаточная причина, чтобы полностью забить на сайт
Что значит «полностью забить на сайт»? Я не предлагал написать ПО и вернуть сайт в 2000чные, или по вашему отказ от jQuery сопостовим с «забиванием на сайт»? Как то сильно вы любите эту либу )
Хватит демагогии.
Я имел в виду, что это не причина, чтобы отказываться от поддержки нетоповых, но всё-таки довольно распространенных браузеров (IE10 и старые Андроиды).
А уж как эта поддержка будет сделана, на jQuery или чем-то ещё — вопрос второй.
А поддерживать сейчас только «IE11+ и в ус не дуть» — это всё-таки удел меньшинства сайтов, как бы кому-то не хотелось доказать обратное.
Я имел в виду, что это не причина, чтобы отказываться от поддержки нетоповых, но всё-таки довольно распространенных браузеров (IE10 и старые Андроиды).
А уж как эта поддержка будет сделана, на jQuery или чем-то ещё — вопрос второй.
А поддерживать сейчас только «IE11+ и в ус не дуть» — это всё-таки удел меньшинства сайтов, как бы кому-то не хотелось доказать обратное.
IE10 распространённый браузер? Я давно не видел статистики по нему меньше процента
1,5%: gs.statcounter.com/#desktop+tablet-browser_version_partially_combined-ww-monthly-201509-201511-bar
и, внезапно, там и IE8 целых 2% имеет
и, внезапно, там и IE8 целых 2% имеет
Я не буду спорить насчёт правдивости этой статистики, так как у меня нет никаких данных на этот счёт.
Просто отмечу что:
1) Есть другая статистика, который тоже на первых строчках в гугле по запросу «browser statistic»: http://www.w3schools.com/browsers/browsers_explorer.asp
2) Мы в своём продукте (SPA) поддерживаем IE11+ и жалоб пока нет.
Просто отмечу что:
1) Есть другая статистика, который тоже на первых строчках в гугле по запросу «browser statistic»: http://www.w3schools.com/browsers/browsers_explorer.asp
2) Мы в своём продукте (SPA) поддерживаем IE11+ и жалоб пока нет.
1) Есть другая статистика, который тоже на первых строчках в гугле по запросу «browser statistic»: www.w3schools.com/browsers/browsers_explorer.asp
Стоит отметить, что статистика w3schools.com основана лишь на посетителях этого сайта, которые по большей части являются веб-разработчиками. Статистика statcounter.com идет с тысяч сайтов где установлен их виджет для аналитики, поэтому, скорее всего, более точно отображает «среднего пользователя».
Сейчас посмотрел статистику одного своего сайта (совершенно обычный небольшой сайт по продаже автокомплектующих) — десятка имеет 4%.
А суммарно IE c 8 по 10 — около 7%.
Вполне ощутимо.
Конечно, если судить по «модно-молодежным» сайтам типа соцсетей и хабра, то там скорее всего будет сильно иначе. Но надо хоть иногда выглядывать в реальный мир обычных людей.
А суммарно IE c 8 по 10 — около 7%.
Вполне ощутимо.
Конечно, если судить по «модно-молодежным» сайтам типа соцсетей и хабра, то там скорее всего будет сильно иначе. Но надо хоть иногда выглядывать в реальный мир обычных людей.
Пример статистики с боевого сайта, проекта посвященного ММО игре:
Так что не надо пожалуйста про нераспространенной IE;)
Так что не надо пожалуйста про нераспространенной IE;)
Против MSIE 11 вроде как никто не возражал. Без 11 версии на ИЕ приходится уже незначительные 1.5%.
Для полноты картины хотелось бы увидеть еще статистику доходов по браузерам. А то окажется, что эти 1.5% генерят 0.000001% прибыли, тогда вообще о чем речь.
Для полноты картины хотелось бы увидеть еще статистику доходов по браузерам. А то окажется, что эти 1.5% генерят 0.000001% прибыли, тогда вообще о чем речь.
Ключевые слова тут — «MMO игра». То есть пользователи — молодежь. Давайте еще статистику ЛОРа посмотрим и сделаем по нему глобальный вывод о популярности IE :)
На сайтах с более разнообразной аудиторией доля IE больше в разы (например, см. мой комментарий чуть выше).
На сайтах с более разнообразной аудиторией доля IE больше в разы (например, см. мой комментарий чуть выше).
Причина отказа от поддержки каких-то браузеров всегда одна (на коммерческих проектах) — решение менеджмента о её целесообразности. Грубо, если целевых пользователей IE 8-10 5%, а их поддержка удорожит разработку на 6%, то «IE11+ и в ус не дуть». Иди другой вариант: если замедление работы сайта из-за поддержки IE8-10 отпугнёт 6% пользователей, то тоже «IE11+ и в ус не дуть». То есть два фактора основных: сколько будет стоить поддержка и как она повлияет на нормальных пользователей.
Это всем известно. Но на практике отказываться от ie9-10 обычно особого смысла нет.
Во-первых, они как правило не влекут какого-то чудовищного усложнения поддержки (это же не ie6 прости хоспади). Да, код будет менее чистым и красивым, но каких-то особых трудностей не будет. Хотя конечно бывает что влекут, в специфичных случаях.
Во-вторых, репутационные потери. Заходит человек на сайт и видит, что он поломан. Он будет винить себя и свой браузер? Да ни в жизнь, он решит что сайт плохой и компания нищебродская.
С андроидами так же.
Во-первых, они как правило не влекут какого-то чудовищного усложнения поддержки (это же не ie6 прости хоспади). Да, код будет менее чистым и красивым, но каких-то особых трудностей не будет. Хотя конечно бывает что влекут, в специфичных случаях.
Во-вторых, репутационные потери. Заходит человек на сайт и видит, что он поломан. Он будет винить себя и свой браузер? Да ни в жизнь, он решит что сайт плохой и компания нищебродская.
С андроидами так же.
Подобные вопросы вечны. Помнится стоял вопрос «отказываемся от поддержки ie <6 или нет». С тех пор у меня аргументы не изменились — это бизнес-решение, по которому мы, технари, можем лишь дать оценку затрат на поддержку устаревших клиентов в двух случаях (с деградацией и нет), плюс оценку затрат на «эмуляцию» современных и будущих пользовательских фич, внедрение которых будет сильно затруднено из необходимости совместимости. Ну и текущую статистику, если нет специально обученных людей. А там бизнес-решает.
Не совсем.
Я убежден, что по умолчанию вопрос «надо ли поддерживать браузер X?» всегда имеет ответ «да».
И только конкретные весомые причины могут сменить его на «нет».
А то выше были рассуждения типа +6% издержек уже могут перекрыть -5% посетителей — так вот это недостаточно. Это примерно как не пускать в самолет людей ростом выше 195 и тяжелее 120 — ну а чо? Их же всего пара процентов, примем «оптимальное» бизнес решение.
Достаточные причины:
— издержки растут очень сильно (несколько десятков процентов и более)
— доля браузера пренебрежимо мала (пара процентов это мала, но не пренебрежимо)
— аудитория проекта очень четко очерчена (например сисадмины)
Я убежден, что по умолчанию вопрос «надо ли поддерживать браузер X?» всегда имеет ответ «да».
И только конкретные весомые причины могут сменить его на «нет».
А то выше были рассуждения типа +6% издержек уже могут перекрыть -5% посетителей — так вот это недостаточно. Это примерно как не пускать в самолет людей ростом выше 195 и тяжелее 120 — ну а чо? Их же всего пара процентов, примем «оптимальное» бизнес решение.
Достаточные причины:
— издержки растут очень сильно (несколько десятков процентов и более)
— доля браузера пренебрежимо мала (пара процентов это мала, но не пренебрежимо)
— аудитория проекта очень четко очерчена (например сисадмины)
издержки растут очень сильно
с выходом каждой новой версии каждого популярного браузера издержки растут. Оценочно прогрессия геометрическая.
доля браузера пренебрежимо мала
это бизнесу решать, какая пренебрежимо мала, а какая нет.
рассуждения типа +6% издержек уже могут перекрыть -5% посетителей — так вот это недостаточноКому недостаточно? Вам? Вы отвечаете за издержки проекта и его окупаемость?
Такие проекты есть, но они скорее исключение.
И, конечно, у вас есть подтверждения этому?
Я проигнорирую фразу «Откуда вы такие берётесь?» и постараюсь ответить.
Да, действительно. Вот вам решение:
Зависит от задачи. Если нужно поддерживать старые ослы, то будьте добры подключить полифилы. Это не сложнее чем подключение библиотеки.
Вы описываете проблемы, не предлагая никакого решения. А решение такое: подключать полифилы безусловно и не пользоваться polyfill.io, если страницу посещает много таких пользователей. Если вы пишете проект с долгосрочной поддержкой, полифилы в будущем можно удалить, а от библиотеки избавиться не получится, не переписывая код.
Я предлагаю функцию с нулём методов, которую можно использовать с полифилами, если того требует ваша задача. Если не нравится, то можно юзать querySelector[All]. Цель поста — не навязать кому-то мою разработку, а призвать пользователей юзать DOM API вместо библиотек.
DOM API тоже умеет воти всё, что вообще может прийти в голову и даже больше. Буду капитаном, но его используют разработчики библиотек, в том числе, разработчики jQuery.
Вы называете кроссбраузерными методы, работающие в 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.
Да, действительно. Вот вам решение:Отлично. Больше странного кода для бога странного кода. Хотя нет, для этого лучше сделать ещё один полифилл. Хотя нет, лучше не делать полифиллы, не писать странный код, а пользоваться jQuery — стандартом де факто.
Зависит от задачи. Если нужно поддерживать старые ослы, то будьте добры подключить полифилы. Это не сложнее чем подключение библиотеки.Если мы говорим про веб-разработку, то поддерживать надо всё, что поддерживается в пределах бюджета. И использование jQuery улучшает этот процесс.
Если вы пишете проект с долгосрочной поддержкой, полифилы в будущем можно удалить, а от библиотеки избавиться не получится, не переписывая код.Согласен с вами. В теории (идеальном мире). На практике такого почти никогда не происходит — всё равно приходится переписывать.
Я предлагаю функцию с нулём методов, которую можно использовать с полифилами, если того требует ваша задачаВы предлагает код, который почти ничего не делает и предлагаете его расширять нужными полифилами. И в чём разница с использованием jQuery с кастомными плагинами?
Цель поста — не навязать кому-то мою разработку, а призвать пользователей юзать DOM API вместо библиотекDOM API — чудесно, но неюзабельно в реальных проектах без полифилов. А с полифилами выгода от переключения на него весьма сомнительна.
DOM API тоже умеет воти всё, что вообще может прийти в голову и даже больше. Буду капитаном, но его используют разработчики библиотек, в том числе, разработчики jQuery.Иначе говоря, «это уже было в Симпсонах» — он уже используется в jQuery и преимущество от его использования уже есть и ваша библиотека не нужна.
А если так переформулировать «Иначе говоря, «это уже было в Симпсонах» — он уже используется в вашей библиотекеке и преимущество от его использования уже есть и jQuery не нужна»
Есть две библиотеки, делающие плюс-минус одинаковые вещи, плюс одна из них делает ещё кучу вещей (естественно ценной оверхидов по памяти, трафику, процессору). Зачем мне эта куча, если есть такая, которая делает ровно то, что нужно? Какие у jQuery преимущества перед bala.js в области применения последней?
Есть две библиотеки, делающие плюс-минус одинаковые вещи, плюс одна из них делает ещё кучу вещей (естественно ценной оверхидов по памяти, трафику, процессору). Зачем мне эта куча, если есть такая, которая делает ровно то, что нужно? Какие у jQuery преимущества перед bala.js в области применения последней?
Какие у jQuery преимущества перед bala.js в области применения последнейДопустим (я в это не верю, но допустим что так бывает), у вас действительно нет потребности ни в чём, кроме выборки DOM-элементов. Тогда вы правы — специализированная библиотека (например, bala.js) справится с этой задачей лучше. Более того, это Unix-way.
Но на моей практике все эти замечательные «мне тут только пару элементов в доме выбрать» постепенно приходят к «ну вот тут ещё нужно выбиралку дат сделать», «вон там неплохо бы сделать вкладки» и «вот тут нужен ползунок с двумя рукоятками». И в этот момент все предыдущие маленькие решения выкидываются и ставится jQuery, потому что он это всё делает хорошо.
Или не выкидываются, а продолжают работать, если разработчик предпочитает Unix-way :)
Это, кстати, единственный юз-кейс, когда мне приходилось подключать jQuery. Очень много инструментов требуют зависимости от jQuery либо из-за лени или отсутствия знаний разработчика, либо из-за того, что инструмент достаточно древний. Сейчас не знаю, как с этим дела, надеюсь, лучше.
$ это гораздо больше чем document.querySelectorAll (именно All), например:
И совершенно сразу пропадает желание вручную писать:
А ещё там может быть не строка, а DOM элемент, или jQuery объект, тогда нужно будет добавить несколько условий и мы в итоге закончим тем, что напишем реализацию абсолютно аналогичную оной из jQuery. Вопрос: ЗАЧЕМ???
Перестаньте убивать jQuery, это бесперспективно, займитесь лучше проблемами, которые не были решены должным образом.
Инструменты нужно использовать там, где им место.
$('.xyz').append('<xyz />')
И совершенно сразу пропадает желание вручную писать:
[].forEach.call(
document.querySelectorAll('.xyz'),
function (node) {
node.insertAdjacentHTML('beforeend', '<xyz />');
}
);
А ещё там может быть не строка, а DOM элемент, или jQuery объект, тогда нужно будет добавить несколько условий и мы в итоге закончим тем, что напишем реализацию абсолютно аналогичную оной из jQuery. Вопрос: ЗАЧЕМ???
Перестаньте убивать jQuery, это бесперспективно, займитесь лучше проблемами, которые не были решены должным образом.
Инструменты нужно использовать там, где им место.
И совершенно сразу пропадает желание вручную писать
Для небольшого проекта такой код приемлем. Для большого — юзайте фреймворки, иначе получете макароны.
Если говорить о bala.js, то с Babel или без него (в случае поддержки только современных браузеров, например, при создании приложения под Electron), вы получете такой код:
for(let node of $('.xyz')) {
node.insertAdjacentHTML('beforeend', '<xyz />');
}
напишем реализацию абсолютно аналогичную оной из jQuery
Вы настолько хорошо знакомы с внутренностями jQuery, что делаете такие мастабные выводы? Как вы считаете, насколько похудеет jQuery если лишить ее поддержки «особенностей» ie? А если еще отказаться от «особенностей» мобильных платформ?
Если говорить об объеме в символах — то около 10% jQuery 3.0 можно будет вырезать, навскидку.
Я уже давно использую версию 3.0, там древние версии IE по большей части вырезаны, как и старые версии мобильных браузеров.
А по поводу внутренностей — там каждый символ на счету и очень тщательная проверка всех изменений.
К примеру, из последнего: github.com/jquery/jquery/commit/eaa3e9f0cfc68083556cf61195821d90e369f646
Рефакторинг чтобы сохранить дополнительные 21 байт. При этом не страдает читабельность, чего не скажешь про bala.js.
Я к тому, что написать односимвольное сокращение для document.querySelector может любой, но даже самые типичные потребности идут гораздо дальше этого.
Я уже давно использую версию 3.0, там древние версии IE по большей части вырезаны, как и старые версии мобильных браузеров.
А по поводу внутренностей — там каждый символ на счету и очень тщательная проверка всех изменений.
К примеру, из последнего: github.com/jquery/jquery/commit/eaa3e9f0cfc68083556cf61195821d90e369f646
Рефакторинг чтобы сохранить дополнительные 21 байт. При этом не страдает читабельность, чего не скажешь про bala.js.
Я к тому, что написать односимвольное сокращение для document.querySelector может любой, но даже самые типичные потребности идут гораздо дальше этого.
jQuery source viewer james.padolsey.com/jquery
Писал на ванильном джесе и пришел скорее к backbonejs, нежели к jquery. Что я сделал не так?
А ничего, что он использует jQuery?) backbonejs.org/#View-dollar
Вы не услышали мой комментарий. Я сказал что пришел скорее к backbonejs, нежели к jquery. Это означает, что структура моего решения позволила отказаться от вермишели jquery, но не позволила отказаться от архитектуры MV*.
Если уж вы решили поделиться ссылкой, то поведую вам, что BackboneJS не зависит и не использует jQuery. jQuery для BackboneJS это всего навсего одна из реализации некоторого функционала. Его можно легко заменить на ZeptoJS или на свою ванильную реализацию, BackboneJS от этого не пострадает.
Если уж вы решили поделиться ссылкой, то поведую вам, что BackboneJS не зависит и не использует jQuery. jQuery для BackboneJS это всего навсего одна из реализации некоторого функционала. Его можно легко заменить на ZeptoJS или на свою ванильную реализацию, BackboneJS от этого не пострадает.
Просто как вариант:
Array
.from(document.querySelectorAll('.xyz'))
.forEach(node =>
node.insertAdjacentHTML('beforeend', '<xyz />')
);
Я на LiveScript тоже компактнее пишу, специально написал на JS канонический вариант чтобы все поняли.
Но это транспайлеры, суть от этого не меняется, это гораздо менее удобно чем jQuery. Для одноразового использования можно и нужно, но постоянно писать такой код — это слишком много визуального шума, читать такую простыню сложно.
Но это транспайлеры, суть от этого не меняется, это гораздо менее удобно чем jQuery. Для одноразового использования можно и нужно, но постоянно писать такой код — это слишком много визуального шума, читать такую простыню сложно.
Предупреждал же, что микро-пакетные решения гораздо удобнее, чем фреймворки. Когда пакет устаревает, его можно выкинуть, заменив на ванильную реализацию, при этом остальные пакеты остаются в строю.
Бала — это ещё и «ребёнок» по-казахски:)
У меня только один вопрос: Вы всегда пишите минифицированный код сразу?
Так сильно сжать код, при этом сделав его читабельным — достаточно сложно. Я попробую расставить табы, спасибо за мысль.
Так, вроде, лучше.
Вы же в курсе, что x.querySelector(y) это не то же самое, что jQuery запрос с контекстом?
Я про то, что querySelector всегда мэтчит от корня (документа), а не от указанного контектса. И обычно это НЕ то, что нужно.
Я про то, что querySelector всегда мэтчит от корня (документа), а не от указанного контектса. И обычно это НЕ то, что нужно.
Лично я не в курсе. То есть x.querySelector(y) делает поиск от корня и уже потом фильтрует?
Не могли бы рассказать об этом подробнее?
Не могли бы рассказать об этом подробнее?
www.w3.org/TR/selectors-api
Это API использует тот же движок, что и браузер при работе с CSS селекторами. По-сути, этим и обусловлено такое поведение.
Even though the method is invoked on an element, selectors are still evaluated in the context of the entire document.
Это API использует тот же движок, что и браузер при работе с CSS селекторами. По-сути, этим и обусловлено такое поведение.
Ок, но я не вижу в этом ничего ужасного.
Пусть этот метод не настолько оптимален на сколько мог бы быть, но если профилировщик не показывает что его вызов является узким местом, то почему бы его не использовать.
Пусть этот метод не настолько оптимален на сколько мог бы быть, но если профилировщик не показывает что его вызов является узким местом, то почему бы его не использовать.
Я ничего не говорил про проблемы. Лишь дал ответ на ваш вопрос.
Изначально формулировка (от другого человека) говорила о том, что реализация в jQuery будет отличаться от
Изначально формулировка (от другого человека) говорила о том, что реализация в jQuery будет отличаться от
element.querySelector()
Проблема не в производительности, а в том, что результат не тот, что обычно нужен (если у вас есть контекст).
Есть же http://zeptojs.com/ уже?
А мне кажется, что попытки «свержения» «библиотек 'де-факто'» это своеобразный двигатель прогресса. В большинстве больших проектов жиквери уже не нужно — всё делает фреймвёрк, а в малых проектах жиквери и не нужно, можно обойтись «408 символами кода» ( finom ).
всё делает фреймвёркДа, в основном потому что jQuery встроен почти во все фреймворки.
Быть встроенным в и быть зависимым от — разные вещи
Хм, спорное утверждение.
Аргументирую. jQuery не встроен, например в Angular, React+Flux, Polymer. В других более мелких проектах есть возможность подключить пяток необходимых микро-библиотек, которые являются обертками поверх
XMLHttpRequest аналоги $.ajax, сахаром для работы с DOM, Promises. Я считаю утверждение «jQuery встроен почти во все фреймворки» спорным, потому как почти каждый современный популярный фреймверк не тянет jQuery с собой и не зависит от этой библиотеки.jQuery не встроен, например в AngularВ Ангуляр встроен jQlite — тот же jQuery, но без дублируемых ангуляром функций.
Это не тот же jQuery. Это ограниченный набор функций. Где нет ни методов для работы с XMLHttpRequest, ни промисов. Поэтому часто рядом с ангуляром подключают еще и jQuery.
jQuery в angular-проект подключают явно не для ajax'а с промисами, ведь в ангуляре есть свои реализации.
Окей, теперь с Ангуляром у меня все стало на места. Согласен, Ангуляр является плохим примером фреймверка «без jQuery».
Ну хорошо, продолжу Ext.Js (кстати довольно старый фреймверк, активно юзается в энтерпрайзе), Sencha Touch, Vue.js, Riot.js (последние два не столь популярны, но новы и известны в узких кругах).
Ну хорошо, продолжу Ext.Js (кстати довольно старый фреймверк, активно юзается в энтерпрайзе), Sencha Touch, Vue.js, Riot.js (последние два не столь популярны, но новы и известны в узких кругах).
Да нет, хороший пример. jQuery в ангуляре почти не нужен. ИМХО, его стоит подключать либо когда нужен какой-то jq-плагин, у которого нет достойных аналогов в виде ангуляр-модуля (или на чистом js), либо когда нужна какая-то прям очень сложная работа с DOM, с которой ангуляровские средства не справятся.
С другой стороны, чаще всего в большом проекте какая-то библиотека всё-равно захочет jq себе в зависимости. А ангуляр умеет детектировать наличие jquery и использовать его заместо jqlite.
С другой стороны, чаще всего в большом проекте какая-то библиотека всё-равно захочет jq себе в зависимости. А ангуляр умеет детектировать наличие jquery и использовать его заместо jqlite.
Какое «такое»?
Где для вас грань между «велосипедом» и «промышленным стандартом де-факто» типа jQuery? Только то, понимаете ли ві лично как оно работает? Или вы вообще не используете сторонний код?
Не нужно разводить демагогию, вы отлично знаете где эта грань: спросить у новичка, полгода-года работающего в отрасли, слышал/работал он с этой библиотекой/фреймворком или нет.
Ну вот я не знаю API jQuery, вы не знаете, например, API prototype. Мне без разницы изучать на проекте jQuery или bala. А вам есть разница изучать prototype или bala?
я бы не был столь голословным, я знаю jq api только на уровне селекторов и некоторых очевидных методов. Не у всех фронэендеров задачи сводятся к jq.
Не все. Это факт.
Может чуть поменьше провел, но несколько человек не знали jQuery. Нюанс: они пошли на фронтендеров с бэкенда и декстопа и после азов js сразу начали учить Ангуляр.
Откуда такая уверенность, что по-любому столкнется? Сколько процентов проектов, по-вашему, использует jQuery?
Факт первый — рынок фронт-енд разработки, и в мире, и везде, завязан на энтерпрайз.
Что вы называете завязкой на ентерпрайз?
До появления SPA-фреймворков наличие в этом легаси коде jQuery мне кажется вам сложно будет оспорить — он был везде
Не везде. Он постепенно занял лидирующие позиции, и как раз в легаси jQuery можно и не встретить, а встретить кого-то из его когда-то равных конкурентов типа prototype.
и у него в жестких зависимостях jQuery.
В хорошем фремйворке всё равно, что в зависимостях, он предоставляет более высокий уровень абстракции. Более того, некоторые могут работать с несколькими низкоуровневыми «бэкендами» прозрачно для пользователя.
Другое дело, что на популярность jQuery сильно повлиял тот фактор, что некоторые локальные решения, да и глобальные решения имели зависимость от jQuery, и когда вставал вопрос «что использовать для задачи такой-то jQuery или *?», то ответ был «в принципе без разницы, но jQuery у нас уже есть в зависимостях» (что впоследствии часто приводило к проблемам, когда один компонент использовал одну версию jQuery, а другой — другую).
По моей личной статистике, использование jquery в проекте часто говорит о низкой квалификации разработчиков. Либо об отношении к проекту как к одноразовой задаче, которую будет поддерживать кто-то другой.
Я называю завязкой на энтерпрайз завязку на энтерпрайз. UI для крупных корпоративных приложений, если не понятно.
То есть вы сейчас говорите о приложениях, к которым у обычного смертного и доступа-то нет?
Постепенно занял лидирующие позиции? В какой реальности? Prototype не был ему равным конкурентом никогда, он всегда имел гораздо меньший процент использования, не надо сочинять.
Даже в 2005-м году?
человек, изучавший популярнейшие в мире фреймворки для SPA сталкивался с jQuery и соответствнно знаком с его API на уровне вещей описанных в статье.
Даже если первая часть вашего утверждения правда, то вторая из неё не следует автоматически.
По вашей личной статистике — вполне может быть и так. Судя по вашим комментариям, если вы верстальщиков считаете фронт-энд разработчиками, невысокого уровня специалист.
О, уже переходы на личности, да с искажением фактов. Перечитайте мои комменты: в них я говорил, что к нам на вакансию веб-разработчиков, приходят HTML/CSS верстальщики, поверхностно работавшие с jQuery и потому считающие себя уже разработчиками, а не верстальщиками.
На этот-то вопрос, как раз-таки, ответ есть.
trends.builtwith.com/javascript/jQuery
trends.builtwith.com/javascript/jQuery
69% сайтов самых посещаемых сайтов в мире, по статистике Libscore.
Я не знаю жуквери API так как не пользовал его уже года 3. Разве что базовую работу с селекторами вспомню. О, печаль-беда, я новичок и мой уровень — максимум уровень интерна :( Ох уж эти UI/UX инженеры, считающие, что жуквери это и есть JS.
Чем еще померяемся?
Какие странные у вас желания.
Если я что-то не вспомню — значит я этого уже не знаю. Ферштейн?
Ага. Я уже не должен счить себя программистом и вру о том, что пользовал жуквери. Так и запишем.
Не много ли вы на себя берёте с такими-то утверждениями? :)
> Как можно изучить фреймворк и забыть?
Если учитывать количество фреймворков, которые мучал — легко и просто. А ещё жуквери не фрейморк.
Не много ли вы на себя берёте с такими-то утверждениями? :)
> Как можно изучить фреймворк и забыть?
Если учитывать количество фреймворков, которые мучал — легко и просто. А ещё жуквери не фрейморк.
А вы не много на себя берете, начиная разговор с пассажа про UI/UX, считающих, что жуквери это и есть JS?
Не много. Логичный вывод из ваших предыдущих комментариев.
Я привел аргументацию
Потрясающая аргументация — я привёл качестве контраргумента себя, знаю нескольких других разработчиков, далеко не юниоров, что если и вспомнят это — то с трудом — ибо оно не нужно.
нихрена ты, дорогой, и не знал.
А вот за это можо (и нужно) по лицу при встрече. Запомним.
Я занимаюсь версткой
Оно и видно.
Итак, значит я не тяну даже на юниора? :(
Знали бы вы сколько мы отсеяли ведущих JS разработчиков, с 5+ годами работы, которые валятся на элементарных тестах на знание js. Мы скорее наймем человека который не знает jquery, потому что он реально что то знает и что то делал, а не гуглил последние 5ть лет нужный плагин в интернете.
Кидайте поменьше говна на вентилятор, есть проекты для которых jquery и нафиг не нужен, а с развитием новых стандартов эта тенденция только расширяется.
Кидайте поменьше говна на вентилятор, есть проекты для которых jquery и нафиг не нужен, а с развитием новых стандартов эта тенденция только расширяется.
Не, не понятно, капсом писать надо.
Мы вам говорим, что лично ваша статистика это не показатель дел в отрасли, у нас в компании jquery почти не используется и по лично моей статистике люди которые не знают jquery оказываются куда более компетентней людей которые его знают. Но Вы конечно и дальше можете тут биться в истерике и доказывать правоту вашей статистики.
Мы вам говорим, что лично ваша статистика это не показатель дел в отрасли, у нас в компании jquery почти не используется и по лично моей статистике люди которые не знают jquery оказываются куда более компетентней людей которые его знают. Но Вы конечно и дальше можете тут биться в истерике и доказывать правоту вашей статистики.
Речь не идет о полном не знании jq, естественно о его существовании слышали все, но насколько глубоко знают люди апи jq? А самое главное, является ли это показателем уровня разработчика. Для меня большинство юзкейсов jquery это: получить элемент по селектору, снять/навесить обработчик, поманипулировать с dom и поставить снять класс. Но в jquery куда больше методов, только мне до них дела нет, и я их не знаю или не использую. А все то что чаще всего используется уже реализовано на уровне стандарта, так вот и вопрос, так ли он необходим этот jquery?
Основной проект у нас 100M+ пользователей, да на основном проекте используется jq, но он там встроен в вреймворк и больше является рудиментом, 99% кода который пишут фронтенд разработчики никак не связан с jq.
Так же есть ряд других проектов, в которых ситуация с jq такая же, а в некоторых он не используется вовсе.
Что касается моих наблюдений об интервьюируемых мной людях, то очень часто к нам приходят люди которые имеют большой опыт работы фронтенд разработки на jq и странным образом они не могут объяснить такие простые вещи, как: чем отличаются GET от POST запросы, не знают как работают куки, не могут объяснить как распространяются события в браузере и я уже молчу про такие вещи как, замыкания, прототипы, ссылочные типы. Так кто же все эти люди которые много лет программировали фронтенд на jq?
Основной проект у нас 100M+ пользователей, да на основном проекте используется jq, но он там встроен в вреймворк и больше является рудиментом, 99% кода который пишут фронтенд разработчики никак не связан с jq.
Так же есть ряд других проектов, в которых ситуация с jq такая же, а в некоторых он не используется вовсе.
Что касается моих наблюдений об интервьюируемых мной людях, то очень часто к нам приходят люди которые имеют большой опыт работы фронтенд разработки на jq и странным образом они не могут объяснить такие простые вещи, как: чем отличаются GET от POST запросы, не знают как работают куки, не могут объяснить как распространяются события в браузере и я уже молчу про такие вещи как, замыкания, прототипы, ссылочные типы. Так кто же все эти люди которые много лет программировали фронтенд на jq?
Когда человек горит «я знаю API jQuery», то подразумевается, что он знает его весь, что на вопрос о любом методе он ответит хотя бы «этот метод делает то-то, но в детали я не вникал», а не «я знаю что $ позволяет получить элмент по селектору» — это даже я знаю, хотя jQuery не знаю.
Другими словами ни одной организации не надо, чтобы исполнитель знал API. А если соискатель утверждает, что знает, но не может ответить о назначении случайно выбранного метода из API, то на его резюме ставится пометка «завышает знания», а уж потом эйчары разбираются враньё это или искреннее заблуждение. В любом случае неточность формулировок — большой минус для разработчика, основной задачей которого является трансляция неформализованных требований в однозначно понимаемые исполнительным устройством команды.
Где в документации описано «это основные методы, а это не основные», «эти параметры основные, их нужно знать, а эти неосновные, не грех и в документацию заглянуть»? Или вы называете методы основными исключительно по тому, как часто лично вы их используете или видите?
Где в документации описано «это основные методы, а это не основные», «эти параметры основные, их нужно знать, а эти неосновные, не грех и в документацию заглянуть»? Или вы называете методы основными исключительно по тому, как часто лично вы их используете или видите?
>люди которые не знают jquery оказываются куда более компетентней людей которые его знают
Сказки.
Сказки.
Личная статистика собеседований по вакансиям типа «junior web developer»:
Большинство тех, кто знает jquery лучше меня, не знают ни javascript, ни какой-нибудь другой ЯП, при словах «паттерны», «принципы проектирования» — абсолютно непонимающие лица. По сути верстальщики, для которых jquery — расширение HTML/CSS. Они могут делать многое на фронте, но они не программисты.
Большинство тех, кто знает javascript, знает какой-нибудь другой ЯП, знает хотя бы про трезвенные архитектуры, MVC, могут объяснить с достаточно детализацией что происходит от момента нажатия enter в адресной строке до вывода страницы в браузере.
Большинство тех, кто хоть как-то знает только javascript, «знает» jquery на уровне вызова $(selector) и $.ajax(settings), их использовали на практике, но не могут толком объяснить, что эти функции возвращают.
Большинство тех, кто знает jquery лучше меня, не знают ни javascript, ни какой-нибудь другой ЯП, при словах «паттерны», «принципы проектирования» — абсолютно непонимающие лица. По сути верстальщики, для которых jquery — расширение HTML/CSS. Они могут делать многое на фронте, но они не программисты.
Большинство тех, кто знает javascript, знает какой-нибудь другой ЯП, знает хотя бы про трезвенные архитектуры, MVC, могут объяснить с достаточно детализацией что происходит от момента нажатия enter в адресной строке до вывода страницы в браузере.
Большинство тех, кто хоть как-то знает только javascript, «знает» jquery на уровне вызова $(selector) и $.ajax(settings), их использовали на практике, но не могут толком объяснить, что эти функции возвращают.
«Большинство» — это не статистика. Это во-первых. Статистика — это нормальные цифры и понятные методы исследования.
А во-вторых — я понял, что вы такой единственный уникум, который и JS в целом знает, и другие ЯП, и в jQuery ориентируется. Больше таких людей нет.
А во-вторых — я понял, что вы такой единственный уникум, который и JS в целом знает, и другие ЯП, и в jQuery ориентируется. Больше таких людей нет.
Если бы я прийдя на проект увидел, что тут используется такое, был бы крайне недоволен.
Ни слова больше! Автор, срочно удаляй «подобную поделку» из всех реп!
Помимо всего вышесказанного одно из преимуществ JQuery, которое сложно победить — JQuery раздается через гугловский CDN и скорее всего уже лежит у пользователя в кеше браузера, а вашу библиотечку еще скачать надо.
Это не библиотека, а одна функция и её скачивать (подключать через script) не надо.
Вы не совсем поняли мою мысль. Реализовать кусок функциональности JQuery в 408 символах это конечно красиво, только надо понимать, что это дополнительные 408 символы, которые по сути дублируют существующую функциональность. Даже если проблемы реализации через год-два исчезнут, это не изменит того, что библиотека (функция, whatever) решает проблему, которой нет.
Вы используете 5% жиквери, но при этом боитесь закачать «лишние» 408 символов кода?
До появления jQuery люди песни слагали ( https://www.youtube.com/watch?v=vTTzwJsHpU8 ), о проблемах при написании фронтенда, jQuery эту проблему решила, вдобавок сильно приятнее сделав синтаксис и т.п. Вы мне предлагаете взять поделку, которая использует подобный синтаксис, но при этом вместо решения проблем, наоборот добавляет кучу новых… конечно боюсь!
CDN — спорное преимущество. Для конечного пользователя он может быть недоступен по разным причинам (блокировка, неполадки на сервере) и тогда веб-приложение сломается.
На проде надёжнее всю статику (js/css) загнать в 1 файл (с таймштампом или чем-то подобном в имени), который и будет лежать в кэше, пока не протухнет или не обновится (при обновлении меняется имя -> никто из пользователей не будет тянуть неактуальную версию из кэша). Плюс, есть много готовых вариантов для сборщиков, чтобы организовать такое.
На проде надёжнее всю статику (js/css) загнать в 1 файл (с таймштампом или чем-то подобном в имени), который и будет лежать в кэше, пока не протухнет или не обновится (при обновлении меняется имя -> никто из пользователей не будет тянуть неактуальную версию из кэша). Плюс, есть много готовых вариантов для сборщиков, чтобы организовать такое.
Конкуренция это хорошо, именно она двигает jQuery вперед)
jQuery развивается сам по себе, никакой конкуренции нет. Предполагаю, что она будет в мейнстриме не меньше пяти лет.
jQuery конкурирует с нативным JS, будущим ES2015+ и всеми теми либами-убийцами (вроде той, про которую пост). Так что конкуренции выше крыши. Можно еще вспомнить прошлые годы, когда jQuery вытеснил Prototype.
Я имею в виду, сколько бы ни было конкурентов в виде фреймворков, крутых и современных замен, jQuery всегда занимает свою нишу, потому что:
а) Она простая. Любой новичок, который знает CSS может с ней разобраться.
б) Она популярна.
в) Она предсказуема. Взять хотя бы делегированные события, которые невероятно сложно заставить работать так, как обычные события (например, заставить работать stopPtopagation так, как он работает с неделегированными событиями).
А всё остальное (в том числе и bala.js) — для тех, кого достало и для тех, кто хочет писать самый быстрый и самый контроллируемый код, т. е. для более-менее опытных разработчиков. Новички и консерваторы («бородатые» новички) будут на рынке веб разработки всегда.
а) Она простая. Любой новичок, который знает CSS может с ней разобраться.
б) Она популярна.
в) Она предсказуема. Взять хотя бы делегированные события, которые невероятно сложно заставить работать так, как обычные события (например, заставить работать stopPtopagation так, как он работает с неделегированными событиями).
А всё остальное (в том числе и bala.js) — для тех, кого достало и для тех, кто хочет писать самый быстрый и самый контроллируемый код, т. е. для более-менее опытных разработчиков. Новички и консерваторы («бородатые» новички) будут на рынке веб разработки всегда.
Странно видеть так много негативных комментариев о проекте, который далеко не самый бессмысленный и бесполезный. Некоторые комментарии выходят за рамки критики и переходят в разряд откровенных оскорблений (например).
Мне не понятно, как можно «поносить» человека, который пытается что-то делать. Степень успешности/актуальности того, что он делает это вопрос н-ный. Проще всего не делая ничего быть великим экспертом во всем.
Понятно, что часть критических/жестких комментариев автор спровоцировал сам. Спровоцировал, излишне «желтым» заголовком статьи и тем, что навесил на свой проект ярлык «убийца jQuery».
Как бы там ни было — это не повод опускаться до откровенных оскорблений.
Мне не понятно, как можно «поносить» человека, который пытается что-то делать. Степень успешности/актуальности того, что он делает это вопрос н-ный. Проще всего не делая ничего быть великим экспертом во всем.
Понятно, что часть критических/жестких комментариев автор спровоцировал сам. Спровоцировал, излишне «желтым» заголовком статьи и тем, что навесил на свой проект ярлык «убийца jQuery».
Как бы там ни было — это не повод опускаться до откровенных оскорблений.
Спасибо за добрый комментарий. Об «убийце jQuery» это была шутка, прямо в начале поста есть приписка.
Имхо, многие оскорбились тем, что им предложили либу, которая из коробки не умеет почти ничего и требует дополнительных полифилов.
Оптимальная стратегия тут действовать наоборот:
1. Изначально предложить либу, которая будет все уметь сразу
2. Как опцию предложить исключить из сборки те полифилы, которые не интересуют пользователей.
Оптимальная стратегия тут действовать наоборот:
1. Изначально предложить либу, которая будет все уметь сразу
2. Как опцию предложить исключить из сборки те полифилы, которые не интересуют пользователей.
Насчет либы, которая «может все» — мне кажется, что автор преследовал несколько иные цели…
Сужу по себе. Я к примеру, при разработке проектов в режиме «just for fun» предпочитаю использовать «чистый» JavaScript. Но при этом для удобства, отдельным файлом подключаю дополнительный функционал (пример), где дописываю то что упростит процесс разработки (включая некоторые методы jQuery).
Полагаю, что подобное js-расширение у автора переросло со временем в либу, которую он описал в статье. Просто нужно было явно в статье ограничить зону использования этой библиотеки.
Сужу по себе. Я к примеру, при разработке проектов в режиме «just for fun» предпочитаю использовать «чистый» JavaScript. Но при этом для удобства, отдельным файлом подключаю дополнительный функционал (пример), где дописываю то что упростит процесс разработки (включая некоторые методы jQuery).
Полагаю, что подобное js-расширение у автора переросло со временем в либу, которую он описал в статье. Просто нужно было явно в статье ограничить зону использования этой библиотеки.
Это не либа :)
Мне не понятно, как можно «поносить» человека, который пытается что-то делать.С моей точки зрения автор не «пытается что-то делать», а замусоривает информационное пространство очередной невероятной библиотекой, единственным плюсом которой является фатальный недостаток других библиотек. Это не «что-то делать», а явный вред.
А мне нравится! И вообще, говорят так «Если Вас не критикуют, значит Вы не добились успеха». И еще мне понравился парсинг через Вашу библиотеку. Но jQuery конечно привычнее будет.
Кстати, в защиту jQuery, за последние полгода я заюзал одну функцию из библиотеки — .parseHTML. Ни один парсер, в том числе, нативный (document.implementation.createDocument) не смог так точно распарсить HTML документ, как это сделал jQuery.
Честно говоря, я и предположить не мог, что мой пост вызовет столько срача с пожеланиями мне отправиться в больницу, обвинениями меня во вредительстве, вопросами «откуда вы такие беретесь». Любой инструмент нужно использовать тогда, когда в нём есть необходимость. Для 99% проектов нативный DOM выполняет свою задачу лучше, чем сторонняя библиотека. Это та мысль, которую мне хотелось донести.
Честно говоря, я и предположить не мог, что мой пост вызовет столько срача с пожеланиями мне отправиться в больницу, обвинениями меня во вредительстве, вопросами «откуда вы такие беретесь». Любой инструмент нужно использовать тогда, когда в нём есть необходимость. Для 99% проектов нативный DOM выполняет свою задачу лучше, чем сторонняя библиотека. Это та мысль, которую мне хотелось донести.
Это похоже на риторический вопрос
Что вам сейчас мешает это делать? Используйте babel, подключайте только те пресеты которые вам необходимы. js сейчас активно развивается, ждать нативных реализация смысла нет, в случае с babel останется только выключать не нужные пресеты и подключать нужные по мере развития языка и браузеров, а не ждать когда там браузеры дорастут до стандарта. Что то мне подсказывает что они будут отставать года так на два.
Как насчёт добавить $.one в балалайку?
Всем, кто подписан на комментарии…
Во-первых, с Новым Годом. Во-вторых, функция дожата до 377 символов, что меньше чем код отслеживания Google Analytics.
Во-первых, с Новым Годом. Во-вторых, функция дожата до 377 символов, что меньше чем код отслеживания Google Analytics.
функция дожата до 377 символов
Вот вы пишите так, будто в этом есть что-то хорошее, а я из-за этого её и не использую. Может уж лучше потратить лишнюю сотню-другую символов и сделать функцию легко читаемой, быстрой и без потенциальных проблем? Вот пример:
(typeof s)[7]
Оке, комментарий поясняет что оно делает, без него многие и не поймут. В отличии от
typeof s == 'function', движки не оптимизируют этот случай. Год-другой и будет доступны, например, SIMD и типизированые объекты со своим результатом typeof длиннее 7 букв.Может уж лучше потратить лишнюю сотню-другую символов и сделать функцию легко читаемой,Идея в том, чтоб сжать функцию настолько сильно, насколько это возможно, в ущерб читаемости (как в js1k). Для остального есть jQuery-подобные крупные библиотеки или возможность форка для тех, кому очень надо.
быстройА что со скоростью не так? Напротив, применяется как можно меньше операторов и методов.
и без потенциальных проблем?
Какие потенциальные проблемы вы можете встретить сейчас?
Год-другой и будет доступны, например, SIMD и типизированые объекты со своим результатом typeof длиннее 7 букв.
Во-первых, как только SIMD появится в стабильной ветке хотя бы в одном браузере, этот момент будет учтен. Во-вторых это очень узкий юз-кейс. Я не представляю, кто может догадаться передать SIMD тип в эту функцию. В крайнем случае, вы получете ошибку float32x4 is not a function (или типа того) и в стеке увидете, где ошибка вызвана.
Идея в том, чтоб сжать функцию настолько сильно, насколько это возможно, в ущерб читаемости (как в js1k).
Согласен, читаемость не проблема. А вот 2 остальные — ещё какие проблемы для такой, скажем так, доволько важной функции.
А что со скоростью не так? Напротив, применяется как можно меньше операторов и методов.
В том и дело — компактный далеко не всегда быстрый. На уже упомянутом простеньком примере.
Какие потенциальные проблемы вы можете встретить сейчас? Я не представляю, кто может догадаться передать SIMD тип в эту функцию.
SIMD это только пример. Других проблем хватает. Например, для данного примера с typeof я ну упомянул о не array-like строках в ES3, хотя, думаю, на ES3 движки, даже с полифилами, код и не ориентирован :) В любом случае, это только 13 символов из 377.как только SIMD появится в стабильной ветке хотя бы в одном браузере, этот момент будет учтен.
И вы так уверены, что все сразу обновят эту функцию? :)
Окей, сдаюсь. Сделал
(разницы почти нет)
typeof s == 'function'.На уже упомянутом простеньком примере.На jsperf не люблю ориентироваться. Лучше бенчмаркать такие вещи в консоли:
window.it = [];
window.x = false;
console.time('xxx');
for(var i=0; i < 1e6; i++) {
x = typeof it == 'function';
}
console.timeEnd('xxx');
console.time('yyy');
for(var i=0; i < 1e6; i++) {
x = (typeof it)[7];
}
console.timeEnd('yyy');
(разницы почти нет)
А зря не любите. Здесь вы измеряете производительность цикла, а не
typeof. А вообще — с одного typeof толку мало :)Затраты суммируются. По-вашему цикл «съедает» всё?
В смысле «всё»? :) Даже с учетом цикла разница видна невооруженным взглядом:
Или вы в консоли код запускаете? :)
Или вы в консоли код запускаете? :)
Хм, у меня разницы нет (учитывая небольшую погрешность).
xxx: 2805.133ms
yyy: 2799.653ms
xxx: 2805.133ms
yyy: 2799.653ms
Сохраните код как HTML документ и почувствуете разницу.
А то так вы его просто
А то так вы его просто
evalите.Хм, буду знать. На jsbin цифры совсем другие.
Это, конечно, оффтоп, но почему такое поведение? Допустим, я заэвалил этот код и V8, после этого, должен применить свои оптимизации, разве не так? Тело цикла, ведь, не эвалится на каждой итерации. Разница в скорости — 20 раз!
Дайте что-нибудь почитать, а то совсем чайником себя почувствовал впервые за последний год.
Дайте что-нибудь почитать, а то совсем чайником себя почувствовал впервые за последний год.
Можете вычесть zzz из результатов:
window.it = [];
window.x = false;
console.time('xxx');
for(var i=0; i < 1e6; i++) {
x = typeof it == 'function';
}
console.timeEnd('xxx');
console.time('yyy');
for(var i=0; i < 1e6; i++) {
x = (typeof it)[7];
}
console.timeEnd('yyy');
console.time('zzz');
for(var i=0; i < 1e6; i++) {
}
console.timeEnd('zzz');
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
bala.js — убийца jQuery в менее чем 400 символах кода *