Почему разработчики игнорируют нативные API браузера?

Представьте: вы хотите сделать список с виртуальной прокруткой. Первая мысль — открыть npm и найти react-virtual или @tanstack/virtual. Вторая мысль появляется гораздо реже: а может, браузер уже умеет это сам? Этот паттерн — рефлекторное движение к экосистеме пакетов в обход платформы — один из самых устойчивых в современной веб-разработке.

Годами сторонники веб-стандартов, производительности и доступности призывали разработчиков «использовать платформу» (use the platform). Аргумент прост: зачем строить что-то самому на JavaScript, если браузер сделает это за вас? Всё, что вы напишете, скорее всего, окажется медленнее и менее удобным, чем то, что браузер даёт из коробки.

Тогда почему же большинство разработчиков этого не делают? Нолан Лоусон — веб-инженер, известный по PouchDB и клиенту Mastodon Pinafore, — опубликовал в октябре 2026 года подробный разбор этого вопроса. Давайте пройдём по его аргументам и добавим контекст 2026 года.

1. Исторический груз: эпоха сломанных браузеров

Самая очевидная причина — историческая: долгое время браузеры догоняли экосистему над ними. Библиотеки вроде jQuery заполняли критические пробелы, пока браузеры реализовывали эквивалентные API — и даже тогда приходилось ждать, пока отстающие вроде IE6 не устареют, чтобы ими можно было пользоваться.

Сегодня большинство браузеров вечнозелёные (Safari спорен, хотя ~7 обновлений в год — неплохо), но вплоть до 2020-х веб-разработчикам приходилось иметь дело с крайне неровной платформой.

Эта эпоха выработала устойчивый рефлекс: не доверяй браузеру, возьми библиотеку. Рефлекс пережил ту реальность, которая его породила. Сейчас IntersectionObserver, ResizeObserver, CSS Grid, position: sticky, <dialog>, popover API — всё это поддерживается повсеместно. Но привычка тянуться к npm никуда не делась.

ℹ Исторический факт
jQuery появился в 2006 году именно потому, что разные браузеры по-разному реализовывали DOM API. Сегодня базовые API унифицированы, но наследие «не верь браузеру» живо в культуре и учебных материалах.

2. Сила привычки и экосистемное мышление

Ещё одна причина — привычка: когда вы привыкли искать React-компоненты на npm, именно туда вы и тянетесь, какой бы ни была задача. Если поискать «sticky positioning» на npm, там не найдётся пакета с надписью «просто используй CSS position: sticky, болван».

Экосистема npm создала собственную гравитацию. Разработчик думает категориями фреймворка, а не платформы. Особенно ярко это проявляется в мире React:

Многие React-разработчики предпочитали придерживаться JSX и идиом React — сырые DOM API казались «отвратительными» — но были совершенно готовы использовать низкоуровневые библиотеки, где сырые DOM-манипуляции обычны. Например, библиотека виртуальных списков может спокойно использовать сырые DOM API ради производительности, при этом выставляя более высокоуровневые примитивы, понятные новичку в React. В каком-то смысле экосистема React-компонентов создала естественное разделение труда, где более опытные разработчики упаковывали незнакомые API платформы в более привычную форму.

«Если поискать sticky positioning на npm, там не найдётся пакета с надписью “просто используй CSS position: sticky, болван”» — Нолан Лоусон

3. Документация: кто выигрывает войну за внимание

Это, пожалуй, самый недооценённый фактор. Частично этот эффект обусловлен документацией. Многие npm-пакеты имеют любовно написанные README или сайты с примерами, туториалами и скриншотами. Тогда как до тех пор, пока MDN не стал главным местом для веб-документации (с web.dev как более футуристичным ответвлением Google), документация по веб-платформе была разбросана по блогам, StackOverflow и сайтам вроде CSS Tricks.

Сравните опыт:

Критерийnpm-пакетНативный браузерный API
ДокументацияREADME + примеры + StorybookMDN (теперь хорошо, раньше — разброс)
Интеграция с фреймворком«из коробки» для React/Vue/AngularТребует адаптации
Поиск в GoogleНаходится сразуНужно знать, что искать
Обновленияnpm updateБраузер обновляется сам
Размер бандла+N KB0 KB
БагиЗависят от автора пакетаЗависят от вендора браузера

Победитель в колонке «Размер бандла» очевиден. Но разработчик видит это только тогда, когда его бандл уже весит 500 КБ.

💡 Совет
Перед тем как добавить npm-пакет, откройте MDN Can I Use и MDN Web Docs. Часто нативное решение поддерживается в 95%+ браузеров и не требует зависимости.

4. IKEA-эффект и удовольствие от сборки

Среди причин, которые исследует автор, — внутренняя радость и ценность обучения от самостоятельной сборки (IKEA-эффект), а также исторические пробелы в выразительности CSS.

IKEA-эффект в разработке — это когда ты больше ценишь то, что сам написал. Свой модальный диалог кажется «правильным», даже если нативный <dialog> делает то же самое лучше, быстрее и доступнее.

Это не глупость — это человеческая психология. Проблема возникает, когда «я хочу понять, как это работает» превращается в «я буду поддерживать этот код в продакшне вечно».


graph TD
    A[Задача: нужен модальный диалог] --> B{Первая мысль}
    B --> C[Ищу npm-пакет]
    B --> D[Использую нативный dialog]
    C --> E[+30 KB в бандле]
    C --> F[Зависимость от автора]
    C --> G[Возможные a11y-проблемы]
    D --> H[0 KB — встроено в браузер]
    D --> I[Фокус, Escape, backdrop — бесплатно]
    D --> J[Полная поддержка скринридеров]
    E --> K[Техдолг через 2 года]
    H --> L[Работает сегодня и через 10 лет]

5. Что меняет ИИ — в лучшую или худшую сторону?

Автор размышляет о том, как ИИ-ассистенты для написания кода могут либо уменьшить, либо усугубить склонность избегать нативных решений платформы.

Это ключевой вопрос для 2026 года. По данным отчёта Figma об ИИ, 68% разработчиков используют ИИ для генерации кода в процессе разработки. Что это значит для «используй платформу»?

Сценарий «хуже»: ИИ-ассистент обучен на огромном корпусе кода, где npm-решения представлены несравнимо богаче, чем нативные API. Спросите Copilot или Claude, как сделать тост-уведомление — и с высокой вероятностью получите импорт react-toastify, а не предложение использовать нативный showToast() или просто <output role="status">.

Сценарий «лучше»: ИИ-ассистенты становятся всё лучше в чтении документации. По данным Mintlify, почти половина трафика на документационные сайты теперь приходит от ИИ-агентов, включая Cursor, Claude Code, ChatGPT и Perplexity. Если MDN хорошо структурирован, ИИ может научиться предлагать нативные решения так же уверенно, как библиотечные.

Бум ИИ усложняет ситуацию. Предупреждают, что «ИИ и продукты в стиле vibe-coding появляются повсюду, грубо нарушая лучшие практики доступности, ещё больше загрязняя веб опытом, которым не все могут пользоваться».

⚠ Риск
АИ-ассистенты, обученные на популярном коде, воспроизводят популярные паттерны — в том числе плохие. Всегда проверяйте, нет ли нативного решения, прежде чем принимать предложение модели.

6. Реальная цена игнорирования платформы

Проигнорировать нативные API — не просто эстетический выбор. Последствия измеримы.

Почти 90% крупнейших сайтов не обслуживают корректный HTML согласно спецификациям W3C и WHATWG. Более трети сайтов не проходят проверку доступности, что для их владельцев — скорее юридическая ответственность (проблема соответствия), чем просто неловкость, учитывая охват Европейского акта о доступности 2025 года.

Фронтенд-фреймворки создают собственные проблемы. Самый распространённый тип ошибок (обнаружен более чем на 59% всех сайтов) — неправильно вложенные элементы, то есть некорректная вложенность тегов.

Пример: вместо нативного <details>/<summary> (работает везде, доступен, 0 JS) разработчик пишет кастомный аккордеон на 200 строк