Hacker News Digest

GrapheneOS не может завершить порт на Pixel 11 из-за отсутствия поддержки аппаратного тегирования памяти (MTE) в прошивке, firmware и, вероятно, самом железе — функция, которую Google, по-видимому, отключил для экономии. MTE используется GrapheneOS по всей системе, включая ядро и стандартные процессы, и значительно повышает защиту от удалённых и локальных эксплойтов. В отличие от этого, Pixel 8 и новее имеют MTE, а Apple реализовала аналогичную технологию (MIE) в iPhone 17 как всегда включённую функцию высокого качества.

Хотя Pixel 11 получил улучшения вроде постквантовой проверки загрузки (ML-DSA), Titan M3 и замену модема на AOSP IMS, эти плюсы перевешиваются потерей MTE, удорожанием и слабыми аппаратными обновлениями: тот же GPU, уменьшенная RAM в базовых Pro-моделях и лишь догоняющий Qualcomm-модем. По сравнению с Snapdragon 8 Elite Gen 5, Pixel 11 отстаёт по производительности CPU и GPU, а также по радиомодулю. GrapheneOS настоятельно рекомендует не покупать Pixel 11, предлагая вместо этого Pixel 8, 9 или 10 — устройства с MTE и лучшим соотношением цены и безопасности, либо ждать поддержки Motorola-устройств, где MTE присутствует.

Pixel 11 имеет аппаратную поддержку MTE, но она отключена в прошивке. GrapheneOS не будет поддерживать устройство, пока MTE не будет включена официально на уровне ОС, даже если функция появится в Android 17 QPR2 Beta или в режиме developer option. Пользователи считают, что Google пожертвовал безопасностью ради снижения стоимости, что делает обновление нецелесообразным. Многие решили пропустить Pixel 11, оставшись на Pixel 8 или 10a из-за минимальных улучшений новой модели. При этом Pixel 8 подвержен массовым сбоям материнских плат через два года эксплуатации. Pixel 10a и 9a считаются последними надежными моделями с поддержкой GrapheneOS и без агрессивных функций вроде Gemini. Опыт владельцев Pixel 6, 7 и 10 подтверждает, что покупка предыдущих моделей по сниженной цене — оптимальная стратегия. Несмотря на это, выгодные предложения трейд-ин на Pixel 11 в 2024 году делают апгрейд экономически привлекательным. Среди пользователей ведутся споры: одни полагают, что MTE отключена из-за аппаратных проблем или в интересах спецслужб, другие обсуждают целесообразность использования устройств Google для обеспечения безопасности через GrapheneOS. Рекомендации: — Не обновлять работающий телефон и избегать новых моделей с отключенными функциями безопасности. — Выбирать Pixel 10 или 9a как стабильную альтернативу с поддержкой GrapheneOS. — Рассматривать устройства Motorola с предустановленной GrapheneOS от сторонних поставщиков. Отдельно отмечается медленная реакция EU-регуляторов на антиконкурентные действия Google. Сравнение с Apple считается неуместным, так как Apple полностью запрещает альтернативные ОС, в то время как Google лишь ограничивает открытость Android на практике.

Cloudflare запустила в бета-версии Web Search API — инструмент, позволяющий AI-агентам и приложениям выполнять поиск в интернете и основывать ответы на актуальных данных, а не полагаться на устаревшие знания модели или попытки угадать правильные URL. На старте доступны три провайдера: Ceramic.ai, Exa и Linkup, все они поддерживают Zero Data Retention при запросах через Cloudflare и соблюдают стандарты сканирования проверенных ботов.

API интегрирован с AI Gateway, поэтому запросы логируются и тарифицируются по стандартным ценам провайдеров без наценки, а также допускается использование собственных API-ключей. Вызов возможен через REST-запрос или привязку AI в Cloudflare Workers, как показано в примерах с поиском активностей в Солт-Лейк-Сити осенью. Для начала работы рекомендуется ознакомиться с руководством по использованию.

Тред раскрывает проблемы использования Web Search API от Cloudflare: ограничения на хранение и перепродажу результатов, сомнения в заявленном нулевом хранении данных, значительные различия в ценах и качестве провайдеров, а также наличие более дешевых и гибких альтернатив (самохостинг, SearXNG, Firecrawl). Пользователи ставят под вопрос добавленную ценность посредничества Cloudflare по сравнению с прямым доступом к провайдерам. Некоторые пользователи указывают, что провайдеры, заявляющие о Zero Data Retention, на самом деле могут сохранять данные, как показал @jasonjmcghee, сравнив информацию на странице провайдера Exa, где Zero Data Retention указано как "No". Вопрос о том, действительно ли Cloudflare сохраняет запросы в своих логах, поднимает сомнения в полной анонимности: @anon373839 задаётся, сохраняет ли сама Cloudflare запросы, даже если провайдеры обещают нулевое хранение. Ценовые различия между провайдерами огромны: Ceramic.ai $0.25, Linkup $5, Exa $7 за 1000 запросов, и пользователи отмечают, что такие цены значительно выше альтернативных сервисов вроде Serper.dev или Luna. Качество выдачи у разных провайдеров сильно варьируется: @freakynit сообщает о почти нулевых результатах от Ceramic.ai, а @hrideshmg отмечает стабильную работу собственного self‐hosted решения Firecrawl. Для снижения зависимости от Cloudflare и контроля над данными рекомендуется использовать self‐hosted решения (Firecrawl, SearXNG) или объединять несколько провайдеров через собственный слой, как делает @hmartin в TypeScript‐пакете. Многие считают, что основная выгода Cloudflare — упрощённый доступ из Workers и единый лог, но это не компенсирует более высокие цены и потенциальные ограничения по хранению данных. Если требуется интеграция с уже существующими агентами на Cloudflare Workers, стоит сравнить стоимость с Brave Search API, как предлагает @ByeByeSpace, чтобы выбрать более экономичный вариант.

В Дании выявлена масштабная утечка персональных данных: злоумышленники использовали легальный доступ одной компании к национальной базе CPR, чтобы получить имена, адреса и CPR-номера около 8,8 миллиона граждан. Утечка не затронула тех, кто оформил защиту своих данных — их информация осталась недоступной.

Администрация CPR немедленно отключила доступ компании, уведомила надзорный орган Datatilsynet и передала дело в полицию. Ведётся расследование в сотрудничестве с экспертами и государственными структурами. Инцидент подчёркивает риски, связанные с широким доступом к централизованным реестрам, даже при формальном соблюдении законов.

Утечка CPR-номеров в Дании произошла из-за неограниченного легального доступа компаний к национальной базе через API, а не из-за взлома. CPR-номер используется как универсальный идентификатор для доступа к медицинским, банковским и государственным сервисам, что делает его критически ценным. Доступ к базе предоставляется без ограничений на объём или частоту запросов, позволяя любому сотруднику компании экспортировать данные всей популяции. Население Дании — около 6 млн, но утечка затронула 8,8 млн записей, включая данные умерших и бывших резидентов, что указывает на хранение исторических данных в базе. Несмотря на наличие MitID как двухфакторной системы аутентификации, утечка CPR-номеров ставит под угрозу целостность системы, так как номера используются как первичный идентификатор во многих сервисах, где двухфакторная аутентификация не применяется (например, аптеки). Цифровизация государственных услуг в Дании развивалась без должного акцента на кибербезопасность, и IT-инфраструктура часто управляется другими министерствами, а не отдельным ведомством. Аналогичные утечки произошли в Польше (20 млн медицинских записей) и Франции (678 тыс. налоговых записей), указывая на системную проблему в ЕС. GDPR не предотвратил такие инциденты: штрафы недостаточны для стимулирования инвестиций в безопасность, а закон не применяется к государственным системам в полной мере. Спор о публичном доступе к данным (как в Швеции через hitta.se) не решён: одни считают, что прозрачность снижает риск злоупотреблений, другие — что это лишь легитимизирует эксплуатацию данных и не заменяет защиту. Для снижения рисков необходимо: рассматривать CPR-номер как имя пользователя, а не пароль, требуя дополнительный фактор аутентификации; обязывать компании анонимизировать или хешировать данные при тестировании; вводить уголовные наказания для ответственных лиц внутри компаний; ограничивать доступ к CPR только тем организациям, которые действительно нуждаются в данных для законных функций, и проводить строгий аудит всех запросов. Утечка подтверждает, что персональные данные в Дании давно не являются секретом — они доступны через легальные каналы, делая инцидент не новостью, а масштабным проявлением уже уязвимой системы. Цифровая идентификация на основе национальных номеров фундаментально уязвима при отсутствии контроля над доступом.

Жительница Флориды использовала чат-бота Claude в качестве личного дневника, записывая в него мысли и планы, включая детали предполагаемого насилия. Одна из записей содержала упоминание о намерении совершить стрельбу в общественном месте, что вызвало тревогу у системы модерации Anthropic. Компания, следуя своим правилам безопасности и обязательствам по предотвращению вреда, передала соответствующую запись в правоохранительные органы. После этого женщина была задержана и предъявлено обвинение в совершении преступления, связанного с планированием насилия. Случай подчеркивает, как ИИ-ассистенты могут непреднамеренно становиться частью цепочки событий, ведущей к реальным последствиям, особенно когда пользователи делятся опасными намерениями в диалогах с моделями. Anthropic подтвердила, что действовала в рамках своей политики использования, направленной на предотвращение насилия и защиту общественной безопасности. Инцидент также поднял вопросы о границах конфиденциальности при взаимодействии с ИИ и ответственности разработчиков за мониторинг контента. Хотя Claude не предназначен для хранения личных данных вроде дневника, его использование в таких целях может привести к непредвиденным выводам системы безопасности. Случай стал примером того, как эческие safeguards в ИИ могут срабатывать в реальных ситуациях, даже когда пользователь не ожидал такого вмешательства. Это также подчеркивает важность осознанного использования ИИ-инструментов и понимания их ограничений в вопросах приватности и безопасности.

Флоридский закон 836.10 считает угрозу совершённой, если она записана в электронном виде и доступна потенциально другим лицам — не требуется направление конкретному получателю. Пользовательское соглашение Anthropic прямо разрешает проверку контента, поэтому сбор данных не является шпионажем и имеет правовую основу. Использование чат‐бота как личного дневника лишает пользователя ожидания конфиденциальности: записи принадлежат сервису и могут быть переданы правоохранительным органам. Некоторые комментаторы видят в этом риск «преступления мысли», так как сложно различить роль‐игру и реальные планы, опасаясь преследования за гипотетические высказывания. Для снижения риска рекомендуют самохостинг моделей или API без автоматической модерации, где пользователь контролирует передачу данных. Ситуация иллюстрирует дилемму ИИ‐компаний между безопасностью общества и приватностью пользователей; в США есть прецеденты передачи подобных записей полиции.

Комары переносят опасные болезни, которые снова становятся угрозой в США из-за потепления и устойчивости к пестицидам: в 2024 году зафиксировано почти 4000 случаев денге — рост на 360% по сравнению с десятилетним средним, а в 2023-м впервые за два десятилетия зарегистрировано десять случаев локальной малярии. Технология генетического подавления популяций комаров, разработанная компанией Oxitec, уже доказала свою эффективность: в полевых испытаниях она сократила численность Aedes aegypti на 80–95%, выпуская самцов с летальным геном tTAV, который приводит к гибели потомства в дикой среде без тетрациклина. Несмотря на подачу заявки в регуляторы в 2010 году, технология всё ещё не одобрена из-за бюрократических задержек в EPA, где оценка ГМО проводится по тем же протоколам, что и для обычных пестицидов, без учёта их специфики в распространении и наследовании. Ускорение процесса возможно — как показал опыт FDA с пользовательскими сборами, которые сократили время審 препаратов с 29 месяцев до 6–10. У США есть ресурсы и необходимость избавиться от переносчиков болезней внутри своих границ — достаточно лишь сделать этот выбор.

Тред дополняет статью практическими наблюдениями и аргументами: большинство комаров‐переносчиков инвазивны, их удаление вряд ли нарушит пищевые цепочки, но есть опасения по поводу непредвиденных экологических последствий. Большинство таких комаров, например Aedes aegypti, инвазивны; их уничтожение не приведёт к полному исчезновению комаров — другие виды заполнят ниши. Технологии генетического подавления нацелены на конкретные виды, поэтому остальные сохраняются и продолжают выполнять экологические функции. Есть спор: некоторые опасаются, что исчезновение комаров повлияет на пищевые цепочки (например, на летучих мышей, лягушек и птиц). Скептики сомневаются в эффективности gene drive из‐за возможного оттеснения естественным отбором при фитнес‐стоимости. Предлагаются альтернативные методы контроля: DIY‐средства вроде mosquito dunks (биологический ларвицид: заливаешь водой, добавляешь таблетки, обновляешь периодически) и традиционные химические распыления (менее экологичны, но широко используются). Подчеркивается необходимость регуляторного надзора: отсутствие контроля позволяет компаниям выпускать ГМ‐комаров без надзора, требуется законодательное вмешательство. Личный опыт из Сингапура показывает, что отсутствие комаров значительно улучшает комфорт летнего отдыха на открытом воздухе.

На Гран-при Бахрейна произошел масштабный сбой в программном обеспечении FIA, который лишил пилотов доступа к критически важным данным во время гонки. Из-за ошибки в системе отображения информации на рулевых колесах и в боксах команды не могли видеть текущие позиции, интервалы между машинами, состояние шин и предупреждения о желтых флагах. Пилоты описывали ситуацию как «ужасную и полностью неприемлемую», отмечая, что они фактически гонялись вслепую, полагаясь только на интуицию и ограниченную связь с инженерами. Некоторые сравнивали это с вождением в условиях полной потери ситуационной осведомленности, что создавало серьезные риски безопасности.

Сбой затронул практически все команды и продолжался значительную часть гонки, прежде чем инженерам FIA удалось восстановить работу системы через резервные каналы. Пилоты, включая Ландо Норриса и Шарля Леклера, открыто критиковали FIA за недостаточную надежность критически важных систем, подчеркивая, что такие сбои недопустимы на уровне Формулы 1. Инцидент поднял вопросы о резервировании и тестировании программного обеспечения, используемого в гонках, и может привести к пересмотру протоколов обеспечения бесперебойной работы телеметрии и информационных систем в будущих этапах чемпионата.

Все машины Формулы‐1 используют одинаковый ECU‐хардвар — TAG700 от McLaren Applied (ранее Motion Applied). Фирменное ПО должно соответствовать правилам FIA; команды могут менять только параметры, а не ядро прошивки. Обновления прошивки применяются между сессиями, часто через флеш‐накопитель или кабель в гараже во время красного флага, без длительного лабораторного тестирования. Сбой в Бахрейне, вероятно, вызван изменением конфигурации или отключением безопасных ограничений, а не полной заменой кода, и усугублен недостаточным тестированием в дождевых условиях. Маленькие команды имеют ограниченные ресурсы для тестирования и полагаются на ПО, предоставляемое FIA, что повышает риск ошибок. Разработчики ПО в мотоспорте часто работают без строгих процессов, что приводит к более низкому качеству кода по сравнению с автомобильной или промышленной отраслью. F1‐карты рассматриваются как прототипы: каждый Гран‐при отличается небольшими изменениями в аппаратуре и ПО, поэтому баги появляются регулярно. Поставщик ECU — Motion Applied (ранее McLaren Applied Technologies), ПО поставляется FIA. Ilmore не является поставщиком ECU в F1.

RemoveMacAI — утилита для полного отключения Apple Intelligence на macOS 27 и восстановления занятого ею места на диске. После выключения функций через системные настройки модели ИИ остаются в хранилище, и этот скрипт не только деактивирует функции (Siri, Writing Tools, Genmoji, Image Playground, интеграцию с ChatGPT, суммаризацию в Mail и других приложениях, предиктивный ввод, Spatial Photos и др.), но и удаляет загруженные модели через сервис управления активами Apple, не трогая /System и оставляя SIP включённым. Все изменения обратимы: достаточно выполнить removemacai revert.

Инструмент работает через конфигурационный профиль, который применяет ограничения Apple и перенаправляет запросы на загрузку моделей на локальный закрытый порт, предотвращая их повторную загрузку. Профиль требует ручного одобрения в System Settings. Утилита не делает сетевых запросов и не собирает данные. Доступна через одноразовый установщик (curl ... | bash) или Homebrew (brew install omlahore/tap/removemacai). Поддерживается только на Apple Silicon и macOS 27+. Dictation остаётся рабочим, так как использует отдельные модели. После удаления модели могут ещё отображаться в разделе «Хранилище» до фоновой очистки системой. Spotlight-процесс, именуемый Siri, остаётся активным — это нормально в macOS 27.

Пользователи отмечают рост занимаемого места из‐за Apple Intelligence: модели ИИ занимают 10‐12 ГБ, что критично на SSD 256 ГБ. Отсутствие встроенных средств удаления вызывает опасения по поводу «bloatware» и заставляет искать сторонние решения. Многие ценят открытый исходный код RemoveMacAI, но советуют проверять подписи, provenance‐аттестацию и код перед запуском из‐за рисков безопасности. Некоторые считают удаление ИИ‐моделей бессмысленным, так как они «небольшие и сбалансированные»; другие настаивают, что они занимают ценное место без пользы. Для очистки симуляторов рекомендуется использовать Xcode → Preferences → Locations → Derived Data или вручную удалять ~/Library/Developer/CoreSimulator/Devices, что освобождает сотни гигабайт. Пользователи отмечают, что даже отключённые функции AI продолжают занимать место (пример: 4 ГБ, исчезают и возвращаются), указывая на недостаточную очистку macOS. Ситуация сравнивается с «de‐crufting» в Windows и Android: Apple теперь тоже требует сторонних утилит для контроля над ресурсами.

Google Data Center в Линкольне, зарегистрированный как Agate LLC, потребляет 52,65 мегаватт электроэнергии в пиковые нагрузки и 13,299 мегагаллона воды в год — около 13 миллионов галлонов, что эквивалентно заполнению 20 олимпийских бассейнов. Это менее половины ежедневного водопотребления города Линкольн за один день. По данным за сентябрь 2026 года, шесть дата-центров в Небраске суммарно используют 765 миллионов галлонов воды в год — достаточно, чтобы заполнить 1 160 олимпийских бассейнов. Наибольшее потребление воды демонстрирует дата-центр в Папиллионе (Fireball Group LLC) — 547,88 мегагаллона в год.

Кроме того, improper redaction раскрыл ожидаемые налоговые возвраты Google по программе Nebraska Advantage Act: Agate LLC ожидает $55,8 млн, Fireball LLC — $39,2 млн, а Westwood Solutions LLC (Омаха) — $22,6 млн за 2025 год. Площадь объекта Agate LLC составляет 288 530 кв. футов — примерно пять футбольных полей. Несмотря на требования исполнительного указа губернатора Джима Пиллена от июля 2026 года о самоотчёте влияния дата-центров на водные и энергетические ресурсы, компании продолжают использовать торговые тайны как основание для сокрытия данных, хотя простые методы выделения и копирования текста позволяют восстановить скрытую информацию. Отчёты доступны через публичный портал Nebraska DWEE по запросу «DCR».

Водопотребление дата-центров в Небраске значительно ниже сельскохозяйственного: один средний фермерский участок использует в 30 раз больше воды, чем дата-центр Google в Линкольне (390 млн галлонов в год), а общее потребление сельхозугодий превышает потребление всех дата-центров на порядки. В Небраске 44 479 ферм занимают более 90% территории и используют десятки миллионов акр-футов воды в год. Водопотребление дата-центра в Папиллионе (548 млн галлонов) в 40 раз превышает потребление дата-центра в Линкольне, что указывает на различия в эффективности охлаждения. Фактическое водопотребление дата-центров в Небраске не превышает 1% от суточного потребления города Линкольн, делая их локальное воздействие незначительным. Вода, используемая для охлаждения дата-центров, не загрязняется и возвращается в окружающую среду, в отличие от промышленного потребления. Сравнение с олимпийскими бассейнами помогает понять масштаб, но более релевантны сравнения с сельхоз- и городским водопотреблением. Дата-центры не являются аномалией в промышленном водопотреблении: их потребление сопоставимо с гольф-клубами и отелями. Снижение водопотребления возможно за счёт воздушного охлаждения, но это увеличивает энергопотребление — компромисс между ресурсами. Фермеры используют воду для орошения кукурузы и сои, требуя в десятки раз больше воды, чем дата-центры, но без аналогичного общественного резонанса. Для объективной оценки необходимо учитывать источник воды (поверхностный, грунтовый, сточные), метод охлаждения и местные экологические условия. Прозрачность в отчётах о водопотреблении должна быть стандартизирована, чтобы избежать дезинформации и морального панического настроя. Некоторые комментаторы считают акцент на водопотреблении дата-центров отвлечением от вопроса о целесообразности развития ИИ, другие настаивают, что ресурсное потребление — реальный, измеримый аспект, требующий прозрачности. Разница между разрешённым и фактическим водопотреблением часто игнорируется в СМИ, искажая восприятие воздействия. Использование дождевой или повторно использованной сточной воды могло бы снизить давление на муниципальные ресурсы, но не упоминается как практика в текущих объектах. Данные о налоговых возвратах дата-центров (например, $100 млн в год) поднимают вопрос о справедливости субсидирования инфраструктуры, потребляющей ресурсы без прямого налогового вклада в местные бюджеты.

Strata — это бесплатный и открытый движок для запуска модели Qwen3.8-Flash-Next на обычных игровых ПК с видеокартой NVIDIA или AMD от 12 ГБ VRAM и 32 ГБ ОЗУ. Он позволяет работать с 125-миллиардным параметровым ИИ локально: чат, генерация кода, анализ изображений и интеграция с агентами — всё без отправки данных в сеть. Установка выполняется в один клик для Windows и Linux, а после запуска модель доступна через локальный OpenAI/Anthropic-совместимый API.

На RTX 5070 (12 ГБ) модель в режиме IQ3_S генерирует ответы со скоростью 53 токена в секунду и обрабатывает промпты до 32К токенов со скоростью 1,620 токенов в секунду. На AMD RX 9070 XT (16 ГБ) соответствующие показатели составляют 44 и 1,420 токенов/с. Благодаря технике «guess, then check» и чтению длинных текстов блоками до 8,192 токенов, ускорение достигает 1,6–1,8× по сравнению с обычным режимом. Для комфортной работы со всеми вариантами модели рекомендуется 64 ГБ ОЗУ и SSD — первый запуск тогда происходит значительно быстрее. Strata использует квантованные версии модели от ISTA-DASLab, UkisAI и Unsloth, а также компоненты llama.cpp, и распространяется под лицензией MIT.

Strata обеспечивает высокую пропускную способность — 100–200 токенов/сек на потребительском железе (RTX 4090, RTX 5090 и аналогичные), подтверждая заявленную производительность. Однако качество заметно падает при низкобитных квантизациях (<4‐bit), особенно в задачах зрения и генерации кода. При работе с визуальными задачами Strata показывает медианную ошибку 154.8 px против 46.5 px у llama.cpp с теми же весами, что указывает на существенный компромисс между скоростью и точностью. Для стабильной работы требуется минимум 32 ГБ видеопамяти и 64 ГБ системной ОЗУ; на 16 ГБ RAM модель не запустится с желаемой производительностью. Ограничения PCIe Gen3 могут стать узким местом даже при мощных GPU. Не рекомендуется запускать несколько запросов одновременно из-за частого переключения контекстов, что снижает эффективность. Strata запускается даже на интегрированной графике, но с низкой скоростью. Для ноутбуков рекомендуется выбирать модели, помещающиеся в 6–8 ГБ VRAM. Увеличение размера модели с 27 B до 125 B даёт лишь ~10 % прироста скорости, что не всегда оправдывает рост аппаратных требований. Для лучшего баланса скорости и качества советуют использовать квантизации IQ2/IQ3. Отмечается рост экосистемы локального инференса: альтернативные движки (Swift, FreeToken, ds4) в некоторых тестах работают быстрее llama.cpp. Высокая пропускная способность открывает сценарии вроде интерактивной помощи в кодинге в реальном времени. В заголовках публикаций следует указывать тип квантизации для прозрачности ожидаемого качества. Однокнопочная установка и открытый код получают положительные отзывы, но реальное тестирование в разных сценариях всё ещё ограничено. Есть скепсис относительно «hype» вокруг Strata из-за отсутствия заметных улучшений точности по сравнению с другими моделями.

Разработчики часто избегают использования нативных возможностей браузера, несмотря на их производительность и надёжность, из-за исторической нестабильности веб-платформы. Долгое время браузеры отставали от потребностей разработчиков, и библиотеки вроде jQuery заполняли критические пробелы, пока стандарты не догоняли. Даже после появления evergreen-браузеров привычка искать решения в npm осталась сильной: разработчики привыкли к знакомым интерфейсам фреймворков и библиотек, где документация понятна, примеры наглядны, а API обёрнут в удобную оболочку. Нативные API, хотя и мощные, часто кажутся «неуклюжими» или плохо документированными по сравнению с привлекательными страницами сторонних пакетов, такими как Dragula, чей сайт выглядит гораздо более приглашающе, чем сухая страница MDN.

Кроме того, существует разделение труда в экосистеме: опытные разработчики готовы использовать низкоуровневые DOM-операции в библиотеках, если они скрыты за привычными абстракциями вроде JSX или хуков React. Это позволяет новичкам работать с высокоуровневыми primitives, не погружаясь в сложности платформы. Однако с ростом ИИ-ассистентов в коде ситуация может измениться: в оптимистичном сценарии агенты будут выбирать платформенные API как более эффективные и проверенные решения, снижая необходимость в избыточном пользовательском коде. В пессимистичном же случае ИИ будет генерировать дублирующий, неидиоматичный код, усиливая фрагментацию и переусложнение, поскольку разработчики могут не тратить время на проверку альтернатив. В любом случае, напряжение между удобством экосистемы и чистотой платформы останется актуальным.

Разработчики избегают нативных возможностей браузера из-за исторической нестабильности, неполноценных API (Web Components, <dialog>, <datalist>), давления дизайнеров и продуктовых команд, привычки и экосистемной патологии, где библиотеки стали стандартом. Web Components имеют плохо продуманный API, требующий обёрток вроде Lit для практического использования. Нативные элементы <datalist> и <dialog> часто ненадёжны или ограничены в браузерах (особенно Firefox и Safari), что вынуждает писать кастомные решения. Safari остаётся проблемой из-за привязки обновлений к версиям ОС, делая новые API недоступными для значительной части пользователей даже после стандартизации. UX-дизайнеры и продукт-менеджеры требуют кастомных интерфейсов (календарей, выпадающих списков), так как нативные элементы не соответствуют визуальным требованиям или не позволяют реализовать сложные сценарии. Многие разработчики выбирают кастомные решения не ради удовольствия, а потому что только они позволяют точно реализовать задуманное поведение, особенно в доступности и анимации. Спор: отсутствие полнофункционального searchable combobox с доступностью вынуждает создавать кастомные компоненты, делая зависимость от npm неизбежной — платформа учит работать вне себя. Спор: одни считают, что веб-платформа должна быть минимальной и композируемой (как Linux), другие — что она должна предоставлять готовые высокоуровневые компоненты, иначе разработчики изобретают велосипеды. Нативные API могут скрывать баги, проявляющиеся только в редких условиях, что делает их ненадёжными для продакшена и заставляет предпочитать контролируемые кастомные решения. Поколение разработчиков, выросшее на React, не знает нативных возможностей браузера и воспринимает работу с DOM как антипаттерн, закрепляя зависимость от фреймворков. Некоторые разработчики, вернувшиеся к vanilla JS + CSS, отмечают, что их приложения загружаются и работают быстрее, чем 99% сайтов с npm и сборкой, и не сталкиваются с ограничениями платформы. Совет: перед созданием кастомного компонента — исследовать, тестировать и оценивать нативные возможности, но не осуждать тех, кто пропускает эти шаги из-за сроков или сложности. Исторически многие стандарты (например, scroll-driven animations) появились не из спецификаций, а потому что разработчики сами создали и массово использовали паттерны, которые потом стандартизировали браузеры. В корпоративной среде многие разработчики просто не знают о существовании нативных элементов вроде <dialog> или <details>, что приводит к повторному изобретению колеса из-за отсутствия обучения. Использование платформы требует отказа от пожеланий продуктовых команд, что требует зрелости и понимания реальной стоимости кастомной разработки — навыка, которым обладают не все. Некоторые разработчики, использующие AI (например, Claude), создают сайты с минимальным JS, опираясь на нативные элементы, и достигают отличных результатов по весу и производительности, если приоритет — лёгкость.