Комментарии 24
А какой процент пользователей сидят в вк на IE 11, если не секрет?
Когда пишите web-приложение с поддержкой ослика, не забудьте проверить как оно в нём работает. Особенно если обмазались промисами.
Мы долго смирялись с размером бандла (который, кстати, не так сильно кратно растёт, если вашего кода сильно больше), пока не решили проверить юзабилити в IE. Это невозможно! Поэтому мы решили, что сотрудники банков (кто ж ещё это устаревшее уг использует?) не должны страдать.
Если приложение большое, то да, полифиллы не так сильно бросаются в глаза. Однако зачастую они занимают процентов 20 от общего бандла. При том что современные браузеры могут в большинстве случаев обходиться без них.
Речь о том, что core-js не только много весит, но и адски тормозит?
Есть где посмотреть тесты производительности по сравнению с нейтивом?
Скорее о том, что сами полифилы не делают движок лучше и быстрее. Так, например, полифил Promise не делает движок ослика конкурентным.
В нашем кейсе мы прям "обмазались" async/await, Vue.js с экосистемой и многим другим. Но когда попробовали поработать в IE11, то получили такие задержки при переходах по страницам, такие задержки отрисовки и прочее, что стало понятно, что никто в здравом уме не станет работать в этом браузере. И это всё в локальной сети. При задержках в 100-200ms это уже финиш.
Если обмазываться асинхронными функциями, то и в современных браузерах всё будет тупить: https://habr.com/ru/post/543934/
В случае ослика всё усугубляется не столько из-за полифила, сколько из-за того, что все асинхронные функции транспилируются в конечный автомат.
"corejs": 3
Пожалуйста, не делайте так. Нужно указывать минорную версию core-js
, т.е. corejs: '3.20'
, иначе будут использоваться модули и данные, что были только во время 3.0
- а это апрель 2019, многое с тех пор прошло.
То есть сам пресет энв берет инфу о поддержке той или иной конструкции из
caniuse-lite
preset-env
берет инфу из compat-table
.
Наш
index.js
(справа) весит 2 KB, а полифиллы для него — больше 20.
В данном, случае спасибо babel
за хелперы - из-за не самого лучшего варианта использования Object.getOwnPropertySymbols
грузится полный полифил символа. Большая часть объёма оттуда. Использовался бы Reflect.ownKeys
- ситуация была бы куда проще. Вообще, в актуальной версии полифил символа слишком часто подгружается не к месту.
Мы во ВКонтакте...
Ребята, пожалуйста, используйте актуальную версию библиотеки - со старой возможны серьезные проблемы, да и соберите все копии в один бандл:
@ArthurSupertramp поправьте таки, пожалуйста, версию core-js
в конфиге во избежание лишних проблем и вопросов у прочитавших данный пост.
Спасибо за фидбэк, внёс в статью ваше примечание о compat-table
С версией corejs в конфиге preset-env не всё так однозначано. Кажется, что минор в конфиге ваще ни на что не влияет: https://github.com/babel/babel/blob/main/packages/babel-preset-env/src/index.ts#L207
Не совсем понял, что данной строчкой вы хотите показать - здесь подключается плагин babel-plugin-polyfill-corejs3
, на стороне которого сейчас и находится вся логика, ответственная за подключение core-js
и на стороне которого разбираются опции.
Простой пример - метод Array.prototype.at
был добавлен в стандарт относительно недавно. esnext
версия появилась в core-js@3.8
, стабильная - в core-js@3.17
. Видит Babel array.at(i)
, таргет IE - импорт чего ему вставлять? В core-js@3.0
нет ни es.array.at
, ни esnext.array.at
, попытка их импорта сломает код. Поэтому и пришлось добавить такой костыль.
Вообще, смотрим документацию.
не из
caniuse-lite
, а из собственной базы@babel/compat-data
@babel/compat-data
собирается из compat-table.
Прошел месяц - ни исправления, ни ответа...
Для того чтобы сайт не был громоздким, делают 2 сборки - modern и legacy.
И потом в зависимости от поддержки nomodule аттрибута будет грузится нужный бандл. Соотвественно люди использующиее современный браузер страдают меньше.
Количество пользователей IE - не постоянное число, оно уверенно уменьшается и уже находится где-то на уровне погрешности измерений. Инвестиции сил и времени в изчезающий рынок - так себе стратегия. Многие крупные вендоры уже давно объявили о завершении поддержки IE в своих продуктах, включая самих MS. Закопайте уже этот труп.
Полезная информация. Спасибо!
Привет! Классная статья, спасибо. Не мог пройти мимо :) Мы выбрали немного другой путь и уже раздаём ES2017 в продакшене пару лет. Ненужные полифиллы в ES2017 не включаем.
Подход, правда, устарел, но суть почти та же. Прикладываю выступление, может быть - будет интересно, как это было сделано https://youtu.be/CKbOHn1lJWw?t=7829
Для решения этой и многих других проблем придумали typescript, почему бы не использовать его? При том что гибкая конфигурация т.с позволяет без особых проблем за короткое время перевести весь проект на него.
По моему субъективному мнению, в наше время разрабатывать на проекты ванильном JS нужно считать "плохой практикой", т.к ts позволяет избежать огромного ряда проблем которые возникают при разработке средних и крупных проектов на JS.
А как ts решит проблему, которую решают полифиллы? Кажется, что это несвязанные вещи. TS помогает писать более стабильный код, но к кроссбразуерности он, кмк, отношения не имеет.
Так классно что доходчиво и просто описали кто есть кто, и что за что отвечает, я так долго собирал эту картину у себя в голове, а уж новичкам, надеюсь будет очень полезно.
Правда я ожидал что надейтся хитрый способ сделать чего нибудь с бандлом под ie например сбилдить два, и отдавать в зависимости от user-agent, но и за это спасибо.
Babel + core-js + IE = ???