Hacker News Digest

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал Phoenix LiveView. Вместо того чтобы разделять фронтенд и бэкенд на разные стеки, он нашёл решение, которое позволяет писать всё на одном языке — Elixir. Это не только ускоряет разработку, но и даёт серьёзные преимущества в производительности.

Ключевые моменты:

• Меньше кода, меньше ошибок: Вместо двух кодовых баз (например, JavaScript + PHP) всё пишется на Elixir, включая UI-логику, что снижает вероятность ошибок.
• Реальное время без усилий: LiveView использует WebSockets для двухсторонней связи в реальном времени, что встроено "из коробки" и не требует дополнительных библиотек.
• Производительность и надёжность: Бэкенд на Elixir (работающем на Erlang VM) обеспечивает высокую конкурентность и отказоустойчивость. Фоновые задачи через Oban перезапускаются автоматически при сбоях.
• Единая архитектура: Нет необходимости в отдельном API или SPA, что упрощает разработку и развертывание.

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

• Обсуждение в основном вращается вокруг сравнения Rails, Phoenix и LiveView, но при этом всплывают факты, что Rails всё ещё умеет WebSocket, а Phoenix не так уж идеален, если нужен только CRUD-приложение.
• Участники спора подчеркивают, что выбор стека часто диктуется личными предпочтениями и опытом, а не объективными преимуществами.
• Несколько раз поднимается тема, что современные фреймворки всё ещё не решают проблему масштабирования и фоновых задач, и что важнее выбрать тот стек, который действительно подходит под задачу.
• Также обсуждается, что выбор инструмента влияет на набор библиотек и сообщество вокруг него, и это может быть важнее, чем абстрактные преимущества языка.

Microdot: крошечный веб-фреймворк для всего

Мигель Гринберг, автор Flask Mega-Tutorial, представил Microdot — мини-фреймворк, работающий и на CPython, и на MicroPython: от IoT до облаков.

Зачем?
Зимой 2018-го в Ирландии Мигель столкнулся с «умным» отоплением, которое погрешало на ±3 °C. Он отключил термостаты, поставил на каждый этаж плату с MicroPython и датчиком (±0,5 °C) и сам включал/выключал нагрев.
Чтобы с дивана видеть температуру и статус, ему нужен был веб-сервер, но Flask и Bottle на MicroPython не лезли. Поэтому он написал Microdot — «Flask в миниатюре».

Фишки

• одна папка, ~1500 строк, нулевые зависимости
• маршруты, шаблоны, cookies, WebSocket, SSE, CORS, SSL, Basic/Digest-аутентификация, тест-клиент
• копирует API Flask: @app.route, request.args, jsonify, abort, before_request
• работает на ESP32, Raspberry Pi Pico, обычных серверах
• ставится pip install microdot (CPython) или mip install microdot (MicroPython)
• опциональные плагины: microdot-session, microdot-cors, microdot-websocket, microdot-jinja, microdot-asyncio

Код

from microdot import Microdot
app = Microdot()

@app.route('/')
async def index(req):
    return {'temp': 22.5, 'heating': False}

app.run(port=80, debug=True)

Размер
ESP32: 70 КБ свободной ОЗУ остаётся после загрузки MicroPython + Microdot + приложение.
CPython: ~1 МБ venv.

Кому

• хобби-IoT: датчики, реле, роботы
• встраиваемые системы: промышленные контроллеры, автономные датчики
• прототипы: быстро поднять REST, потом перейти на Flask/FastAPI
• обучение: Flask-разработчики учатся за пять минут

Где
GitHub: github.com/miguelgrinberg/microdot
Документация: microdot.readthedocs.io
PyPI: pip install microdot

• Microdot — это 765-строковый Python-фреймворк, который работает и на CPython, и на MicroPython; предназначен для веб-серверов на IoT-устройствах (ESP32 и др.).
• Автор @miguelgrinberg подтвердил, что расширения (шаблоны, сессии) опциональны и почти не требуют зависимостей; версия 2 внесла ломающие изменения.
• Комментаторы спорят о слове «impossibly small»: кто-то считает 765 строк нормальным минимумом, кто-то — перебором; сравнивают с Bottle, Rails 0.x и FW/1.
• Пользователи делятся опытом: SSE + htmx для живых GPIO-индикаторов, бенчмарки RPS, проекты термостатов и садовых сенсоров.
• Упоминаются альтернативы (TurboLua, BirSaat) и вопрос: «почему бы не написать это на C?»

GNU Artanis — первый production-ready веб-фреймворк на Scheme. Лёгкий, быстрый, с поддержкой JSON/XML/SXML, WebSocket, i18n, MySQL/SQLite/PostgreSQL, кэширования, шаблонов и статики.

(use-modules (artanis artanis))
(init-server)
(get "/hello" (λ () "hello world"))
(run #:port 8080)

Скачать

• GNU FTP
• GitLab

Документация
Официальное руководство

Исходники

• Savannah: https://savannah.gnu.org/projects/artanis
• GitLab: https://gitlab.com/hardenedlinux/artanis

История
2013 — рождение на hack-potluck Guile; 2014 — награда «Lisp In Summer Projects»; 2015 — первая стабильная версия и вступление в GNU; 2021 — переход под крыло HardenedLinux.

Контакты
Почта: artanis@gnu.org
GitLab: https://gitlab.com/hardenedlinux/artanis

• Участники обсуждают фреймворк Artanis для Guile Scheme: кто-то хвалит простоту синтаксиса и встроенный веб-сервер, кто-то жалуется на отсутствие CSRF, 404-ссылок и слабое tooling.
• Почему Guile не стал популярен? Недостаток LSP, отладки, туториалов и узкая аудитория.
• Название «Artanis» — отсылка к Sinatra (Ruby) и палиндрому «Sinatra» задом-наперёд.
• Сайт без JS и шрифтов выглядит чисто, но кто-то считает текст слишком крупным и структуру странной.
• По безопасности: при грамотных разработчиках Scheme-системы могут быть безопаснее «обычных».