Comments 33
На дворе 2020, не используйте полифилы.
Если что-то работает в хроме, но не работает в ФФ хотя бы в найтли (или наоборот) — значит фича пока сырая, глюкавая и будет дорабатываться.
Если юзерам нужен ИЕ, то скорее всего у них ХР. Подумайте, нужны ли в 2020 вам такие юзеры. Если даже нужны — пересаживайте их на ESR-версии хрома/ФФ/оперы, там хотя бы асинки работают и большинство из нужных фич.
Полифилы мало того что раздувают ваш бундль, они ещё часто тормозят всех. JS полифил всегда будет выполняться медленнее, чем нативная реализация того же в браузере.
На крайний случай делайте две сборки — нормальную и легаси с полифилами. Vue например умеет такое «из коробки», но не всем так повезло.
Подумайте, нужны ли в 2020 вам такие юзеры.
Вот у нас бизнес подумал и сказал, что нужны. Заметную часть доходов приносят пользователи IE в b2b сфере у многих, насколько я знаю.
раздувают ваш бундль, они ещё часто тормозят всех
Мы используем такой подход: современные браузеры не тормозим, старые и так медленные.
Первым идёт небольшой скрипт который проверяет фичу и синхронно подключает скрипт полифила.
!window.Promise && document.write('<script src="путь"></script>')В итоге новый браузер пробегает десяток if и быстро работает, старые браузеры ждут пачки полифилов.
Правда это не работает с async\await и другим новым синтаксисом, но тут мы планируем собирать два бандла.
Если юзерам нужен ИЕ, то скорее всего у них ХР. Подумайте, нужны ли в 2020 вам такие юзеры.
Ушел пересаживать тысячу-другую своих бухгалтеров и юристов на Линукс, пришла команда из хабра.
А сидят они в IE не по своей прихоти или нежелании переходить на другие браузеры. Основная часть этих пользователей работает или в банковской сфере или работают с банками (или с госструктурами). Он поддерживает нужный тип шифрования. Для этого же браузера пишут специальные расширения для работы. Кроме того, в таких организациях очень не любят что-то менять, если и так хорошо работает.
В части, что полифилы медленнее нативной реализации, согласен, но, когда нет выбора, то без них не обойтись.
Кроме того, в таких организациях очень не любят что-то менять, если и так хорошо работает
В том-то и дело, что работает плохо. Explorer устаревший и самый небезопасный браузер и ничего хорошего там нет. Сидят на нем не от хорошей жизни, и я не понимаю, зачем оправдывать этот старый хлам.
По правде говоря, я и сам не понимаю этого требования на счёт IE. Нормальная система должна работать во всех браузерах. Вот, поэтому, там, где невозможно использовать браузеры актуальной версии или поддерживающие стандартные функции и приходится использовать полифилы (как по мне, частный случай «костылей»).
в таких организациях очень не любят что-то менять
Ну вот, вот настоящая причина. Вон выше xitt 20 лет назад освоил администрирование ХР, и теперь все его «тысячи-другие бухгалтеров и юристов» должны страдать.
Ну это его проблемы, а речь про разработчиков. Под ИЕ мало просто поставить полифилы, там слишком много всего надо тащить. Вы не можете использовать допустим нативные мультимедиа АПИ напрямую, вы должны брать либу, которая их оборачивает (и тормозит на нормальных браузерах) и тянет флэш для ИЕ. И так куда ни плюнь. А потом всё это нужно тестировать, в том числе в ИЕ. Со своими тысячами бухгалтеров такие как товарищ выше пусть разбираются сами, но почему миллионы разработчиков должны страдать?
Разработчик волен выбирать поддерживать ему ИЕ и ко или нет. Есть проекты, где даже в вакансиях выдают за свой плюс: "ИЕ не поддерживаем", а крепостное право отменили. Более того, можно даже свой бизнес открыть, если никак не можешь найти проект, где бизнес считает выгодным не поддерживать ИЕ.
А так большинство разработчиков поддерживают ИЕ, потому что это входит в условия их работы, они так договорились с работодателем. Уж что-что, а не разу не слышал даже, чтобы поддержка ИЕ появилась в проекте, чтоб пришёл начальник и сказал "ребята, с сегодняшнего дня мы поддерживаем ИЕ" (вернее в третьем тысячелетии ни разу не слышал :) )
Уважаемые читатели! Пользуетесь ли вы полифиллами?
Да, пользуюсь. Давеча было два юзкейса:
Первый уже внедрил на одном проекте, а над вторым как раз подумываю. Какие у вас впечатления по этим полифиллам, если пользовались?
Мне обе фичи очень нравятся: диалоги — своей семантичностью и поддержкой нескольких плюшек (form method=dialog, showModal(), ::backdrop), а :focus-visible — возможностью сделать ненавязчивый focus ring, включающийся только при работе с клавиатуры.
По крайней мере проблему flat и Promise вы бы точно решили.
Наиболее адекватное найденное решение на 2019 год — www.npmjs.com/package/webpack-polyfill-injector
Оно конечно не идеально, но на порядок лучше чем искать и подключать необходимые полифиллы ручками из разных источников.
Благо на дворе 2020 и такой инструмент есть: browserslist + Can I Use как источник данных, какие технологии поддерживаются в целевых браузерах; @babel/preset-env c
useBuiltIns: 'usage' в качестве анализатора кода и инсертера полифиллов; core-js как источник полифиллов; Webpack optimization.splitChunks для вынесения в отдельный кешируемый файл вроде polyfill.somecontenthash.js. Про год шучу, было доступно и раньше.Этот способ позволяет точно определять необходимые полифиллы для конкретного проекта и соответствует требованиям информационной безопасности. Альтернатива — polyfill.io, внешний скрипт, в который передается вручную набор необходимых фич (например,
https://polyfill.io/v3/polyfill.min.js?features=es2017), и их сервер в зависимости от User Agent включит в отдаваемый файл только те полифиллы, которые требуются конкретному браузеру. Так, современным будет отдан с размером менее 1кб, а стареньким — соответствующей возрасту толщиной. Соответственно, как внешний скрипт, на непредсказуемое время может блокировать загрузку страницы и отдавать любой код, крадущий ваши данные (даже доверяя конкретным разработчикам, надо учитывать что и Гугл раз в год бывает взломан). Но многие выбирают именно это решение, да и вообще пользуются опенсорс-пакетами, не валидируют поступающие данные, и… в общем, дело каждого.В любом случае, думаю что оба решения получше, чем ручной подбор полифиллов (когда я подбирал вручную, ан-нет, а всегда что-то да забывалось, то Date.now забудешь, то .trim(), то Object.assign).
А статья будто из родных 00-х, удивительно сейчас такое читать, как и видеть подобный стиль кода с использованием
// startHere Make some forEach
arr.forEach(function() { someLogic; })
// endHere Make some forEach
Не использовать ли анализатор кода
Не выйдет надежно в силу динамической природы js — можно промахнуться и недоложить полифиллов (ну и я просто не люблю babel — везде использую ts компилятор, даже где просто js).
Задача чуть более реализуема для ts, но готовых инструментов мне не известно.
polyfill.io — накладывает лишнего (webpack-polyfill-injector кстати использует polyfill.io как источник полифиллов).
Несмотря на необходимость ручного подключения, мне как-то легче прописать десяток недостающих функций (пусть и за несколько походов в консоль), чем надеяться на магическую автоподстановку или бороться с желанием порезать лишнее из polyfill.io
Так речь необязательно о служебном сайте, а об абстрактном сервисе доступном всем желающим. Менеджеры смотрят на цифры аналитики, видят там пользователей с IE и не хотят терять эти пару процентов.
Когда я пришел туда, и копнул код. Я был в ужасе. Конечно я пришел с предложением переписать код, как многие до меня. Так как оддерживать сие — боль. Да и о новых фишках можно было и не думать.
И ответ топ менеджмента — Дима, у нас нет бюджета и времени на переписание фронта. Мы не можем выделить команду на полтора два года, для этого. Да и в чем смысл для нас? Клиенты покупают, мы продаем — все овольны. Какой профит принесет переписанный фронт допустим на Реакт?
И если подумать — а профита особо и нет для клиента. Увы.
Так что не все зависит от программистов. У него свои рамки и приходится выкручиваться и саппортить ненависный IE.
Когда менеджмент топит (а топит обычно только менеджмент в случае публичного продукта) за поддержку IE подразумевается, что они считают прибыльность его поддержки, включая репутационный ущерб от отказа поддерживать клиентов, которые иной раз десятилетия лояльны компании.
Сказано красиво, но иной раз кажется что это решение основано не на учете всех факторов, а на обычном "так исторически сложилось, если что-то поменять и оно сломается, кто за это отвечать будет?"
Вот поэтому такая ситуация и есть, ждем пока случится какой-то волшебный скачок, как это вышло в истории про IE6 и Youtube.
P.S. особой сложности добавляет здесь то, что IE11 – это последняя версия браузера вообще. То есть если раньше разговор шел о том, чтобы убрать старые версии из поддержки и оставить только новые, то теперь надо убрать браузер из поддержки целиком. А на это сложнее уговорить.
Может по разному бывает, но на проектах, на которых я работал в последние годы, доля ИЕ мониторится и где-то раз в полгода вопрос о целесообразности дальнейшей поддержки поднимается. В смысле доходит до руководства. Разработчики и QA постоянно поминают IE "добрым, тихим словом".
Я бы не сказал, что сложнее уговорить: аргументы одни и те же у сторон в разговорах, как о том, что дропнуть поддержку 9 и 10, так и 11. Тут скорее оценка вероятности, что клиенты обновятся другая.
Использование полифиллов при написании кросс-браузерных приложений