Logo
TGCATALOG
Каталог Подборки Блог
Будни разработчика: блог лид JS

Будни разработчика: блог лид JS

Блог ведущего JS-разработчика о повседневной работе.

Нет оценок
932
29.10.2026
932
29.10.2026
Нет оценок
932
29.10.2026
Безопасный переход через бот
О канале

Блог ведущего JS-разработчика о повседневной работе.

Подписчиков 14,297
Тематика IT
Язык Русский
Ссылка t.me/htmlshit
Описание

Личный блог Lead JS-разработчика. Публикации о буднях в IT, полезных практиках, инструментах и опыте. Инсайты для frontend и fullstack разработчиков, желающих развиваться в JavaScript экосистеме.

Последние посты

Будни разработчика: блог лид JS
Будни разработчика: блог лид JS
🔒Открыть пост
и посмотреть медиа
#статья дня Леа Веру написала большой текст в защиту полифиллов. Поводом стало мнение одного из ключевых редакторов 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
Будни разработчика: блог лид JS
Динамика подписчиков
+-0.8% за 30 дней
Текущие
14,297
Месяц назад
14,419
Средний рост
+-4 / день
Обновлено
21 час назад

Отзывы о канале Будни разработчика: блог лид JS

Авторизуйтесь, чтобы оставить отзыв

Только зарегистрированные пользователи могут делиться своим мнением.

Пока нет отзывов

Станьте первым, кто поделится своим впечатлением об этом ресурсе!

Похожие ресурсы

Loading
Переход на светлую тему
Главная Каталог Подборки Блог Вход