Hacker News Digest

Несмотря на 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.
• Были также затронуты темы о том, что встроенная санитизация может влиять на разработчиков, которые полагаются на встроенную санитизацию, и о том, что это может влиять на разработчиков, которые полагаются на встроенную санитизацию.

В предоставленном тексте отсутствует содержательная часть статьи о платформе 100X.Bot. Заголовок указывает на "всё-в-одном" AI-платформу, но нет описания её функций, возможностей или особенностей. Единственная дополнительная информация - это код отслеживания Facebook Pixel, что говорит о возможной интеграции с этой платформой или использовании её для аналитики. Для создания полноценного пересказа требуется более подробная информация о самой платформе, её назначении и преимуществах.

• Пользователи обсуждают, что «самовосстановление» (self-healing) в Agent4 ограничено лишь изменением CSS-классов, тогда как реальные сайты могут меняться гораздо шире, что ставит под сомнение ценность «самовосстанавливающихся» селекторов.
• Критика касается и того, что Agent4 не открыт исходный код, а также то, что расширение требует «разрешений на все сайты» и может читать/записывать cookies, что вызывает опасения по поводу приватности.
• Некоторые участники обсуждения задаются вопросом, действительно ли Agent4 соответствует принципам открытого исходного кода и прозрачности, и предлагают, что если нет — то почему бы не сделать его открытым.
• Обсуждается, что если селекторы нестабильны, то это может привести к тому, что автоматизация может внезапно сломаться, и это может быть критично для пользователей.
• Также поднимается вопрос о том, что если вместо того, чтобы полагаться на нестабильные селекторы, лучше было бы иметь возможность генерировать скрипт, который бы использовал более стабильные селекторы.

Turbo отслеживает Turbo Streams через два механизма. При отправке форм он перехватывает события submit через слушателя на document, предотвращает стандартную отправку и использует fetch API с заголовком Accept: text/vnd.turbo-stream.html. Это сигнализирует серверу, что можно отвечать Turbo Stream элементами. Сервер, в свою очередь, должен вернуть ответ с Content-Type: text/vnd.turbo-stream.html.

Для обработки ответов Turbo использует слушателя события turbo:before-fetch-response. Этот обработчик проверяет тип содержимого ответа и при совпадении добавляет содержимое в DOM. Когда <turbo-stream> элементы добавляются, они автоматически выполняют одно из семи действий (append, prepend, replace и т.д.). Для обычных fetch-запросов разработчикам нужно самостоятельно добавлять заголовок Accept.

• Turbo Streams становятся менее актуальными, так как фреймворк уже сам по себе использует их по умолчанию; оставляем только для специфичных сценариев вроде уведомлений.
• Подписки на каналы и фреймы полезны для изолированных обновлений, но не стоит переусердствовать с ними в ущерб стандартным паттернам.
• Покупатели из ЮВА сталкиваются с отсутствием покупательского паритета; вопрос о ценах и доступности курса остаётся открытым.
• Сообщество обеспокоено, что чрезмерная рельсовость может оттолкнуть не-Ruby разработчиков, которые сейчас используют Turbo вне Rails.

Функциональное программирование принесло во фронтенд мощные абстракции: React с компонентами как функциями от состояния, Redux с предсказуемыми редюсерами и TypeScript для типобезопасности. Однако эти принципы — чистота функций, неизменяемость данных и явные побочные эффекты — вступили в конфликт с природой веба, где DOM мутабелен, CSS каскадируется глобально, а пользовательские события асинхронны и хаотичны. Вместо адаптации к платформе разработчики стали строить слои абстракций, фактически объявляя войну встроенным механизмам браузера.

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

• Критика излишнего усложнения фронтенд-разработки из-за увлечения функциональным программированием и абстракциями в ущерб простоте и нативным возможностям платформы.
• Споры о читаемости и уместности использования методов массивов (map, filter, reduce) вместо классических циклов, а также о качестве кода на CSS.
• Обсуждение проблем управления состоянием и иерархией данных в UI, включая сравнение React с другими подходами и фреймворками.
• Вопросы к эволюции веб-платформы и стандартов, которые не успевают за потребностями разработчиков и популярными решениями из фреймворков.
• Замечания о качестве статьи-первоисточника: построение на спорных утверждениях (straw man) и продвижение авторской технологии (HTMLX).

• HTML: справка по элементам, глобальным атрибутам, форматам дат/времени, руководства по адаптивным изображениям, видео и аудио.
• CSS: справка по свойствам, селекторам, @-правилам, единицам измерения; гайды по блочной модели, анимациям, Flexbox, цветам; «поваренная книга» для колонок, центрирования, карточек.
• JavaScript: справка по встроенным объектам, операторам, функциям; гайды по управлению потоком, циклам, объектам, классам.
• Web APIs: File System, Fetch, Geolocation, DOM, Push, Service Worker; гайды по Web Animations, Fetch, History, Speech API, Web Workers.
• Другие технологии: Accessibility, HTTP, URI, WebAssembly, WebDriver, WebExtensions.
• Обучение: курс «Frontend-разработчик», основы HTML, CSS, JavaScript.
• Инструменты: Playground, HTTP Observatory, генераторы теней, радиусов, границ, палитра цветов.

• Участники обсуждают, как использовать тег <template> без фреймворков: он удобен для клонирования больших фрагментов, ускоряет рендер и снижает нагрузку по сравнению с React/Vue.
• Недостаток — приходится вручную связывать данные и DOM; многие хотят единого формата «HTML+CSS+JS» для компонентов.
• Shopify, Salesforce, MedusaJS и Alpine.js уже применяют <template> в продакшене, но спецификация HTML Modules пока не завершена.

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

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

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

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

SmallJS — свободная реализация Smalltalk-80, компилирующаяся в JavaScript для браузеров и Node.js.

• v1.7 уже доступна (GitHub).
• Работа ведётся в файлах, а не образах; отлично сочетается с VS Code (подсветка, отладка).
• Используются привычные JS-имена классов и методов; в комплекте обёртки для DOM, Express, БД, потоков.

Быстрый старт — примеры проектов и Todo-приложение.

Хотите помочь? Пишите на info@small-js.org.

• SmallJS вызвал всплеск интереса; автор @Smalltalker-80 откликается на вопросы.
• Проект файл-ориентирован, без образа; VSCode вместо браузерной IDE.
• flavio81 и wild_egg сожалеют о потере «живого» Smalltalk-опыта и сложностях синхронизации образов в Lisp.
• Playground SmallJS компилирует выражения прямо в браузере, но полноценной live-среды нет.
• Упомянуты Amber (застой), Pharo (монолитная VM) и Chrome Workspace для хот-релоада.

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-коммитах и т.д.
• Сообщество просит открытый код, нормальную документацию и понятную схему версионирования/обновления приложений.

Переосмысление 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, лучше продуманные формы/контролы, богатые стандартные виджеты), чем плодить новые параллельные стеки.