Hacker News Digest

Разработчики часто избегают использования нативных возможностей браузера, несмотря на их производительность и надёжность, из-за исторической нестабильности веб-платформы. Долгое время браузеры отставали от потребностей разработчиков, и библиотеки вроде 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, опираясь на нативные элементы, и достигают отличных результатов по весу и производительности, если приоритет — лёгкость.

Несмотря на 15 лет развития фронтенда, сравнение React и Backbone показывает удивительно мало прогресса в снижении сложности. Код для одинаковой функциональности в обеих фреймворках примерно одинаков по длине, что ставит под сомнение все усилия сообщества. React выглядит чище, но это достигается за счет скрытой сложности абстракций, в то время как Backbone предлагает явное, хоть и многословное, описание происходящего.

"Вы торгуете явной простотой за сложность абстракций" — ключевая мысль статьи. React скрывает множество деталей: неожиданное очищение инпутов из-за смены ключей компонентов, бесконечные циклы в useEffect из-за нестабильных зависимостей, "устаревшие" замыкания в обработчиках событий. Эти не крайние случаи, а обычные проблемы, требующие понимания алгоритмов согласования, фаз рендеринга и планировщика React.

Для 99% приложений, не имеющих тысячи компонентов на странице, такая сложность может быть избыточна. Фундаментальная задача "событие + состояние = UI" остается простой, но современные фреймворки создают ненужные абстракции, мешающие пониманию и отладке. Возможно, сообществу стоит искать более прозрачные и "взламываемые" решения, подобные Backbone и jQuery.

• Обсуждение показало, что споры между сторонниками React и Backbone часто сводятся к сравнению простых примеров, что не отражает реальную сложность больших приложений и может вводить в заблуждение.
• Участники подчеркнули, что React и Backbone решают разные задачи: первый предлагает сложную, но мощную систему управления состоянием, тогда как второй предоставляет прямой и прозрачный контроль над DOM.
• Несколько человек отметили, что выбор между инструментами должен зависеть от характера проекта и команды, а не от сравнения "Hello World" примеров.
• Обсуждение также затронуло вопрос о том, что разработчики могут переоценивать или недооценивать сложность, связанную с управлением состоянием, и как это влияет на выбор инструмента.
• Наконец, было высказано мнение, что выбор между React и Backbone должен быть основан на факторах, таких как размер команды, сложность проекта и долгосрочная поддерживаемость, а не на сравнение простых примеров кода.

Предоставленный текст содержит только навигационную структуру сайта MDN, но не основное содержание статьи о методе setHTML(). В тексте отсутствует описание самого API, его синтаксиса, параметров, примеров использования и совместимости с браузерами. Для создания точного пересказа требуется полное содержание статьи, описывающее новый метод DOM API, который, вероятно, предоставляет альтернативу innerHTML с дополнительными возможностями или улучшенной безопасностью. Без доступа к фактическому описанию метода невозможно предоставить содержательный пересказ его функциональности и применения.

• Впервые за 25 лет в Firefox Nightly появилась возможность безопасно вставлять HTML через Element.setHTML(), что вызвало обсуждение: спор о том, почему так долго не хватало базовой возможности, и о том, что API-шный дизайн (включая именование setHTML/setHTMLUnsafe) не идеален.
• Участники обсуждения отметили, что новое API встроенной санитизации встроенной в браузер — это фактически встроенный DOMPurify, и что спор в основном ведется о том, что «безопасность по умолчанию» должна быть выбрана как поведение по умолчанию.
• Некоторые комментаторы выразили обеспокоенность тем, что спецификация пока не различает между контентом и вставляемым через setHTML() и innerHTML, и что это может влиять на производительность, если разработчики начнутт читать спецификацию как «естественное продолжение» innerHTML.
• Были также затронуты темы о том, что встроенная санитизация может влиять на разработчиков, которые полагаются на встроенную санитизацию, и о том, что это может влиять на разработчиков, которые полагаются на встроенную санитизацию.

Rust повышает производительность разработки, несмотря на сложность.
Ключевые факторы:

• Жёсткий компилятор ловит ошибки до запуска, уменьшая время отладки.
• Модель владения устраняет гонки и утечки памяти, снижая количество багов.
• Инструменты: Cargo, Clippy, rustfmt и rust-analyzer ускоряют цикл «написание → проверка → запуск».
• Сообщество предлагает качественные крейты и быструю помощь.
• Производительность кода сравнима с C/C++, но без segfault и UB.

В итоге меньше времени тратится на отладку, больше — на новые функции.

• Автор статьи рассказал, как Rust позволяет безболезненно рефакторить большие кодовые базы благодаря строгой типизации и проверкам компилятора.
• Многие участники согласились, что статическая типизация (Rust, Haskell, OCaml-подобные языки) повышает уверенность при изменениях, особенно в многолюдных проектах.
• Часть комментаторов считает сравнение с TypeScript «нечестным»: TS компилируется в JS и наследует его недостатки, а приведённый баг с window.location.href — это особенность DOM, а не языка.
• Некоторые отметили, что Rust тоже не идеален: async/синхронные блокировки, медленная компиляция и «множество способов сделать одно и то же» могут снижать удобство.
• Общий вывод: преимущество Rust в безопасности и рефакторинге особенно заметно на больших проектах, но язык требует времени на изучение и не всегда лучше «классических» статически типизированных альтернатив.

Hyperclay — однофайловые HTML-приложения
Работайте как с глиной: открыли файл, изменили — изменения сохранились. Без сборки, деплоя и фреймворков.

• Прямое редактирование в браузере: меняете DOM — файл перезаписывает себя через /save.
• Полная переносимость: скачали HTML — запустили где угодно, офлайн.
• Версии: каждое сохранение фиксируется, откат в один клик.

Примеры: dev-log, writer, kanban, landing.

Почему это важно

Статические сайты удобны, но изменения исчезают после перезагрузки. Чтобы сделать цифровой объект «физическим» — нужен сервер, БД, API, аккаунты. Hyperclay убирает всё лишнее: UI, логика и данные — в одном самомодифицирующемся HTML-документе.

• Hyperclay — это NodeJS-сервер + клиентская библиотека, которая сохраняет изменения DOM прямо в исходный .html-файл, обновляя его на лету.
• Идея вызывает ассоциации с TiddlyWiki, Webstrates и даже HTA-архивами Windows 98, но делает акцент на многопользовательской работе и версионировании.
• Участники обсуждают проблемы локального file:// (CORS, модули), безопасность, ограничения iOS и то, что без сервера изменения не сохраняются.
• Некоторые делятся своими однофайловыми решениями: шифровальщик, Asteroids, «твиттер» на git-коммитах и т.д.
• Сообщество просит открытый код, нормальную документацию и понятную схему версионирования/обновления приложений.