Как стать автором
Обновить

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

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

Да это же мечта перфекциониста!

Ну будет там вместо одного jquery десяток полифилов и пол сотни велосипедов, принципиально особо ничего не поменяется, пока последний IE не вымрет.
НЛО прилетело и опубликовало эту надпись здесь
Вопрос не в количестве разработчиков, а в количестве пользователей.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
В любом случае это наверняка люди на достаточно мощных машинах и не на IE.
Зайдет человек ISSUE отправить или Wiki полистать или обновить, а ему, как мне напишут, мол, извините, поддержка любого IE прекращена.
А у нас (30к рабочих мест, маленькая телеком компания) это единственный официально поддерживаемый браузер.

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

Во многих местах люди борятся за конверсию и даже 1% конверсии является весьма значимым значением. Лишь некоторые веб-разработчики имеют вольность разбрасываться аудиторией как им вздумается — выкидывать поддержку распространенных и актуальных браузеров, делать невменяемые размеры JS кода, ставить неадекватные KeepAlive и так далее.
Терпимее надо быть, терпимее — не у всех блид эдж версия всего и вся, корка ай7, 32 ГБ ОЗУ и гигабитный интернет.

Точно так же говорили работники банковского сектора, когда массово избавлялись от ie6, у них были даже посерьезнее причины, т.к. много их софта было написано на связке нэтив и ie6. К счастью, их не стали слушать. Вам же не предлагают апгрейд, вам просто предлагают сменить браузер.

Т.е. сменить место работы.
А еще сменить железо, оператора сотовой связи и его никакое покрытие и, наконец, страну. Ваша точка зрения мне понятна.
или донести до руководства или кто там у вас решает, что можно, а что нельзя, что время не стоит на месте. про оператора и покрытие, я не очень понял — размеры бандла стали меньше, чем вы не довольны в этом аспекте?
Еще один фантастический сценарий.
На 40КБ jQuery? Ок, тут, пожалуй, да.
Просто обычно вместо jQuery прилетает любой популярный фреймворк, который больше) Тут на ваниллу переписали, повезло.
Во многих местах люди борятся за конверсию и даже 1% конверсии является весьма значимым значением.

Все ведь зависит от соотношения затрат и прибыли в итоге. Так уж вышло, что обычно выгоднее сделать более круглую кнопочку, чтобы привлечь внимание обладателя ай7 корки с 32гб озу, чем плодить костыли ради маргиналов с ие. Nothing personal, it's just business.

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

Кто тратит? Те самые люди, которые сидят за компуктерами с протухшим 10 лет назад ИЕ потом в этом ИЕ заходят на мой сайт чтобы потратить свои личные деньги?

Компания тратит, в которой эти люди работают. habr.com/post/418257/#comment_18925333
Но сложно будет потратить деньги, если сайт о продукте не открывается))
Но сложно будет потратить деньги, если сайт о продукте не открывается))

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

Цены софта у всех примерно одинаковые, плюс объемы позволяют работать с вендорами напрямую.
Ну, если таких сайтов будет немного, то это одно. Но если это будет всеобщей тенденцией, то это немного другое. Думаю, что это не единственная компания, где ИБ одобряют конкретные версии конкретного софта, а часть софта еще и сертификацию проходит.
Думаю, что это не единственная компания, где ИБ одобряют конкретные версии конкретного софта, а часть софта еще и сертификацию проходит.

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

Что-то мне подсказывает, что если в компании все плохо с АХЧ и сотрудники сидят на устаревшем софте, то и покупательская способность у такой компании не очень.

Я бы не был так категоричен. Сам работал в очень большой и богатой компании, которая разрабатывала UI под IE6 для еще более богатых компаний.


У них там логика такая: у нас миллионы рабочих мест с IE6. Все вроде работает. Перевести на что-то новое все рабочие места — это гигантские затраты. На обновление железа, софта, зарплаты админов, которые это сделают, переобучение сотрудников, которые умеют лишь тыкать в те кнопки, которым их научили. На переписывание и тестирование софта.


В итоге, да, десятилетиями пользуются устаревшими технологиями.


Это еще что, в США (возможно, в Европе тоже), скажем, до сих пор во многих местах КОБОЛ используется. Переписать сложно и дорого, по их расчетам переписывание обойдется дороже, чем платить за поддержку пенсионерам, пишущим на КОБОЛ.


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

Я работал в большой компании (60к+ человек) и мы переходили с Win XP на Win 7. Вот были времена… Работа по 12 часов, бесконечные тренинги. В общем было весело. А потом еще и на Google Chrome c IE и на Gmail c Outlook. Все это стоит для больших компании Огромных денег. И это для них никак не окупиться. Нужно что бы в топ менеджменте были люди которые понимали, что мир не стоит на месте и людям нужны современные инструменты. Хирург же не будет оперировать ржавым скальпелем. Так и современного работнику нужны новые и хорошие инструменты, что бы эффективно выполнять свою работу. Если руководство компании этого не понимает, то это полностью их просчет.

Github официально не поддерживает IE. При заходе с этого браузера показывается вот такая плашка.

Учитывая недавний переход под крыло Microsoft все может сильно поменяться…

Только если в сторону ускорения отказа от IE. Сам Майкрософт активно призывает пользователей переезжать на новый Edge.

НЛО прилетело и опубликовало эту надпись здесь
То, что активно призывает — это понятно. Но, обычно, Microsoft крайне трепетно относится к обратной совместимости.
Но это все не более чем гадание на кофейной гуще — посмотрим, как оно будет.
Уже минимум год как пытаются избавится они от обратной совместимости и идут в сторону отбрасывание всего старого как в винде так и в браузере. Они сами уже хотят избавится от ослика

WinApi хоть оставят?

НЛО прилетело и опубликовало эту надпись здесь
Оставят. Но по предварительным планам если я правильно помню они собираются убрать эксплорер и на его место поставить другую оболчку и в ней уже WinAPI будет эмулироваться а не запускаться на прямую. НО тут резонно. Так как слишком много кода на нем
Хм… случайно не для этого ли был куплен гитхаб? :)
НЛО прилетело и опубликовало эту надпись здесь
Угу, даже слишком. Про покупку MS в комментариях точно не вспомнят.
Про покупку MS

Так MS и вовсе не при делах ведь — судя из текста сказано, что миграция заняла не один год. А гитхаб купили условно «вчера».
А вот если бы гитхаб прилег на денек, тут же бы вспомнили о Майкрософте, причем многие сделали бы это на полном серьезе
Ради справедливости — прилечь на денек можно в следствии «чего-угодно» и это явно можно сделать куда быстрее, чем за годы. Улавливаете разницу?
Вспомнят, когда они все начнут переписывать на TypeScript.
TypeScript это прошлый век, будущее за blazor
Вопросы в FAQ у Blazor один лучше другого:
«Is this Silverlight all over again?», «Does Blazor use XAML?», "...does Blazor work in IE?"

Отличное "будущее", по ссылке кроме "Loading..." и горы ошибок в консоли ни черта нет. Wait… Oh, shi~~!!!11

НЛО прилетело и опубликовало эту надпись здесь

Вы хотите сказать, что в WASM коде, который генерирует это решение вшит интерпретатор/вирт.машина .NET? Но зачем? Можно же сразу в WASM-е всё организовать?! Я ничего не понимаю в .Net, но, судя по названиям библиотек, — это скорее штатная библиотека, а не вирт. машина подтягивается. Или я не прав?

НЛО прилетело и опубликовало эту надпись здесь
Как «зачем»? А что еще можно сделать с байт-кодом кроме как виртуальную машину для него?
НЛО прилетело и опубликовало эту надпись здесь
И что? Байт-код WASM слишком низкоуровневый.

И поэтому нужно больше рантаймов богу рантайма?

И потому пока что нет другого способа использовать IL в WASM.
JQuery не фреймворк, а библиотека. «Избавляться» от нее можно строчка за строчкой. Почему переход с нее на чистый javascript занял годы, непонятно, и вызывает удивление.
Как минимум, потому что меняя код строчка за строчкой надо постоянно запускать тесты и смотреть, чтобы ничего не сломалось
Да, это годы…

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

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

Больше человек в разработке => сложнее задача миграции. Разве не так?
Если бы речь шла про одну команду из 3-5 человек, то, на мой взгляд, задача была бы выполнима в разы быстрее.

Как минимум, потому что меняя код строчка за строчкой надо постоянно запускать тесты и смотреть, чтобы ничего не сломалось

Да ладно, несложно весь код к "без-jquery" преобразовать автоматически, с гарантированным сохранением семантики. И никаких тестов не потребуется.

Я почему-то уверен, что подобные заявления делают люди, которые на самом деле на практике никогда этого не делали.
Я почему-то уверен, что подобные заявления делают люди, которые на самом деле на практике никогда этого не делали.

Глупость говорите. Очевидно, что можно заинлайнить все вызовы в пределе.

Вы в курсе, например, что поведение $(".some-class") не соответствует поведению document.querySelectorAll? Они похожи по своей сути, но и отличаются в ряде нюансов. И это не единственный пример.
Автоматически эту конвертацию сделать невозможно, если нас интересует осмысленный результат.
Заинлайнить тоже проблематично, потому что каждый метод jQ это не самостоятельная функция, там под капотом много перекресных вызовов. Инлайнить все уровни вложенности? Успехов — получится монструозное нечто объемом раз в 10 больше, чем человеческий код (в чем тогда смысл?).
Вы в курсе, например, что поведение $(".some-class") не соответствует поведению document.querySelectorAll?

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


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

Это утверждение эквивалентно тому, что ф-и jquery невозможно реализовать. Что, очевидно, неправда.


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


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

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

Если раньше функции jQuery поддерживала команда jQuery, то в данном случае — это просто имплементация jQuery API силами Github, а собственно и дальнейшее сопровождение, тестирование и поддержка кода отвечающего за этот API. Замена кода на jQuery на код эксплуатирующий нативные методы браузера — значит переложить ответственность за сопровождение инструментов на плечи разработчиков браузера.

В чем теперь проблема определить данную ф-ю в jquery в соответствии с замененным кодом и заинлайнить?
Тем, что функции jQ под капотом вызывают другие функции, а те третьи и так далее?
Нельзя «заменить код» внутри функций, сохранив полностью архитектуру jQ, потому что это опять получится jQ. Переписывая на ванильный JS, придется менять и архитектуру тоже, а это в автоматическом режиме не делается.

jQuery.Deferred != Promise, jQuery.ajax() != window.fetch(), jQuery.find() != document.querySelector(). Семантику можно сохранить ценой застрявания на старом API, на необходимости мейнтейнить jQuery-совместимую библиотеку. Современный браузер новый API покрывает кейсы jQuery, причем есть гарантия что этот API мейнтейнится разработчиками браузеров, совместим с большим количеством браузеров и использует общепринятый стандарт, где дотошно описано поведение API. Это может исключить подобные ситуации: https://github.com/jquery/jquery/issues/2824

Мигрировать крупный проект на новую версию jQuery достаточно «весело», что уж говорить про отказ от него. Это ж JS, здесь ошибки часто всплывают совсем не там, где возникают на самом деле и ловить их можно достаточно долго, скрупулёзно тестируя все.
На jquery есть множество плагинов, которые отлично делают свою работу, избавляясь от которых надо найти им замену, как минимум нехуже, в идеале такие же, возможно, даже написать свои реализации.
Если это было не главным направлением, тогда и время могло выделяться соответственно.

Добавлю описание для моего предыдущего комментария, потому что ссылки без описания вводят людей в замешательство, простите был не внимателен к вам. Что я хотел этим сказать: это вопрос времени, но уже есть достаточно большое количество компонентов частично или полностью покрывающие функциональность jQuery плагонов, которые можно интегрировать в существующий проект медленно переводя проект на веб-компоненты. Одно из хороших свойств веб-компонентов — возможность использовать их в паре с jQuery/Angular/React/Vue.

я не нашел статьи «как переделать jquery plugin в webcomponent». и мне кажется я понимаю почему — если переделывать, то так чтобы оставалась компонента чистого js, как ядро, и тогда можно было бы и jquery и webcomponent поддерживать, как обертки над ядром. И если в случае jquery такое ядро «чистого js» вытащить просто, webcomponent — это придется убивать template — т.е. его динамически создавать (не вижу другого способа, может слепота куринья) — что ну совсем «против течения».

я может в плену неправильных идей, но этот вопрос меня завел в тупик: как создавать компоненты так чтобы можно было на одном ядре (общем коде) поддерживать и jquery и webcomponent?
Я перечитал ваш комментарий, но так и не понял вот этого: «webcomponent — это придется убивать template — т.е. его динамически создавать».
Вот template github.com/webcomponents/hello-world-element/blob/master/hello-world.html#L2-L4, но допустим он много сложнее.

Я хочу такой же компонент поддерживать и как jquery и как wc, т.е. вытащить как можно больше общего в чистый js. В чистом js я веcь html что внутри темплейта — могу генерировать динамически. Теперь у меня два куска кода делающие тоже самое. Надо идти дальше и ставить вопрос: как избежать поддержки и «сгенерированного динамически html» и html заданного template, как оставить что-то одно? Генерировать содержание template динамически? Это точно возможно, работает же wc там где нет броузерной поддержки template. Но что это будет? wc без template — как и не wc вовсе.

А вообще я бы просто хотел увидеть статью на тему как мигировать jquery plugin в web component. И как поддерживать один и тот же компонент в двух вариантах. И очень удивлен что такой статьи нет.

Но ведь вы собрались с jquery на webcomponents переносить, а не наоборот. Откуда у вас возьмется template в плагине jquery?


Это же фича webcomponents, а не нечто обязательное. Его можно генерировать динамически так же как это jquery-плагины делают.


А вообще я бы просто хотел увидеть статью на тему как мигировать jquery plugin в web component.

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

не «переносить» а портировать, т.е. поддерживать обе версии.

да, у меня ступор от непонимания того на сколько template «фича» а не нечто обязательное. но спасибо, немного ободрили.

функционально jquery plugin консервативен 1) инициализация параметрами 2) генерация хтмл 3) обработка событий внутри компоненты 4) проталкивание событий вовне компонеты 5) вызов методов (в том числе dispose);

Я вижу для себя одну очень полезную фичу WebComponents — это инициализация веб-компонента автоматически при появлении тега в DOM. Пример: у нас есть задача в старом приложении на jQuery добавить тултипы (подсказки, появляющиеся при наведении на ссылку). Можно сделать jQuery плагин, который нужно будет пере-инициализировать на каком то куске DOM при обновлении в нем контента, либо можно сделать веб-компонент <my-tooltip text="My text">...</my-tooltip>, который будет инициализироваться самостоятельно и перестраиваться при изменениях, что очень удобно. И я думаю что на данном этапе, это можно использовать, даже с полифилами, не дожидаясь минорных фич.

а какие конкретно полифилы имеете ввиду? меня множественное число озадачило. в единственном я бы понял что речть идет о github.com/webcomponents/webcomponentsjs
и на сколько я понимаю его грузить превентивно, потому что если условно то это асинхрон, а нельзя.

и какие минорные фичи имеются ввиду?

https://www.webcomponents.org/polyfills/ — здесь список полифилов с развернутыми пояснениями. Для меня самая значимая фича — это возможность инициализировать код обслуживающий DOM-элемент, добавлением тега на страницу (можно легко интегрировать новые компоненты в legacy код — почти не вникая в механизм обновления контента). Другие фичи — это import компонентов через <link rel="import" href="myfile.html">, <template></template>.

Спасибо большое.

Еще один вопросик, а вы бы приняли подобное решение (механическая копия jquery):

<select multiple id="mySelect" >
   <option > ..  </option>
   <option > ..  </option>
</select>
<custom-multiselect for="mySelect" />


Мне кажется оно проще и прозрачней чем создание «скрытого» селекта внутри (нужного для формы).

Кастомный мульти-селект я бы делал в виде тега-враппера (http://jsfiddle.net/jmas/fod2vu4m/4/). Далее в шаблонах обернул бы необходимые <select> в <multi-select>, сам селект скрыл бы, а показал аналогичный интерфейс. Операции бы дублировал на оригинальном <select>.


Допустим новый <multi-select> используется в форме которая полностью перегружает свой контент через через ajax. Такой мульти-селект будет инициализироваться автоматически, а его поведение (с точки зрения старого кода) будет соответствовать стандартному селекту.

Не уверен что возможно сделать «поведение соответсующее стандартному селекту» (т.е. все методы и события обрабатывать/тригерить) — а если возможно то кода море. Лучший код — который не написан. П.С. предполагаю, что внутренний селект скрыт шадоу домом (хотя опять: не понимаю на сколько это обязательно).
проверил по вашему jsfiddle — нет не скрыто шадоу домом.

все прекрасно. но не понятно а какие соглашения вообще есть по использованию шадоу дома?

С моей точки зрения — совершенно не обязательно. Shadow DOM иммет свои преимущества — их лучше дополнительно изучить и сделать для себя вывод: когда Shadow DOM нужен.


т.е. все методы и события обрабатывать/тригерить

На самом деле их всего два: change, input, а базовый которого в большинстве случаев достаточно, на который все обычно подписываются — это change.

Демка по вашей ссылке устарела, последний коммит туда был 3 года назад.
Вот актуальное описание веб-компонентов.


Переиспользуемый веб/jquery компонент можно сделать вот так


// переиспользуемый код
function vanillaComponent(element, options) {
    element.innerHTML = `Hello ${options.name}!`;
}

// Web component
class MyComponent extends HTMLElement {
  connectedCallback() {
    vanillaComponent(this, {
      name: this.getAttribute('name')
    });
  }
}
customElements.define('my-component', MyComponent);

// Jquery
$.fn.myComponent = function(options) {
  this.each(function() {
    vanillaComponent(this, $(this).data());
  });
}

$(document).ready(function() {
  $('.my-component').myComponent();
});

Рабочее демо: http://jsfiddle.net/gc1rynmf/9/

СПАСИБО! то что нужно.

Да, функция document.registerElement()устарела, сейчас рекомендуется использовать window.customElements.define(). Спасибо, что поправили.

Скорее всего считают с момента когда в новом коде запретили использовать jq, потом со временем большая часть кода переписывалась в результате обычной деятельности сайта, и в конце решили что вот пора бы окончательно перейти.
Я считаю, шаг очень правильный. Сегодня стало нормой правил жрать трафик пользователя, нагружать его загрузкой кучей библиотек и совсем не заботиться о быстродействии сайта…
Минифицированная и гзипнутая jquery весит 30кб. Это разве много? Даже для мобильного интернета это крохи. В отличие от всяких ангуляров, которые весят даже в сжатом виде по 150 кб, в пять раз больше (вот тут есть сравнение)
Даже без этих сравнений jquery пропадает в многомегабайтном море данных, в котором любой считающий себя современным сайт топит каждый открывший его браузер.
medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
Если в двух словах: стоимость JS в пересчете на 1 кб гораздо выше, чем у других данных, например, картинок. И дело там, главным образом, не в интернете.
Ради интереса.
А что означает галочка Disable cache?
Гитхаб нестандартный сайт, действительно заботящийся об оптимизации своего кода. В его случае уход с jquery вполне имел смысл.
Для 99% других сайтов это бессмысленно и весьма затратно — даже у Гитхаба ушли ГОДЫ!!!

Все, все сидят на игле jquery…
Я это отлично понимаю. Как по мне, в большинстве случаев достаточно jquery, тем более, что его можно закешировать. А вот когда на каких-то одностраничниках js'а на 500 кб — это перебор.
Насколько я помню, основной «минус» jquery не размер, а большой overhead при выполнении селекторных запросов. Думаю, это основной стимул уйти с нее.
Насколько я знаю, библиотеку jQuery можно собрать без подсистемы селекторных запросов (Sizzle).
Глаза закатываются от подобных сравнений. А где упоминание Ivy Compiler?
www.youtube.com/watch?v=dIxknqPOWms 44:25 => ToDo App 12.2 KB
herringtondarkholme.github.io/2018/02/19/angular-ivy => Hello World 3.2 KB

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

Интересно, чем было бы плохо взять preact \ choo \ hyperapp \ etc? Они очень мало весят, но, по моему, декларативный стиль описания намного упрощает код.
Так, кстати, поступили с главной страницей мобильной версии Яндекса (там preact) — а в их случае скорость еще важнее, чем для GH.
Только выпилить jQuery потребовались годы. Чтобы переписать все на фреймворк потребуется слишком большое количество времени + появится зависимость от стороннего кода, от которой стараются уйти
Все логично. jQuery появилась как ответ на неудобство написания кода на Vanilla JS, но годы идут, API и тулинг улучшаются, поэтому необходимость в прослойке становится менее актуальна.

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

Сейчас не так уж сложно найти vanilla.js UI компоненты. Например, вот форк bootstrap, не требующий jQuery. А вот PR в официальный репо, убирающий зависимость от jQuery в следующем мажорном релизе.

помимо самой jQuery придется отказаться и ото всех библиотек, которые ее используют.
Вот именно. Свой код переделать — ладно, а вот аналога по функциональности lightGallery ни в jquery ни в js, например, я не знаю. Безвыходная ситуация.
photoswipe довольно неплох. Прада он не умеет делать списки превью, вроде бы, но я их все равно обычно сам делаю.
Ну и для динамического размера фото надо немного дописать кода. А визуально очень похоже.
Из-за списка превью я его и выбрал. В остальном все лайтбоксы похожи.
Не неудобство, а разную работу одного и того же кода в разных браузерах, поэтому придумали jq, который внутри себя сам решал что за браузер и что исполнять, сейчас проблема значительно менее выражена чем раньше, отсюда отказ.
Это вполне входит в понятие «неудобство».
Интересно, а тысячи строк «document.querySelectorAll» в коде, не будут занимать больше, чем 30кб jQuery плюс те же тысячи строк "$"? :)

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

Если у вас на страницу грузится файл с тысячей вызовов querySelectorAll, то вы явно что-то делаете не так. Возьмите фреймворк.

Я тоже про это думал. А если делать свои shortcut'ы для вызовов частоупотребимых методов, то получится свой jQuery.
А какие у вас ещё настолько «частоупотребимые» кроме querySelector и querySelectorAll?
С полученными из querySelector* элементами надо дальше что-то делать — скрывать/показывать, менять свойства и тому подобное.
Это вы про .attr("attr-name", "attr-value") вместо нативного .attributeName = "attributeValue"?
Условно говоря да, но jQuery автоматически применяет действие ко всем найденным элементам, не заставляя писать циклы.
Ну, с .forEach() и лямбдами разница в символах выходит не такой уж большой.
.attr("name", "value");
vs
.forEach(x => x.name = "value")'
Зато не нужно на каждое действие запоминать отдельный jQuery-метод со своим синтаксисом. Которые ещё и делают разное в зависимости от количества и типа параметров и может чейниться, а могут и нет, как тот же .attr().
Кстати, эти возвращающие значение методы и синтаксис, которым проще выбрать всё, чем один элемент, ещё и феерически поощряют говнокод с выборками и обработкой по миллиону элементов вместо одного первого.

Да, только NodeList.forEach не реализован даже в последнем IE, как и стрелочные функции, поэтому придется обмазываться полифиллами и использовать транспилятор, что в сумме выглядит ничуть не лучше решения от jQuery.

На всякий случай напомню, что статья про Github, который IE официально не поддерживает.
Вы правы, но эта ветка комментариев началась с мысли о том, что подход гитхаба не подходит для большинства других сайтов.
Ясно, давайте так: в проектах с современными браузерными требованиями vanilla.js будет достаточно, а для поддержки IE, так уж и быть, понадобятся хелперы.
Так полифиллы (как и рантайм-транспиляторы) можно подключать условно — при определении устаревшего браузера. В итоге, большинство пользователей (с автообновляющимися браузерами) получат выигрыш.
А теперь сделайте шаг назад и посмотрите на ситуацию глазами непредвзятого наблюдателя: вместо одной библиотечки на ~30 кб (которая уже скачана у 99% пользователей, если использовать CDN) вы предлагаете использовать целую систему из детектора браузеров, вороха полифиллов, транспилятора и сборщика. Вся ответственность за обновление и обеспечение совместной работы этих компонентов теперь на вас. Для многих сайтов эти усилия не стоят затрат.
Да забудьте про CDN! Недавние события наглядно всем продемонстрировали, что на чужие CDN надеяться нельзя.
Что за «недавние события»? Можно ссылку?
Ну, например, блокировки Телеграмма.
Если ваш сайт ориентирован на зарубежную аудиторию — вас эта проблема не коснется. Если на отечественную — есть CDN от MailRu / Yandex. Не вижу смысла отказываться от хороших технических решений из-за паранойи.

А если, как и положено нормальному сайту, на весь мир?

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

Или просто все зависимости раздаются с самого сайта.

И тогда вы больше платите за трафик, а ваши страницы грузятся дольше.
НЛО прилетело и опубликовало эту надпись здесь

Ну экономия на спичках же.


Особенно, если учесть, что jQuery весит 30 Кб, а полифил для Array.from, чтобы удобно итерироваться по NodeList, весит 1кб.

> Да забудьте про CDN! Недавние события наглядно всем продемонстрировали, что на чужие CDN надеяться нельзя.

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

Но вероятность того что РКН забанит хотя бы один из серверов выше чем вероятность бана только одного сервера.

Но вероятность того что РКН забанит хотя бы один из серверов выше чем вероятность бана только одного сервера.

Не понял, что вы сейчас имели ввиду.

Есть два сервера. Сервер А — ваш сервер, на котором сайт. Сервер Б — это сервер гугла, где лежит jquery.

Вероятность бана А или Б выше чем вероятность бана А.

Ну, так, очевидно, верно :)

систему из детектора браузеров, вороха полифиллов, транспилятора и сборщика.
Только не «и», а «или». Зачем нужны полифиллы, если будет транспилятор? И зачем нужны полифиллы и транспиляторы, если детектор их не подключит (а это большинство случаев)? Ну, и сборщик тут вообще непонятно, откуда взялся — я же пишу про рантайм.
Кроме того, при использовании этой библиотеки весь ваш код завязан на неё, а в «моём» варианте всю эту «обвязку» можно выкинуть, и в 93%+ случаев всё будет работать и так — даже на десктопе у IE всего 6.97%, а среди мобильных браузеров там и вообще меньше одного процента.
Зачем нужны полифиллы, если будет транспилятор?
Потому что это разные вещи — транспилятор поддерживает синтаксис, а полифиллы — функционал. Хотя Babel поддерживает полифиллы в качестве плагина, у вас в итоге все равно будет и то, и другое.
я же пишу про рантайм
Я искренне надеялся, что это была опечатка. Вы на полном серьезе предлагаете и без того обиженным пользователям IE подсунуть клиентский транспилятор?
Ну, вы же предлагаете из-за них обидеть всех остальных.
Много их.
1. обход дома по вертикали и горизонтали (всякие parents, siblings, closest, matches — нативные варианты этих функций либо не очень удобны, либо до сих пор некроссбраузерны и приходится писать обертки);
2. поиск-фильтрация-отбор среди найденного;
3. создать-удалить-добавить-изъять-переместить-завернуть-развернуть;
4. манипуляция классами-атрибутами-стилями;
5. события повесить-убрать-послушать-вызвать;
6. работа с координатами и размерами…
Ну и так далее. Это я перечислил только самое базовое, без углубления в дебри.

Вообще jQ за все годы оптимизирована очень хорошо и для своего объема функциональности имеет более чем адекватный размер. Существенно его снизить можно только отказываясь от каких-то фишек, что и пытаются делать разные альтернативные библиотеки.
Я лично писал свой велосипед, по объему получилось в 5-6 раз меньше jQ, но у меня было только самое-самое необходимое. Чудес не бывает.
Я как-то пробовал подключать не собранную версию jquery, а отдельные модули из исходников. Получалось интересно, но жутко не хватало нормальных тайпингов (как в rx.js сделано, например).
поиск-фильтрация-отбор среди найденного;
Можно пример? По моему опыту, фильтры можно либо сразу запихать в селектор, либо там всё равно потом передаётся функция, которую можно и в .forEach() на NodeList дёргать, а можно NodeList и в массив сконвертировать в 5 символов через spread operator, если на свежие версии браузеров или babel ориентироваться, и тогда прямо .filter() по массиву.
создать-удалить-добавить-изъять-переместить-завернуть-развернуть;
На мой вкус, из этого только «создать» пишется многословно, потому что нужно писать document.createElement, а потом содержимое запихивать.
манипуляция классами-атрибутами-стилями;
А что тут настолько проще, чем в стандарте? ClassList есть, атрибуты прямо как свойства доступны…

Кратко: кроссбраузерность, чейнинг, пакетная обработка.

Библиотеки типа jQuery рассчитаны не только на одностраничники на реактах, но и «просто сайты». Откуда вытекают два нюанса:
а) IE11 там нужен, как бы кому ни хотелось обратного.
б) Разработчики/владельцы «просто сайтов» любят готовые решения, без этих ваших бабелей, чтоб можно было продрубить и использовать.

Поэтому там не катят NodeList.forEach, Element.remove, closest, matches, append, prepend и тд (причем часть этого не работает даже в Edge, если память не подводит).
Еще под капотом выясняется, что часто методов возвращает Element, а часть Node; аналогично с NodeList/HTMLCollection.
Ещё например, у IE всплывает много нюансов при работе с SVG-узлами.
Да, можно обвеситься парой десятков полифиллов, но зачем, если проще взять одну библиотеку, которая заодно и удобство даст?

По чейнингу и пакетной обработке. Ну те же стили почти всегда задаются по несколько штук сразу — я могу вызвать метод один раз, передав ему объект. Классы очень часто нужно добавить один и убрать другой — classList придется вызывать дважды. SVG-атрибуты тоже специфику имеют.
gzip прекрасно сожмет тысячи одинаковых строк любой длины.
борьба с ветряными мельницами заняла годы.
учитывая, что каждый второй сайт сожержит jQuery, то вероятнее всего эти огромные 30кб будут уже закешированы в браузере или на сервере провайдера интернет.
Теперь новая проблема — а что делать со сьекономленной на загрузке 0.1 секунды времени?
сходить на сайт с jQuery посмотреть новости или погоду?
Представьте себе трафик GitHub, отнимите от каждого запроса 1Кб и посчитайте разницу до/после. Это самый очевидный плюс, если отбросить сравнение скорости работы VanillaJS и jQuery

И какой трафик? Миллион посетителей в день? (Вряд ли). Т.е. 1Гб экономии в день, большая часть из которой на самом деле закеширована?


"Самый очевидный плюс" наверняка последний в списке плюсов для перехода.

www.similarweb.com/website/github.com#overview
538 млн. за июнь

Понятно, что кэш и все такое, но мне кажется экономия все же больше 1Гб в день.

Да и трафик там далеко не основная цель. Я лишь один из вариантов привел.

Спасибо за цифры.


Да и трафик там далеко не основная цель.

Ну да, я о том же.

не понимаю в чем видите проблему.
библиотека легко подключается с любого популярного CDN ресурса, легко достается с ближайшего кеша промежуточных серверов при первом обращении и из локального кеша браузера при последующих.
трафик будет между клиентом и CDN узлом. к «трафик GitHub» вообще никакого отношения не будет иметь.
в трафике клиента этот обьем будет ничтожно малым по сравнению с просмотром котика, новым роликом с ютюба или прослушиванием муз. трека.

Выше уже писал: «Да и трафик там далеко не основная цель. Я лишь один из вариантов привел.»

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

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А сейчас умножается на ещё 2 — полная и slim. Но справедливости ради, сейчас развитие jQuery не такое сумасшедшее, как несколько лет назад, когда номера версий перещелкивались быстрее, чем сегодня у браузеров. Продукт зрелый и законсервировался стабилизировался.
а также ради возможности использовать библиотеку Flow.JS для статического анализа типов.

Эх, на какие только жертвы люди не идут, чтобы ТС не юзать.

ТС пользователи принесли в жертву Babel. Нельзя служить обеим богам.

Вроде, это ортогональные вещи.

Вот контрпример: babeljs.io/docs/en/next/babel-plugin-transform-typescript

Typescript запускается только для проверки типов, с флагом --no-emit, а сборка происходит с Бабелем. Такой подход позволяет использовать кастомные babel-плагины для более оптимальной сборки, например, вырезания debug-информации
es8 со всеми babel plugin proposal'ами как язык не подмножество ts. вы предлагаете выбрать программирование на ts, а бабелом лишь вырезать куски кода. Да код между условным комментариями можно вырезать и без бабела. бабел нужен для другого.
Babel != фичи ESnext. Babel это удобный и мощный инструмент процессинга Javascript и его диалектов. Не все можно удобно завернуть в `if(process.env.NODE_ENV !== 'production') {}`. Здесь как раз Babel и приходит на помощь.
а еще можно просто в package.json указать babel и где-то его в тестах использовать — тоже типа бабел. но если вы настаиваете, то переформулирую тезис так: «пользователи TS приносят в жертву фичи ESNext»

С таким утверждением соглашусь. Однако и здесь происходят изменения. Babel убирает stage-0 пресет, намеренно усложняя использование нестандартизованных (пока) фич языка.

а в чем усложнение? я и раньше Stage Presets не использовал. явное перечисление плагинов = самодокументация. я не пикируюсь — статья написана прыгающим умом — слишком много вещей в голове держать надо. может что упустил.

Раньше можно было включить весь набор экпериментальных фич одной строкой {"presets": ["stage-0"]}. Теперь нужно подключать фичи явно. И при этом отдавать себе отчет в их нестабильности (альфа-версия стандарта, так сказать).

Вполне оправдано для Гитхаба, да и время как нельзя подходящее (сам уже пару лет не использую jQuery в новых проектах). Но без фреймворка будет туговато, так что я бы ожидал через годик какой-нибудь github-js-framework-light, который они будут вынуждены изобрести
Так vanilla pjax же…
ajax и pushState это далеко не все технологии, которые нужны для создания даже среднего сайта

Господи, в мире js все меняется быстрее чем этим заполняется stackoverflow. Теперь еще shadow dom и полифиллы… Ушел гуглить что это такое

НЛО прилетело и опубликовало эту надпись здесь
Как вы считаете, есть ли для этого выгода бизнесу? Прямая или косвенная.
Удовлетворенность пользователей. Даже 1 сэкономленная секунда это существенно для сайта, на который ходишь каждый день по многу раз.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории