Hacker News Digest

• HTMX — это не мем и не анти-JS, а просто библиотека, которая расширяет HTML без отказа от JavaScript.
• Аргумент «10 МБ WASM» сводится к «загрузка кода на клиенте — это не проблема, если использовать Service Worker.
• «Local first» не означает «без сервера», а лишь убирает синхронизацию состояния, оставляя серверную логику на клиенте.
• Под капотом HTMX остаётся обычный запрос-ответ, просто вместо JSON в DOM вставляется HTML-фрагмент.
• Дискуссия свелась к тому, что критика не в том, что HTMX плох, а в том, что пример не показывает, как реальные приложения выглядят.

Carson Gross объявляет о выходе htmx 4.0, вопреки предыдущему обещанию не делать версии 3.0. Основные изменения включают переход с XMLHttpRequest на fetch() как основную AJAX-инфраструктуру, что изменит модель событий. Также неявное наследование атрибутов станет явным через модификатор :inherited, а поддержка истории откажется от локального кэширования DOM в пользу сетевых запросов, что упростит код и повысит надежность.

Большинство основных функций (hx-get, hx-post, hx-target и т.д.) останутся без изменений. Автор признает, что обновление до 4.0 потребует больше усилий, чем переход с 1.0 на 2.0, но обещает perpetual поддержку htmx 2.0. Эти изменения направлены на долгосрочную устойчивость проекта и снимут давление с версий 2.0, позволив им сосредоточиться на стабильности.

• HTMX 2.0 будет поддерживаться бесконечно, поэтому нет необходимости обновляться, если он вам подходит.
• Автор признал, что придется выпустить HTMX 4.0, чтобы не нарушить обещание не делать HTMX 3.0.
• Пользователи обсуждают, стоит ли переходить на 4.0 или остаться на 2.0, который будет поддерживаться вечно.
• Некоторые считают, что Datastar более функционален и удобен, но он не open-source и может быть закрыт в любой момент.
• Появились вопросы о том, какие именно изменения в 4.0 делают его лучше 2.0, и стоит ли переходить на него.

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

В репозитории содержатся скрипты для работы с базой данных и веб-интерфейсы для взаимодействия с ней. Автор использует этот проект как пример того, как можно организовать собственные данные и доступ к ним через веб-приложения. Код проекта доступен для изучения и возможного использования другими разработателями.

• Сторонники подхода "база данных как единственный источник истины" приводят примеры от 2007 года до сегодняшнего дня, показывая, что идея не нова, но вот вдохновение от неё пришло к Дереку Сиверсу, который в свою очередь вдохновил обсуждение на Hacker News.
• Обсуждение затрагивает вопросы от "что если вся логика в БД" до "какие ещё нестандартные инструменты могут подхватить эстафету", включая ссылки на PostgREST и Supabase как современные эквиваленты идеи.
• Участники делятся личным опытом, от 2007 года до сегодняшнего дня, подчеркивая, что подход был популярен в ранних 2000-х и что он до сих пор может быть применим для новых проектов.
• Поднимается вопрос о том, как и где хранятся шаблоны и как они попадают в ответы сервера, а также обсуждается использование таких инструментов как HTMX или Datastar для гидратации через гипермедиа.
• В конце концов, обсуждение сводится к тому, что идея остаётся актуальной, и участники выражают надежду, что она может вдохновить следующего поколения разработчиков так же, как это сделал Rich Hickey со своим докладом "Simplicity Matters".

Разработчики представили 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-фреймворков и возможность быстрой разработки без сборки.

Jetzig — веб-фреймворк на Zig, MIT-лицензия.
Маршруты по файлам, REST из коробки.
Шаблоны Zmpl: лейауты, partials, статика на этапе сборки.
JSON-ответ по умолчанию.
Движок http.zig = высокая скорость.
CLI создаёт проекты и компоненты.
Цепочка middleware, встроенная поддержка htmx.
Куки, сессии, заголовки — без кода.
ORM JetQuery для баз данных.
Сообщество в Discord, исходники на GitHub.

• Jetzig — новый Zig-фреймворк для веба: single-бинарник, статическая типизация, маршруты через структуры, напоминает Django.
• Название играет по-немецки: «jetzig» ≈ «сейчас-вроде» (now-ish), как у Zeit/Now.sh.
• Под капотом http.zig, значит пока только HTTP/1.1; RESTful на словах, но по факту JSON-RPC.
• Видео-вводилка уже есть, комьюнити хвалит «правильные» решенийки, но докопались до баннера куки на localhost.
• JetQuery даёт compile-time безопасность имён полей — если переименуете член структуры, код не соберётся.

• Несколько лет назад мне выпал шанс выбрать async‑first, типизированный Python‑фреймворк для веба. Я взял Litestar — без хайпа и ракет в твитах — и не пожалел: уже около 18 месяцев все мои новые рабочие проекты на нём.

• Даже если вы пишете асинхронные веб‑приложения на Python, вы могли пройти мимо Litestar. Хочу это исправить.

• Вкус демо: простой файл

  from litestar import Litestar, get
  
  @get("/greet")
  async def greet(name: str) -> str:
      return f"Hi, {name}!"
  
  app = Litestar([greet])
  

  Запускаете через litestar run или любой ASGI‑сервер. /greet?name=Bob вернёт «Hi, Bob!». Без name — HTTP 400: параметр обязателен. Да, похоже на FastAPI и на знакомые по Spring/ASP.NET MVC подходы с аннотациями — и FastAPI тоже так умеет. Но у Litestar есть свои сильные стороны.

• Про название: раньше проект назывался Starlite, потому что изначально строился на Starlette (как и FastAPI). Позже зависимость убрали, а чтобы не путать со Starlette, в релизе 2.0 (2023) переименовали в Litestar.

• Масштабирование кода, а не трафика:

  • Django плохо «масштабируется вниз»: «правильный» старт быстро разрастается в десяток файлов и папок. Однофайловые трюки работают, но против шерсти.
  • Микрофреймворки — наоборот: стартуют в одном файле, но по мере роста кода расползаются и начинают мешать.
  • В FastAPI маршруты обычно вешаются декораторами на объект приложения. Это удобно в одном файле, но при разбиении на модули ведёт к циклическим импортам. Решение — «вторичные» реестры маршрутов (APIRouter, blueprint): нужны, потому что декораторы привязаны к app. Litestar же позволяет описывать обработчики отдельно и передавать их приложению списком, что естественно масштабируется от одного файла к структуре проекта без костылей.

• Обсуждение сравнивает FastAPI, Litestar, Starlette и Django для построения бекендов: многие отмечают, что FastAPI удобен для простых сервисов, но усложняется в больших кодовых базах, тогда как Litestar воспринимается более продуманным и быстрым для сложных API.
• Несколько участников хвалят Litestar: высокая скорость, асинхронность, first-class msgspec, контроллеры для вложенных роутов, кеширование, плагины (в т.ч. для HTMX), и развивающийся Advanced Alchemy; отмечают, что у него больше одного мейнтейнера.
• Часть разработчиков предпочитает Starlette как легковесную основу без «всей кухни», а Django ценят за ORM; обсуждают плюсы/минусы SQLAlchemy и альтернативы (peewee), а также идею разделять модели API и БД с самого начала.
• Критика FastAPI касается структуры кода, управления зависимостями и разрыва между туториалами и реальными практиками; при этом приводят ссылки на репозитории-референсы, где показано, как масштабировать FastAPI.
• Запросы и сомнения: как обрабатывать ошибки при стриминге, как деплоить (NGINX Unit упоминался как «капризный»), и нужен ли референс-проект Litestar; приводят litestar-fullstack как пример.
• В целом тон дискуссии: многие либо мигрируют с FastAPI на Litestar, либо довольны Starlette; документацию нового поколения фреймворков часто критикуют за недостаток строгого API-референса и переизбыток туториалов.

I enjoyed reading this. It follows a similar experience with our first htmx website, away from using modern frontends, or just simple jQuery with ajax json data.I remember, working with a co-worker, we planned out the process (a step-by-step on the application like this post) and