Hacker News Digest

Переосмысление DOM с нуля

Браузеры в странном положении: WebAssembly выстрелил, даже на сервере, а клиентская часть ощущается почти как 10 лет назад. Доступ к веб-API из WASM решают тонким JS-клеем — но зачем вообще лезть в DOM? Просто других опций нет. Пора отправить DOM и его API «на ферму», и вот почему.

Никто уже не знает браузеры целиком — и это часть проблемы.

Модель «документа»

Мало кто осознает, насколько DOM раздут. У document.body в Chrome 350+ ключей, а в document.body.style — около 660 свойств. Граница между свойствами и методами размыта, геттеры могут триггерить релэйаут, висят легаси-штучки вроде onevent. DOM толстеет; страничникам это почти не видно, а приложениям — боль.

Большинство избегают прямой работы с DOM; деклартивности мало и она несовременна. Способов сделать одно и то же много, ни один не приятен.

connectedCallback() {
  const shadow = this.attachShadow({ mode: 'closed' });
  const template = document.getElementById('hello-world').content.cloneNode(true);
  const hwMsg = `Hello ${ this.name }`;
  Array.from(template.querySelectorAll('.hw-text')).forEach(n => n.textContent = hwMsg);
  shadow.append(template);
}

Веб-компоненты пришли поздно, непопулярны: API громоздкий, Shadow DOM плодит уровни вложенности и области видимости. Главная беда — строковая наследственность SGML/XML: состояние хранить в документе плохо; React-подобные это избегают, их «XML» — лишь синтаксис.

HTML почти не менялся 10–15 лет. ARIA стала заплаткой тому, что не дала «семантика HTML». Цели так и не достигли: нет <thread> или <comment>, правила странные. WHATWG (то есть вендоры) добавляет лишь заплатки по краям; даже CSS оброс выражениями — любая шаблонка хочет стать языком программирования.

Редактируемость HTML через contentEditable — теоретически есть, практически — темная магия; у команд Docs/Notion наверняка кошмары. Догмы про «прогрессивное улучшение» и разделение разметки/стилей в мире приложений мало кто исповедует.

Сегодня приложения склеивают HTML/CSS/SVG до «достаточно красиво», ценой огромных оверхедов — это анти-UI тулкит.

Подпись: Ввод Slack

Подпись: Оффскрин-хаки для буфера обмена

Списки и таблицы приходится виртуализировать вручную, перехватывая лайаут, ресайз, драги и т. п. «Прилипший вниз» скролл в чате — вечный TODO. Чем больше виртуализируешь, тем больше заново пишешь «поиск на странице», контекстные меню и пр. Веб стер грань между UI и «текучим контентом» — когда-то это было ново, теперь UI устарел, контент унифицировался.

CSS вывернут наизнанку

CSS не имеет стройной…

• Участники признают, что веб-платформа сложна и разрослась из-за обратной совместимости, множества требований и долгой эволюции; переписывание «с нуля» в реальности лишь добавляет новые слои сложности.
• Многие защищают DOM/HTML/CSS: они кроссплатформенны, поддерживают доступность, приватность, IME/спеллчек и текстовые сценарии, с которыми канвас/кастомные рендеры часто не справляются.
• Критика фокусируется на перегруженности API, «текучих» абстракциях и смешении ролей (CSS как и стиль, и лейаут), предлагаются идеи модульности API, хранение состояния в документе, и дисциплинированное использование Web Components.
• Аргумент «выбросить и заменить» упирается в стоимость миграции и необходимость покрыть весь исторический функционал; успех веба объясняют именно гибкостью, хаками, позже закреплёнными стандартами, и жёсткой обратной совместимостью.
• Проводят параллели с нативными UI-стеками: многие считают веб-технологии более удачными; обсуждают Flutter/WASM/WebGPU как путь к «приложенческому» вебу без ломания существующего.
• Идеи разделения «документы vs приложения» всплывают часто (вплоть до «DOCTYPE app»), но консенсус: нужно сосуществование обоих подходов, а не замена.
• Скепсис к «HTML на Canvas» и «перезапуску браузера» высок: полезнее усиливать существующие примитивы (дешёвый доступ WASM к DOM, лучше продуманные формы/контролы, богатые стандартные виджеты), чем плодить новые параллельные стеки.