и посмотреть медиа
Будни разработчика: блог лид JS
и посмотреть медиа
Блог ведущего JS-разработчика о повседневной работе.
Блог ведущего JS-разработчика о повседневной работе.
Личный блог Lead JS-разработчика. Публикации о буднях в IT, полезных практиках, инструментах и опыте. Инсайты для frontend и fullstack разработчиков, желающих развиваться в JavaScript экосистеме.
#статья дня Леа Веру написала большой текст в защиту полифиллов. Поводом стало мнение одного из ключевых редакторов WHATWG: полифиллы якобы вредят веб-платформе, потому что слишком рано занимают имена и форму будущих API. Проблема действительно существует. Кто-то реализует ещё не утверждённый API, библиотека становится популярной, сайты начинают от неё зависеть. После этого изменить название или поведение уже сложно: старые страницы сломаются. Браузерам приходится либо повторять чужую реализацию вместе с её ошибками, либо искать для стандарта менее удачную форму. В качестве более безопасной альтернативы часто предлагают ponyfills. Полифилл добавляет отсутствующий API туда, где он должен находиться: if (!RegExp.escape) { RegExp.escape = value => /* реализация */; } После этого приложение всегда вызывает RegExp.escape(). В новом браузере работает нативная версия, в старом — подставленная. Ponyfill глобальные объекты не меняет. Это обычная импортируемая функция: import { regexpEscape } from "./regexp-escape.js"; На первый взгляд подход аккуратнее: ponyfill не занимает имя будущего API и не вмешивается в платформу. Но Веру считает, что полноценной заменой полифиллам он быть не может. Главное преимущество полифилла — код сразу пишется под стандартный API. Когда браузер добавляет нативную реализацию, приложение автоматически начинает использовать её, а полифилл постепенно превращается в пустышку. Ponyfill остаётся в коде. Даже когда браузеры давно поддерживают нужный API, проект продолжает использовать импортированную функцию. Для перехода на нативную реализацию придётся менять импорты и вызовы. Можно заставить ponyfill внутри проверять наличие нативного API, но тогда получается, по выражению Веру, «разобранный полифилл»: стандартная реализация уже используется, однако нестандартный интерфейс и отдельная зависимость всё равно остаются. Ponyfills полезны, пока API только проектируется: на них можно проверить идею, не занимая заранее имя в платформе. Но для уже сформировавшегося API полифилл даёт более естественный путь — стандартный интерфейс сегодня и автоматический переход на браузерную реализацию завтра. Веру также считает, что полифиллы несправедливо делают виноватыми в проблемах совместимости. Даже без них останутся проверки возможностей, @supports, условные импорты и самописные обёртки, которые точно так же могут закрепить раннюю форму API. Зато полифиллы позволяют использовать новую возможность после появления первой браузерной реализации, не дожидаясь всех остальных. Разработчики получают работающий API, а другие браузеры — реальный спрос и причину быстрее добавить поддержку. Поэтому популярный полифилл — не только риск, но и сигнал: функция разработчикам уже нужна, а стандартизация и браузеры за ней не успевают. Ponyfills хороши для экспериментов, но не заменяют главного свойства полифилла — способности со временем стать ненужным. #javascript
Открыть канал и посмотреть медиаOnly registered users can share their opinion.
Be the first to share your impression of this resource!
Market channel with goods, discounts and trade offers. Everything for profitable purchases and sales.