Hacker News Digest

Команда Skald переписала бэкенд с Python на Node.js всего через неделю после запуска, идя против стандартного совета стартапам сначала "делать то, что не масштабируется". Основная причина — сложность с асинхронностью в Python, особенно при работе с Django. Автор отмечает, что писать качественный асинхронный код на Python "очень сложно и неинтуитивно", в отличие от JavaScript с его event loop или Go с goroutines.

Django до сих пор не имеет полной поддержки асинхронности: нет нативного асинхронного файлового ввода-вывода, ORM не поддерживает async, а для интеграции синхронных и асинхронных функций требуется постоянно писать sync_to_async и async_to_sync. Даже крупные компании вроде PostHog, несмотря на наличие AI-фич, продолжают использовать традиционный WSGI вместо полного перехода на асинхронность. В итоге команда пришла к выводу, что Django скоро начнет создавать проблемы с производительностью даже при небольшом количестве пользователей.

• Обсуждение в основном вращается вокруг того, что Python/async-экосистема остаётся незрелой, а Django-ORM не предназначена для асинхронной работы, что делает выбор между «старым, но проверенным» и «новым, но сырым» неоднозначным.
• Участники спорят, стоит ли жертвовать удобством разработки и экосистемой ради производительности, или же лучше переписать всё на Node/TypeScript, если речь идёт о высоконагруженном REST API.
• Поднимается вопрос о том, что выбор стека влияет на набор инженеров, и что важнее — удобство разработки или производительность.
• Некоторые участники подчеркивают, что важно не только выбрать правильный инструмент, но и уметь его использовать, иначе даже самый современный фреймворк не спасёт от проблем с масштабированием.

Разработчик создал одно и то же мобильное приложение 10 раз на разных фреймворках, чтобы сравнить их производительность. Новые фреймворки (Marko, SolidStart, SvelteKit, Qwik) показывают практически мгновенную загрузку с временем First Contentful Paint в диапазоне 35-39мс, что в 12-13 раз быстрее, чем у Next.js. Реальная разница между лидерами минимальна — все они ощущаются как мгновенные, а ключевым фактором становится размер бандла.

Марко стал чемпионом по размеру бандла, достигая всего 28.8 kB в сжатом виде, что в 6.36 раза меньше, чем у Next.js (176.3 kB). Qwik City использует паттерн "возобновляемости", устраняя традиционную гидратацию и обеспечивая мгновенную интерактивность для крупных клиентских приложений. Автор рекомендует выбирать фреймворки на основе приоритетов проекта, а не микро-разниц в метриках производительности.

• Svelte/SvelteKit и Solid/SolidStart показали наилучшую производительность и удобство разработки, особенно в мобильных условиях.
• React критикуют за фундаментальные проблемы производительности и большие размеры бандлов, несмотря на его популярность.
• Многие разработчики предпочитают использовать знакомые стеки (например, Django/React) вместо поиска "самого быстрого" решения, ценя скорость и комфорт разработки.
• Статья вызвала споры о важности оптимизации для мобильных устройств и критику за игнорирование нативных разработок и PWA.
• Стиль и содержание статьи были раскритикованы как "ChatGPT-slop" за шаблонность и отсутствие глубины.

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

Команда Wasmer анонсировала бета-поддержку Python в своей edge-платформе на базе WebAssembly. Это позволяет запускать популярные фреймворки вроде FastAPI, Django и Streamlit, а также библиотеки типа numpy и pandas — всё в песочнице с почти нативной производительностью. Ключевые улучшения включают динамическую линковку, поддержку сокетов, потоков и собственный индекс пакетов.

Производительность впечатляет: тесты показывают, что Python на Wasmer работает всего на 5% медленнее нативного, при этом обеспечивая изоляцию и портативность. Платформа уже обгоняет Cloudflare по поддержке мультитрединга и нативных модулей, а вскоре добавит полную поддержку PyTorch и других тяжёлых библиотек.

• Запуск Python в WebAssembly через Wasmer предлагает производительность, близкую к нативной, и обеспечивает надежную песочницу для выполнения кода.
• Обсуждаются практические применения: встраивание скриптов в приложения, серверные API (FastAPI, Django) и выполнение пользовательского кода в изоляции.
• Поднимаются вопросы о поддержке ключевых библиотек (numpy), асинхронности (asyncio) и межъязыкового взаимодействия (Python-JS).
• Отмечаются существующие альтернативы (Pyodide, контейнеры) и сложности с зависимостями, имеющими нативные расширения.
• WASM рассматривается как более простая и легковесная альтернатива виртуальным машинам и контейнерам для развертывания.

Сервис позволяет создавать RSS-ленты из любого сайта, указывая CSS-селекторы для заголовков, описаний и ссылок. Пользователь вводит URL, задаёт название фида и выбирает элементы для парсинга — например, самые читаемые статьи Washington Post или джазовые обзоры на Bandcamp.

Можно включать метаданные, обрезать параметры ссылок и тестировать результат перед генерацией. Инструмент полезен для автоматизации подписок на контент, который изначально не поддерживает RSS, или для создания персонализированных дайджестов.

• Обсуждаются различные инструменты и подходы для создания RSS-лент из веб-страниц, включая самописные скрипты, готовые решения и использование XSLT.
• Поднимаются вопросы о весе зависимостей (например, Django), производительности и возможности бесплатного хостинга на платформах вроде Cloudflare Workers.
• Участники делятся альтернативами, такими как RSS-Bridge, FreshRSS и инструменты для парсинга HTML с помощью CSS-селекторов.
• Обсуждаются технические детали RSS/Atom, такие как необходимость GUID и дат для совместимости с читалками.
• Отмечаются проблемы с надежностью подобных инструментов на современном вебе, включая некорректную работу режима чтения в браузерах.

• Async в Python уже 10 лет, но до сих пор не стал мейнстримом.
• Причины:
  • ошибки «забыл await», трудно отлаживать;
  • GIL приучил не думать о параллелизме;
  • польза только при I/O-задачах, CPU-нагрузка не ускоряется;
  • фреймворки не догнали: Django ORM всё ещё синхронен, Flask тоже.
• Классический кейс — HTTP-запросы: стартуем сотни корутин, ждём ответов, не блокируем интерпретатор.
• Но дисковый I/O, CPU-задачи и другие сценарии не так выигрывают.
• Вывод: чтобы новые фичи 3.14 (free-threading, sub-interpreters) не повторили судьбу async, нужно:
  • чётко объяснять, какие задачи они решают;
  • давать простые API и инструменты отладки;
  • не ждать, пока экосистема «догонит», а сразу внедрять в популярные библиотеки.

• Async в Python пришёл «слишком поздно»: к моменту появления asyncio большинство уже решали задачи I/O через forking, multiprocessing или сторонние библиотеки.
• «Цветные функции» и необходимость переписывать весь код ради async делают его «заразным» и несовместимым с существующими синхронными библиотеками.
• Сложная семантика (event-loop, await, cancellation-исключения), плохая документация и отсутствие понятных best-practice усложняют отладку и поддержку.
• Для большинства задач Python-разработчика async не критичен: WSGI/WSGI-совместимые решения, Celery, Kafka и простое горизонтальное масштабирование покрывают потребности.
• Альтернативы (trio, anyio, gevent) и другие языки (Go, Elixir) предлагают более простые модели конкурентности без «раскрашенных» функций.

Next.js выводит из себя

Наконец-то написал пост: злость лучший мотиватор.
В $COMPANY упал сервис на Next.js, а логов в проде нет. Задача — добавить логирование.

Middleware
Дока обещает: «Middleware выполняется до рендера, удобно для логов».
Пробуем pino + AsyncLocalStorage:

// middleware.ts
export async function middleware(req: NextRequest) {
  LoggerStorage.enterWith(requestLogger());
  logger()?.debug({ url: req.url }, "start");
  return NextResponse.next();
}

Запускаем — логи летят в браузер. Почему? Runtime по умолчанию edge. Меняем на nodejs — в новом проекте работает, в боевом нет.

Страницы и layouts
Пишем в компоненте:

logger()?.info("from page");

Тишина. logger() возвращает null: рендер и middleware живут в разных async-контекстах.

Решение
Передаём requestId через заголовки:

// middleware.ts
const id = crypto.randomUUID();
loggerInstance.child({ requestId: id }).debug("start");
return NextResponse.next({ headers: { "x-request-id": id } });

// page.tsx
const id = headers().get("x-request-id");
loggerInstance.child({ requestId: id }).info("from page");

Итог: чтобы просто логировать, нужно городить костыли через заголовки.

• Пользователи жалуются на игнорирование сотен старых issue, перегруженность абстракциями и постоянные «канареечные» решения, которые не доходят до продакшена.
• Сообщество считает Next.js «самой худшей» технологией: сложно понять, где выполняется код, нельзя цепочкой middleware, а апи-шлюзы выглядят «как будто их писали выпускники буткемпа».
• Разработчики предлагают уходить на Remix, React Router v7, Nuxt, SolidStart, Deno Fresh или даже «чистый HTML/CSS» ради простоты и контроля.
• Представитель Vercel признаёт DX-проблемы и обещает улучшения, но многие уже мигрируют на Vite или Django/Rails/Phoenix.

PlutoPrint — библиотека Python для генерации PDF и изображений из HTML, работает на базе PlutoBook.
Установка: pip install plutoprint.

Основные возможности

• HTML → PDF/PNG/JPEG — одна строка кода.
• CSS/JS — полная поддержка современных стандартов.
• Шаблоны — Jinja2, Django, Flask и др.
• Пакетная обработка — асинхронный режим.
• Docker-образ для быстрого деплоя.

Быстрый старт

from plutoprint import PlutoPrint

pp = PlutoPrint()
pp.html_to_pdf("report.html", "report.pdf")

Параметры

• format: pdf, png, jpeg
• width/height, orientation, margin, header/footer, dpi

Примеры

• Отчёты, чеки, инвойсы, почтовые этикетки, скриншоты страниц.

Лицензия

MIT.

• Пользователи сравнивают PlutoPrint с WeasyPrint, Puppeteer и Typst: новый движок на C++ обещает быть быстрее и легче по памяти, но покрывает не весь CSS.
• Рекомендуют прогнать тесты с print-css.rocks и проверить прод-качество (проблемы с thead, page-break-inside и т.д.).
• Puppeteer даёт полную поддержку веб-платформы, но требует Chromium и много RAM, особенно для 200-500-страничных PDF.
• Есть вопросы по flexbox, SVG, оглавлению, поддержке Markdown и крэшу на macOS.
• Несколько человек рассматривают PlutoPrint как замену wkhtmltopdf и fpdf, автор открыт к спонсорству.

Qodo Command набрал 71,2 % на SWE-bench Verified — стандартном бенчмарке для оценки способности агентов решать реальные задачи из GitHub.

• SWE-bench Verified включает 500 задач из 12 популярных репозиториев (Django, scikit-learn, sympy и др.).
• Каждая задача: описание бага/фичи + тест, который должен проходить после исправления.
• Оценивается только успешность прохождения тестов; стиль и качество кода не учитываются.

Результаты

• 71,2 % — новый рекорд среди публичных решений.
• +18,2 п.п. от предыдущего лидера (CodeStory Aide).
• +31,2 п.п. от первого релиза SWE-bench (2023).

Ключевые инсайты

• Контекст важнее модели: использование 128k-токенного окна и RAG-поиска по 500+ файлам дало +12 %.
• Итерации решают: 3–5 попыток сборки/тестов повышают успех на 8 %.
• Маленькие PR легче: задачи <30 строк кода решаются в 84 % случаев, >200 — лишь 38 %.

Что дальше

• Публикация детального тех-отчёта и открытого датасета.
• Расширение до 1 000 задач и добавление новых языков (Go, Rust).

• Qodo показал 71,2 % на SWE-bench-verified — 5-е место, всего на 1 % уступая официальному Claude Sonnet 4.
• Участники сомневаются в честности результатов и просят независимую платформу с peer-review.
• Поднимаются вопросы о стоимости, эффективности, размере модели и специфике подготовки именно под тест.
• Обсуждают, что сам бенчмарк «закрыт» для Python-ошибок и не отражает реальную разработку.
• Некоторые уже отказались от Qodo в пользу BugBot и сомневаются в жизнеспособности «обёрток» над LLM.

• Несколько лет назад мне выпал шанс выбрать 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-референса и переизбыток туториалов.