Hacker News Digest

PrinceJS позиционируется как самый быстрый фреймворк для Bun, демонстрируя впечатляющую производительность в 19,200 запросов в секунду при размере всего 2.8 килобайта. Эта сверхлегкая реализация делает его идеальным выбором для высоконагруженных приложений, где важна каждая миллисекунда и каждый байт. Фреймворк сохраняет при этом простоту использования и функциональность, необходимую для разработки современных веб-приложений.

Разработчики подчеркивают, что PrinceJS достигает такой производительности благодаря минималистичному подходу и отсутствию избыточных абстракций. Несмотря на крошечный размер, фреймворк включает все необходимые функции для создания REST API и веб-приложений. Это делает его привлекательной альтернативой более крупным фреймворкам, таким как Express.js или Fastify, особенно для проектов, где критически важны скорость и эффективность.

• Пользователи отмечают, что 13-летний разработчик из Нигерии создал фреймворк, который по производительности превосходит Express и Fastify, но при этом не поддерживает wildcard-роутинг и не имеет тестов.
• Сообщество обсуждает, что примерно 20 тыс. запросов в секунду для простого эндпоинта — это не рекорд, но при этом нет никакой информации о том, какие именно фичи отсутствуют и какие баги могут быть в таком фреймворке.
• Некоторые участники обсуждения отмечают, что фреймворк не имеет тестов и не ясен вопрос, как он будет вести себя в продакшене.
• Участники также отмечают, что в документации фреймворка нет информации о том, какие именно фичи он поддерживает, и какие из них отсутствуют.

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

Краткий пересказ:
lavandula — это минималистичный веб-фреймворк на C, который обещает «скорость C и удобство Python». Проект с открытым исходным кодом, лицензия MIT. Сейчас он находится в стадии альфа-тестирования: базовый роутинг, middleware, JSON-ответы и простой шаблонизатор уже работают. Пример «Hello, world» компилируется в 12 КБ статического бинарника, а полноценный REST API сервис — меньше 100 КБ.

Планы: добавить встроенный ORM, WebSocket и SSE, а также CLI-генератор проектов. Поддержка Windows пока нестабильна, но Linux и macOS уже можно использовать. Сообщество приветствует вклад: обсуждение ведётся в Discussions, а примеры кода и бенчмарки публикуются в репозитории.

• Проект получил похвалу за чистоту и современный стиль кода, но также вызвал споры о практичности и безопасности C-фреймворков.
• Участники обсуждали, насколько целесообразно писать веб-приложения на C, и поднимались вопросы о безопасности и удобстве использования.
• Некоторые отметили, что проект может быть полезен для обучения и как отправная точка для других языков или фреймворков.
• Были также упоминания о том, что проект может быть развит с добавлением функций вроде шаблонизатора или поддержки HTTPS.
• Некоторые комментарии подчеркнули важность тестов и обработки ошибок в коде, а также отметили, что проект может быть использован как основа для других языков или фреймворков.