Hacker News Digest

Регулярное использование ИИ-ассистентов приводит к накоплению когнитивного долга, снижению вовлечённости в работу, ухудшению критического мышления и замедлению формирования навыков, как показывают исследования. Постоянное делегирование решений создаёт слепые зоны, мешая осознавать компромиссы и проверять, соответствует ли направление, выбранное ИИ, личным предпочтениям и стилю. Один день в неделю без ИИ позволяет оценить реальное влияние автоматизации, проанализировать принятые решения и вернуть ощущение потока и удовлетворения от самостоятельной работы.

Для внедрения достаточно попросить руководство разрешить отключать ИИ-ассистенты один день в неделю — писать код вручную, читать документацию и думать самостоятельно. Инструменты вроде Greptile или Prelint допустимы, так как они дают обратную связь для обучения, в отличие от ИИ, который не извлекает уроков. Инициатива началась с HTMX, где CEO ввёл такие пятницы; присоединиться можно, написав в X @lazilyevaluated. Даже один день в неделю снижает долгосрочное потребление токенов и возвращает радость от творческого процесса.

Отказ от ИИ в один день недели — личная стратегия, компенсирующая чрезмерную зависимость, но не решающая проблему системного делегирования решений. **Практические рекомендации:** - Использовать ИИ для задач, которые проще объяснить, чем решить самостоятельно (итерации UI), но не для задач, требующих глубокого понимания логики (архитектура). - Применять ИИ как замену Stack Overflow — для вопросов, а не для генерации кода. - Вводить «AI brakes» на выходных: писать код вручную на личных проектах для поддержания когнитивных навыков. - Блокировать 90 минут в неделю на глубокий разбор отчётов ИИ вместо ежедневных поверхностных проверок. - Использовать ИИ для представления вариантов, а не для принятия решений. - Некоторые полностью отказались от ИИ в рабочее время, чтобы восстановить удовольствие от кодинга и мотивацию. - Не использовать выводы ИИ, если непонятно, как они получены, — это главный способ избежать когнитивного долга. - Ограничение ИИ может быть и экономически осознанным выбором (пример: продажа бюджета токенов коллегам). **Спорные позиции:** - Исследования «когнитивного долга» основаны на препринтах с низкой репродуцируемостью, проблемной методологией EEG и неубедительными выводами. - «Снижение вовлечённости» — не деградация, а естественный результат делегирования рутины. - Анализ и проверка выводов ИИ могут повышать критическое мышление, а не снижать его. - Требование писать код вручную — ретро-романтизм без практической ценности, если человек понимает работу ИИ. **Общий вывод участников:** Правила не должны навязываться — каждый решает сам, когда и как использовать ИИ. ИИ должен оставаться инструментом, а не заменой мышления: ключевое условие — понимание того, что генерирует ИИ, прежде чем использовать его выводы.

htmx 4.0.0 вышел после восьми месяцев разработки, сосредоточившись на стабильности и будущей долговечности — с целью создания веб-сервисов, работающих 100 лет. Главное изменение: атрибуты больше не наследуются автоматически, а требуют явного указания через :inherited (например, hx-confirm:inherited), что устраняет неочевидное поведение из прошлых версий. Для миграции доступен инструмент командной строки, автоматически находящий места, где нужно добавить :inherited.

Внутренне библиотека перешла с XMLHttpRequest на современный fetch(), что упростило код и позволило реализовать стриминг HTML. Имена событий стандартизированы, а поддержка истории больше не использует localStorage, убрав частые проблемы с отладкой. Несмотря на изменения, поведение 4.0 почти идентично 2.x — обновление необязательно: NPM оставит 2.x как latest, пока 2027 год. Для разработчиков, использующих LLM, выпущены специальные файлы с руководствами по миграции, отладке и написанию расширений.

Тред в основном поддерживает релиз, но добавляет несколько практических наблюдений: реальный опыт миграции с Turbo/Hotwire на htmx 4 в Rails-приложении (@dajonker), сочетание с agent-driven разработкой благодаря простой HTML-разметке (@bluesnowmonkey, @arjie), подтверждение востребованности обновлённой совместимости с Alpine через alpine-ajax (@james2doyle), а также контраргумент из .NET/Angular-стека о возврате к смешению UI и бизнес-логики (@rednb). Шутка про «CEO of HTMX» стала мемом треда.

• htmx ценят за простоту, низкий порог входа и органичный рост без корпоративных амбиций; многие отмечают, что агенты и vibe-coding отлично работают с гипермедийным HTML, потому что UI можно тестировать без headless-браузера (@bluesnowmonkey, @arjie, @havaloc, @nzoschke).

• Наследование атрибутов через явный `:inherited` воспринимается как спорное, но потенциально полезное для читаемости (@jamesforestwest, @ryanisnan отмечает, что кроме статического HTML лучшей альтернативы для «100-летнего веба» он не видит).

• Совет: @james2doyle на практике заменил htmx связкой Alpine.js + alpine-ajax (~10 КБ), получив все нужные фичи и обойдя проблемы совместимости hx-alpine-compat.

• Совет: @dajonker в проде на Rails заменил большую часть Hotwired/Turbo на htmx 4, используя ActionCable для пушей вместо Turbo Streams, и отмечает, что с htmx поток контента управляется с клиента, а не с сервера.

• Спор: @rednb, опытный .NET+Angular разработчик, считает htmx шагом назад: возврат к генерации UI на бэкенде смешивает presentation с бизнес-логикой, а серверное управление состоянием в нетривиальных SPA сложнее TypeScript. Ему возражают сторонники SSR-подхода (@nzoschke: Go+htmx+SQLite как простой и быстрый стек), показывая, что «шаг назад» зависит от класса задач.

• alpine-ajax и Datastar упоминаются как реальные альтернативы/дополнения к htmx (@james2doyle, @threesmegiste: Datastar вырос из идей htmx, @teknico).

• Спор: @replwoacause сомневается в долгосрочной ценности htmx в эпоху LLM, которые могут генерировать JS напрямую; @threesmegiste и @ryanisnan контраргументируют, что простота и независимость от JS-цепочек инструментов остаются преимуществами, особенно для долгоживущих сервисов.

• Совет: Несколько пользователей (@cubefox, @hollowturtle) сообщают о практическом баге: якорные ссылки в секции «On this page» ломаются на Mobile Safari и Android Firefox/Chrome — регрессия 4.0.0, не упомянутая в статье.

• Мем треда — самопровозглашённые «CEO of HTMX» (@Baguette5242, @dec0dedab0de, @hmokiguess, @miguel-muniz, @alkonaut), породивший шутку про домен htmx.ceo и реплику «у нас больше CEO, чем пользователей» (@alkonaut).

• Совет: @praseodym и @orsenthil независимо заметили, что обложка релиза (джип) совпадает с обоями Omarchy Quattro/DHH; @alsanan напоминает, что истинный драйвер 4.0 — проект fixi того же автора, более минималистичный преемник.

htmx 4 — это не фреймворк, а мерч-сборник с юмористическим уклоном: сайт swag.htmx.org продаёт футболки, худи, стикеры и кружки с мемами вроде «htmx sucks» и «Hypermedia is for Lovers». Всё это — пародия на экосистему современных фронтенд-библиотек, где даже технические инструменты обрастают культурой бренда. Сайт предлагает товары в 17 валютах, от USD до JPY, и включает коллекции с персонажами вроде «Grug» — отсылкой к трендам вроде «простой код для простых людей».

Сайт не содержит реальных продуктов — только рекламные баннеры, трекеры и куки от Google, Twitter, Facebook, TikTok и Microsoft, что само по себе является сатирой на современные веб-платформы. Даже кнопки «Accept all» и «Reject all» имитируют навязчивые согласия на отслеживание, подчёркивая абсурдность текущей модели монетизации веба. htmx 4 — это не обновление, а культурный комментарий: если фронтенд стал ритуалом, пусть и мерчем его празднуют.

htmx прост в использовании, позволяет быстро создавать отзывчивые сайты с минимальной сложностью и успешно заменяет React и Vanilla JS. Пользователи отмечают его эффективность для статических сайтов и совместимость с AWS Step Functions и PostgreSQL. Рекомендуется использовать htmx вместе с серверными шаблонами. Один из пользователей критикует отсутствие надёжного fallback при отключённом JavaScript, что может ухудшить доступность. Команда htmx известна нестандартным подходом — например, выпуском htmx 4.0 на Game Boy.

Чтобы ускорить процесс получения услуг у регулируемой монополии, где падение удовлетворённости ниже 96 % грозит миллионами штрафов, команда решила заменить устаревший ASP‑форму и дорогой React‑приложение на полностью HTML‑ориентированный сайт. Используя Astro, они построили сайт, где каждая стадия формы — отдельная страница, отправляемая на сервер, а данные сохраняются в базе. Такой подход позволил работать без JavaScript, поддерживать древние браузеры и сохранять ввод даже при плохом соединении. Результат — количество пользователей мгновенно удвоилось.

Ключевой принцип — «простое HTML работает везде». Как отмечает Теренс Эден, даже браузеры типа PSP, способные открыть лишь три вкладки и часто терять память, без проблем отображают страницы GOV.UK, написанные в лёгком HTML. Команда использовала кастомные веб‑компоненты, которые перехватывают стандартную валидацию браузера, выводят ошибки в aria‑describedby и очищают их при вводе, избегая тяжёлых React‑валидаторов. Доступность достигла уровня AA, а всё приложение оставалось лёгким: без 20 МБ JavaScript‑пакетов, только небольшие улучшения в виде CSS и минимального скрипта. Это показывает, что для публичных форм достаточно чистого HTML и грамотного серверного хранения, а современные фреймворки лишь дополняют, а не заменяют базовый веб‑технологический фундамент.

• Простой HTML‑first подход с минимальным JavaScript может значительно повысить доступность и производительность сайтов.
• Использование технологий вроде HTMX и серверных фреймворков (Go, Rails, Django) позволяет реализовать сложные функции без тяжёлых клиентских библиотек.
• Проблемы с поддержкой старых браузеров и устройств часто решаются через полифиллы, ограничение функционала и fallback‑варианты.
• Успешные кейсы показывают, что правильный дизайн и понимание пользователей важнее выбора конкретного фреймворка.

Разработчики представили Hyperflask — новый фреймворк для Python, который объединяет множество инструментов в единую экосистему для ускорения разработки веб-приложений. Основная идея в том, чтобы избавить разработчиков от необходимости самостоятельно подбирать и настраивать различные технологии, которые часто требуются в проектах.

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

Ключевые возможности включают:

• Единая структура проекта: стандартизированная организация кода, что ускоряет onboarding новых разработчиков и упрощает поддержку.
• Готовые решения для типовых задач: аутентификация, отправка email, обработка файлов, фоновые задачи — всё доступно "из коробки".
• Гибридный рендеринг: статические страницы генерируются на сервере для скорости, но при необходимости могут динамически обновляться через HTMX.
• Оптимизация под SEO: серверный рендеринг гарантирует, что контент индексируется поисковыми системами.

Разработчики подчеркивают, что Hyperflask не просто набор инструментов, а целостная экосистема, где все части глубоко интегрированы. Это позволяет избежать типичных проблем, когда отдельные библиотеки, будучи собранными вручную, конфликтуют друг с другом.

Проект пока находится в стадии бета-тестирования, но уже доступен для использования. Основная команда состоит из разработчиков, ранее стоявших за популярными проектами в экосистеме Python, что говорит о серьезности намерений.

Для сообщества это может быть значимым, поскольку экосистема Python долгое время не имела полноценного аналога популярным JavaScript-фреймворкам вроде Next.js. Hyperflask, хоть и молодой проект, показывает важный шаг в этом направлении.

• Обсуждение в основном вращается вокруг сравнения Flask/HTMX-стека с альтернативами (FastAPI, Django, Litestar, FastHTML), где критика касается производительности, архитектуры и "state of the art" в 2025 году.
• Участники спорят о целесообразности смешивания шаблонов и логики в одном файле, о том, насколько это упрощает или усложняет разработку, и о том, как это сказывается на тестируемости и сопровождении кода.
• Ряд комментаторов поднимает вопрос о том, что выбор Flask в 2025 году может быть устарел, особенно если учесть отсутствие встроенной поддержки async/await, и сравнивает его с FastAPI или Litestar.
• Некоторые участники высказывают мнение, что вместо того, чтобы изобретать еще один каркас, было бы лучше взять существующий и внедрить в него улучшенную документацию, инструменты и лучшие практики.

Datastar — это «гипермедийный» фреймворк, который позволяет строить реактивные веб-приложения без JavaScript-кода. Он использует HTML-атрибуты и SSE-потоки для связи с сервером, а не JSON-API. Библиотека весит всего 10,75 КиБ и не требует сборки, что делает её идеальной для быстрого прототипирования. Примеры включают в себя чат-приложение, доска Kanban и т.д.

• Datastar и его автор Делани Гиллиан продвигают идею минималистичного подхода к веб-разработке, но критики указывают на то, что это может быть маркетинговым ходом, поскольку Pro-версия платная, а также что фреймворк может быть переоценённым решением, которое не решает фундаментальные проблемы веб-разработки.
• Обсуждение выявило, что Datastar не предоставляет никаких новых решений для проблем, с которыми сталкиваются разработчики, и вместо этого фокусируется на уже известных проблемах, таких как сложность, с которой сталкиваются разработчики, и не предлагает никаких новых решений.
• Участники обсуждения также подняли вопрос о том, что Datastar может быть не более чем просто ещё одним инструментом в арсенале веб-разработчика, и что его ценность может быть переоценена, в то время как другие инструменты, такие как HTMX и Alpine.js, могут предложить схожий функционал без необходимости платить за Pro-версию.
• Некоторые участники обсуждения также выразили обеспокоенность тем, что Datastar может быть не более чем попыткой монетизировать open-source проект, и что это может быть неэтичным, особенно если это не делает ясным, какие именно функции являются Pro-версией эксклюзивными.
• В конце концов, обсуждение подошло к выводу, что хотя Datastar и может быть полезным инструментом в определённых контекстах, его ценность может быть переоценена, и что его подход может не подходить для всех.

Автор перешёл с HTMX на Datastar, потому что последний убирает две проблемы: размер кода и сложность синхронизации фронтенда с бэкендом. Он показывает, что на практике это сокращает код на 60-70% и убирает необходимость вручную управлять состоянием на клиенте. Datastar заставляет сервер описывать, какие элементы и как должны обновляться, и это упрощает логику. Пример: вместо 3-4 атрибутов HTMX достаточно одного data-on-click. Это также убирает необходимость вручную следить за событиеми и состоянием, потому что вся логика находится в одном месте.

• Обсуждение в основном вращается вокруг сравнения Datastar и HTMX, где участники делятся опытом, спорят о том, какие фичи действительно нужны, и обсуждают, какие из фреймворков лучше подходят для разных сценариев использования.
• Несколько участников подчеркивают, что Datastar требует оплаты за ряд базовых функций, что вызывает сомнения в ценности продукта для open-source сообщества.
• Некоторые комментаторы высказывают, что Datastar и HTMX имеют разные подходы к обновлению контента: Datastar использует Server-Sent Events, в то время как HTMX использует обычные HTTP-запросы.
• Участники обсуждают, что Datastar требует больше кода на стороне сервера, в то время как HTMX позволяет легко обновлять различные части страницы без дополнительного кода.
• Некоторые комментаторы высказывают, что Datastar и HTMX имеют разные подходы к обновлению контента: Datastar использует Server-Sent Events, в то время как HTMX использует обычные HTTP-запросы.

HTMX предлагает декларативный подход к веб-разработке через HTML-атрибуты, что могло бы сократить потребность в JavaScript, если бы браузеры поддерживали такие семантики изначально. Однако автор отмечает, что HTMX не предоставляет чёткой структуры, подобной SPA-фреймворкам, что ведёт к риску создания спагетти-кода, как в случае с jQuery.

В ответ на это был создан MESH — фреймворк, сочетающий модульный SSR с гидрацией, где каждый компонент соответствует одному эндпоинту. Это позволяет писать бэкенд с фокусом на HTML, сохраняя ощущение работы с SPA. Для демонстрации использовались Go, Templ и Declarative Shadow DOM, с небольшим хаком для обхода ограничений HTMX внутри теневых DOM. Ключевая идея — обеспечить единственно верный способ структурирования кода, избегая хаоса.

• Обсуждается применимость HTMX для различных типов приложений: отличное решение для многостраничных приложений, но может быть неоптимальным для сложных SPA-подобных интерфейсов с интенсивным взаимодействием (например, drag-and-drop).
• Представлены альтернативные подходы и фреймворки: MESH (один эндпоинт на компонент), Data-Star (обновление по SSE), Blazor, Leptos, а также использование чистого JS или Web Components.
• Поднимаются технические нюансы HTMX: поведение по умолчанию при замене контента (innerHTML), обработка ошибок, ограничения парсера DOM при работе с Shadow DOM.
• Критикуется тенденция добавления абстракций поверх HTMX, что, по мнению части участников, противорит его философии простоты и возврата к истокам.
• Отмечается ценность HTMX и подобных инструментов как реакция на сложность современных JS-фреймворков и возможность быстрой разработки без сборки.