Comments 178
Да это же мечта перфекциониста!
А у нас (30к рабочих мест, маленькая телеком компания) это единственный официально поддерживаемый браузер.
Непонятно, почему проблемы маразма вашего руководства должны волновать кого-либо вне вашей компании.
Терпимее надо быть, терпимее — не у всех блид эдж версия всего и вся, корка ай7, 32 ГБ ОЗУ и гигабитный интернет.
Точно так же говорили работники банковского сектора, когда массово избавлялись от ie6, у них были даже посерьезнее причины, т.к. много их софта было написано на связке нэтив и ie6. К счастью, их не стали слушать. Вам же не предлагают апгрейд, вам просто предлагают сменить браузер.
А еще сменить железо, оператора сотовой связи и его никакое покрытие и, наконец, страну. Ваша точка зрения мне понятна.
Во многих местах люди борятся за конверсию и даже 1% конверсии является весьма значимым значением.
Все ведь зависит от соотношения затрат и прибыли в итоге. Так уж вышло, что обычно выгоднее сделать более круглую кнопочку, чтобы привлечь внимание обладателя ай7 корки с 32гб озу, чем плодить костыли ради маргиналов с ие. Nothing personal, it's just business.
Эти маргиналы тратят сотни тысяч долларов в год на софт и железо, но ок, пусть будут для вас маргиналами.
Кто тратит? Те самые люди, которые сидят за компуктерами с протухшим 10 лет назад ИЕ потом в этом ИЕ заходят на мой сайт чтобы потратить свои личные деньги?
Но сложно будет потратить деньги, если сайт о продукте не открывается))
Но сложно будет потратить деньги, если сайт о продукте не открывается))
И сколько случайных сайтов из сотни в среднем предлагают тот самый продукт, который потом купит ваша компания?
Ну и если компания в итоге потеряет деньги из-за того, что дороже купила что-то, что могла купить дешевле, но не купила, потому что у закупа "сайт не открылся", то закуп в рыло и получит. Так что я не думаю что у вас работают дебилы, которые не открывают в таком случае сайт из-под другого браузера.
Ну, если таких сайтов будет немного, то это одно. Но если это будет всеобщей тенденцией, то это немного другое. Думаю, что это не единственная компания, где ИБ одобряют конкретные версии конкретного софта, а часть софта еще и сертификацию проходит.
Я бы не был так категоричен. Сам работал в очень большой и богатой компании, которая разрабатывала UI под IE6 для еще более богатых компаний.
У них там логика такая: у нас миллионы рабочих мест с IE6. Все вроде работает. Перевести на что-то новое все рабочие места — это гигантские затраты. На обновление железа, софта, зарплаты админов, которые это сделают, переобучение сотрудников, которые умеют лишь тыкать в те кнопки, которым их научили. На переписывание и тестирование софта.
В итоге, да, десятилетиями пользуются устаревшими технологиями.
Это еще что, в США (возможно, в Европе тоже), скажем, до сих пор во многих местах КОБОЛ используется. Переписать сложно и дорого, по их расчетам переписывание обойдется дороже, чем платить за поддержку пенсионерам, пишущим на КОБОЛ.
У нас же, например, и труд дешевле (то есть переписать не так сложно), и такого жесткого легаси нет (хотя местами есть в малых масштабах, я лично видел когда-то древние PDP, которые годами не выключались, и на которых гонялся какой-то очень важный для предприятия софт).
Github официально не поддерживает IE. При заходе с этого браузера показывается вот такая плашка.
Только если в сторону ускорения отказа от IE. Сам Майкрософт активно призывает пользователей переезжать на новый Edge.
Но это все не более чем гадание на кофейной гуще — посмотрим, как оно будет.
Про покупку MS
Так MS и вовсе не при делах ведь — судя из текста сказано, что миграция заняла не один год. А гитхаб купили условно «вчера».
«Is this Silverlight all over again?», «Does Blazor use XAML?», "...does Blazor work in IE?"
Отличное "будущее", по ссылке кроме "Loading..." и горы ошибок в консоли ни черта нет. Wait… Oh, shi~~!!!11
Вы хотите сказать, что в WASM коде, который генерирует это решение вшит интерпретатор/вирт.машина .NET? Но зачем? Можно же сразу в WASM-е всё организовать?! Я ничего не понимаю в .Net, но, судя по названиям библиотек, — это скорее штатная библиотека, а не вирт. машина подтягивается. Или я не прав?
Годы. Так и проходят миграции больших кодовых баз, особенно если команд разработки больше одной. Надо обкладываться тестами, осторожно мигрировать и некий общий план действий между командами согласовывать и выдерживать.
Задача непростая. Может статься, это одна из наиболее сложных задач в программировании
Как минимум, потому что меняя код строчка за строчкой надо постоянно запускать тесты и смотреть, чтобы ничего не сломалось
Да ладно, несложно весь код к "без-jquery" преобразовать автоматически, с гарантированным сохранением семантики. И никаких тестов не потребуется.
Я почему-то уверен, что подобные заявления делают люди, которые на самом деле на практике никогда этого не делали.
Глупость говорите. Очевидно, что можно заинлайнить все вызовы в пределе.
Автоматически эту конвертацию сделать невозможно, если нас интересует осмысленный результат.
Заинлайнить тоже проблематично, потому что каждый метод 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 плагонов, которые можно интегрировать в существующий проект медленно переводя проект на веб-компоненты. Одно из хороших свойств веб-компонентов — возможность использовать их в паре с jQuery/Angular/React/Vue.
я может в плену неправильных идей, но этот вопрос меня завел в тупик: как создавать компоненты так чтобы можно было на одном ядре (общем коде) поддерживать и jquery и webcomponent?
Я хочу такой же компонент поддерживать и как 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>, который будет инициализироваться самостоятельно и перестраиваться при изменениях, что очень удобно. И я думаю что на данном этапе, это можно использовать, даже с полифилами, не дожидаясь минорных фич.
и на сколько я понимаю его грузить превентивно, потому что если условно то это асинхрон, а нельзя.
и какие минорные фичи имеются ввиду?
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. Такой мульти-селект будет инициализироваться автоматически, а его поведение (с точки зрения старого кода) будет соответствовать стандартному селекту.
все прекрасно. но не понятно а какие соглашения вообще есть по использованию шадоу дома?
С моей точки зрения — совершенно не обязательно. 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/
Если в двух словах: стоимость JS в пересчете на 1 кб гораздо выше, чем у других данных, например, картинок. И дело там, главным образом, не в интернете.
А что означает галочка Disable cache?
Для 99% других сайтов это бессмысленно и весьма затратно — даже у Гитхаба ушли ГОДЫ!!!
Все, все сидят на игле jquery…
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) — а в их случае скорость еще важнее, чем для GH.
Впрочем, для рядового разработчика без бюджетов гитхаба это все еще непосильный путь: помимо самой jQuery придется отказаться и ото всех библиотек, которые ее используют.
Сейчас не так уж сложно найти vanilla.js UI компоненты. Например, вот форк bootstrap, не требующий jQuery. А вот PR в официальный репо, убирающий зависимость от jQuery в следующем мажорном релизе.
помимо самой jQuery придется отказаться и ото всех библиотек, которые ее используют.Вот именно. Свой код переделать — ладно, а вот аналога по функциональности lightGallery ни в jquery ни в js, например, я не знаю. Безвыходная ситуация.
Ведь jQuery, или какой еще более легкий аналог, вполне можно рассматривать как более альтернативный компактный и приятный синтаксис, для длинного и неудобного встроенного. Семантика ведь там почти такая же.
Если у вас на страницу грузится файл с тысячей вызовов querySelectorAll, то вы явно что-то делаете не так. Возьмите фреймворк.
querySelector и querySelectorAll?querySelector* элементами надо дальше что-то делать — скрывать/показывать, менять свойства и тому подобное..attr("attr-name", "attr-value") вместо нативного .attributeName = "attributeValue"?.forEach() и лямбдами разница в символах выходит не такой уж большой..attr("name", "value");.forEach(x => x.name = "value")'.attr().Кстати, эти возвращающие значение методы и синтаксис, которым проще выбрать всё, чем один элемент, ещё и феерически поощряют говнокод с выборками и обработкой по миллиону элементов вместо одного первого.
Да, только NodeList.forEach не реализован даже в последнем IE, как и стрелочные функции, поэтому придется обмазываться полифиллами и использовать транспилятор, что в сумме выглядит ничуть не лучше решения от jQuery.
А если, как и положено нормальному сайту, на весь мир?
Или просто все зависимости раздаются с самого сайта.
Ну экономия на спичках же.
Особенно, если учесть, что jQuery весит 30 Кб, а полифил для Array.from, чтобы удобно итерироваться по NodeList, весит 1кб.
Скажем так, вероятность того, что роскомнадзор забанит cdn гугла ниже, чем вероятность того, что роскомнадзор забанит сервер вашей компании.
систему из детектора браузеров, вороха полифиллов, транспилятора и сборщика.Только не «и», а «или». Зачем нужны полифиллы, если будет транспилятор? И зачем нужны полифиллы и транспиляторы, если детектор их не подключит (а это большинство случаев)? Ну, и сборщик тут вообще непонятно, откуда взялся — я же пишу про рантайм.
Кроме того, при использовании этой библиотеки весь ваш код завязан на неё, а в «моём» варианте всю эту «обвязку» можно выкинуть, и в 93%+ случаев всё будет работать и так — даже на десктопе у IE всего 6.97%, а среди мобильных браузеров там и вообще меньше одного процента.
Зачем нужны полифиллы, если будет транспилятор?Потому что это разные вещи — транспилятор поддерживает синтаксис, а полифиллы — функционал. Хотя Babel поддерживает полифиллы в качестве плагина, у вас в итоге все равно будет и то, и другое.
я же пишу про рантаймЯ искренне надеялся, что это была опечатка. Вы на полном серьезе предлагаете и без того обиженным пользователям IE подсунуть клиентский транспилятор?
1. обход дома по вертикали и горизонтали (всякие parents, siblings, closest, matches — нативные варианты этих функций либо не очень удобны, либо до сих пор некроссбраузерны и приходится писать обертки);
2. поиск-фильтрация-отбор среди найденного;
3. создать-удалить-добавить-изъять-переместить-завернуть-развернуть;
4. манипуляция классами-атрибутами-стилями;
5. события повесить-убрать-послушать-вызвать;
6. работа с координатами и размерами…
Ну и так далее. Это я перечислил только самое базовое, без углубления в дебри.
Вообще jQ за все годы оптимизирована очень хорошо и для своего объема функциональности имеет более чем адекватный размер. Существенно его снизить можно только отказываясь от каких-то фишек, что и пытаются делать разные альтернативные библиотеки.
Я лично писал свой велосипед, по объему получилось в 5-6 раз меньше jQ, но у меня было только самое-самое необходимое. Чудес не бывает.
поиск-фильтрация-отбор среди найденного;Можно пример? По моему опыту, фильтры можно либо сразу запихать в селектор, либо там всё равно потом передаётся функция, которую можно и в
.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-атрибуты тоже специфику имеют.
учитывая, что каждый второй сайт сожержит jQuery, то вероятнее всего эти огромные 30кб будут уже закешированы в браузере или на сервере провайдера интернет.
Теперь новая проблема — а что делать со сьекономленной на загрузке 0.1 секунды времени?
сходить на сайт с jQuery посмотреть новости или погоду?
И какой трафик? Миллион посетителей в день? (Вряд ли). Т.е. 1Гб экономии в день, большая часть из которой на самом деле закеширована?
"Самый очевидный плюс" наверняка последний в списке плюсов для перехода.
538 млн. за июнь
Понятно, что кэш и все такое, но мне кажется экономия все же больше 1Гб в день.
Да и трафик там далеко не основная цель. Я лишь один из вариантов привел.
библиотека легко подключается с любого популярного CDN ресурса, легко достается с ближайшего кеша промежуточных серверов при первом обращении и из локального кеша браузера при последующих.
трафик будет между клиентом и CDN узлом. к «трафик GitHub» вообще никакого отношения не будет иметь.
в трафике клиента этот обьем будет ничтожно малым по сравнению с просмотром котика, новым роликом с ютюба или прослушиванием муз. трека.
Причина (по моей версии) была переложить ответственность за поддержку инструментария с библиотеки на браузер (разработчики библиотеки имеют больше шансов допустить ошибку, чем разработчики стандарта и браузеров, потому что ошибка имеет гораздо большую цену, поэтому код покрыт тестами лучше). Тем более снимается вопрос об обновлении библиотеки — это происходит автоматически на клиенте при обновлении браузера.
а также ради возможности использовать библиотеку Flow.JS для статического анализа типов.
Эх, на какие только жертвы люди не идут, чтобы ТС не юзать.
Вроде, это ортогональные вещи.
Typescript запускается только для проверки типов, с флагом --no-emit, а сборка происходит с Бабелем. Такой подход позволяет использовать кастомные babel-плагины для более оптимальной сборки, например, вырезания debug-информации
С таким утверждением соглашусь. Однако и здесь происходят изменения. Babel убирает stage-0 пресет, намеренно усложняя использование нестандартизованных (пока) фич языка.
Господи, в мире js все меняется быстрее чем этим заполняется stackoverflow. Теперь еще shadow dom и полифиллы… Ушел гуглить что это такое
Github.com отказывается от использования jQuery и переходит на чистый JavaScript