Hacker News Digest

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

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

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

Cap'n Web — это новая система RPC для браузеров и веб-серверов, созданная Cloudflare на чистом TypeScript. Она наследует философию объектно-ориентированных возможностей (object-capability) от Cap'n Proto, но оптимизирована для веб-стека: использует JSON для сериализации, работает поверх HTTP, WebSocket и postMessage(), весит менее 10 КБ и не требует схем или шаблонного кода. Поддерживает двусторонние вызовы, передачу функций и объектов по ссылке, а также конвейеризацию промисов для сокращения задержек.

Настройка занимает буквально несколько строк: клиент подключается через WebSocket, а сервер реализуется как класс с методами, которые автоматически становятся удалёнными процедурами. Например, метод hello(name) на сервере можно вызвать из браузера как api.hello("World"). Система интегрируется с TypeScript для типобезопасности и работает в Cloudflare Workers, Node.js и современных браузерах. Это делает распределённое программирование почти неотличимым от локального, с учётом сетевых реалий.

• Обсуждение Cap'n Web как упрощённой, schemaless версии Cap'n Proto RPC для TypeScript/JavaScript с поддержкой передачи функций и двусторонних вызовов.
• Сравнение с другими технологиями: проводятся параллели с GraphQL (решение проблемы N+1, но без DataLoader), tRPC/ORPC (схемы vs schemaless), gRPC-web (сложность) и старыми системами вроде Java RMI или .NET Remoting.
• Подняты вопросы о безопасности (риски из-за отсутствия схем и передачи произвольных колбэков), состоянии сервера (статусность vs статусность) и проблемах отладки (сложность отслеживания сетевых запросов).
• Обсуждаются технические детали: пайплайнинг промисов для уменьшения RTT, выполнение .map() на сервере через DSL, управление памятью и сборкой мусора для долгоживущих соединений.
• Запросы на расширение: поддержка других языков (Rust, Elixir), стриминг, генераторы, версионирование API и бинарная совместимость с Cap'n Proto.

CLI-инструменты часто зависят от платформы/версии, плохо документированы и ломаются при не-ASCII вводе. Агенты путаются в управлении состоянием (например, tmux-сессиями) и теряют контекст после мелкой ошибки. Каждый вызов ещё тормозит из-за предварительной проверки безопасности.

Композиция в CLI работает через bash: цепочки tmux send-keys, sleep, base64 и т.д. MCP сегодня так не умеет.

Выход — MCP-сервер с одним «убер-инструментом»: Python-интерпретатор, сохраняющий состояние между вызовами. Пример — pexpect-mcp: виртуальное окружение + pexpect, позволяющее скриптами управлять интерактивными CLI-программами. Вместо 30 отдельных MCP-функций достаточно одной, принимающей код.

• Участники спорят, нужен ли MCP (Model Context Protocol): кто-то считает его лишним слоем, другие — полезным способом дать LLM структурированные инструменты.
• Критика: MCP ограничивает агента набором команд, не решает безопасность, дублирует OpenAPI и заставляет LLM учиться новому формату вместо bash/API.
• Альтернативы: прямое обращение к HTTP/CLI/WebSocket (UTCP), YAML-описание тулов (hooks_mcp), eval в песочнице (runjs, Bubblewrap).
• Практические проблемы: при 100+ тулов агент путается; приходится писать кучу обвязок вместо «просто вызвать API».
• Общий вывод: MCP пока выглядит сыро, требует лишних усилий и не даёт очевидных преимуществ перед строками/bash/API.

Как работает технология «мультиплеера» в Figma

Основная идея
Figma позволяет десяткам дизайнеров одновременно работать над одним файлом без конфликтов. Это достигается за счёт оперативной синхронизации изменений и разрешения конфликтов на лету.

Архитектура

• WebSocket-соединение — каждый клиент держит постоянное соединение с сервером.
• Операционные преобразования (OT) — любое действие (перемещение слоя, изменение текста) описывается как операция. Сервер применяет её и рассылает всем клиентам.
• Дельты и патчи — вместо полной передачи файла отправляются только изменения, что экономит трафик и ускоряет работу.

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

Производительность

• Дерево объектов хранится в памяти браузера и обновляется по мере поступления операций.
• Сжатие и батчинг — несколько операций объединяются в один пакет, чтобы снизить нагрузку на сеть.
• Кеширование — сервер хранит последние состояния файлов, чтобы быстро «догнать» клиента, который только подключился.

Безопасность и надёжность

• Все операции логируются и могут быть отменены (undo/redo).
• Данные шифруются при передаче и хранятся в зашифрованном виде.
• Регулярные снепшоты защищают от потери данных при сбоях.

Итог
Технология «мультиплеера» превращает Figma в «Google Docs для дизайна», где коллаборация происходит без конфликтов и задержек.

• Участники делятся ссылками на материалы Linear, Automerge, Croquet и другие решения для реал-тайм синхронизации.
• Обсуждают, насколько сложной остаётся задача и какие новые инструменты (Liveblocks, Electric SQL, Rocicorp Zero) делают её доступнее.
• Спорят о терминологии «multiplayer» и о том, насколько часто пользователи действительно одновременно редактируют дизайн.
• Отмечают, что Figma пошла на радикальные меры: собственный WebGL-рендерер и протокол, отказавшись от готовых библиотек.
• Шутят о случайном переключении сайта из тёмной в светлую тему при прокрутке и о «figma balls».

Начав использовать Linear, я углубился в «локально-ориентированные» приложения: клиент хранит полную БД, изменения сначала пишутся локально, а фоновый sync-рантайн рассылает их по WebSocket/GraphQL. Пользователь видит мгновенные обновления без сетевой задержки.

Проанализировав реверс-инжиниринг и доклады команды Linear, я понял: их sync-движок — это месяцы работы, чтобы решить офлайн-режим, конфликты, частичную синхронизацию, миграции схем и безопасность.

В 2025-м экосистема уже готова:

• Electric SQL — Postgres-синхронизация
• PowerSync — корпоративный уровень
• Jazz — «обновляешь локальный state — всё синхронизируется»
• Zero, Instant, Triplit, LiveStore — упрощают разработку

Jazz предлагает CoValues: схема на Zod + автоматическая репликация. Пример:

const Post = co.map({
  title: z.string(),
  comments: co.list(Comment)
});

Меняешь post.title — изменение мгновенно отражается у всех участников.

• Участники обсуждают преимущества и недостатки подходов local-first (Zero, Electric, Jazz, CRDT, PouchDB, Turso и др.).
• Ключевые плюсы: мгновенный UX, офлайн-работа, упрощённая синхронизация через запросы (Zero) и отсутствие конфликтов (CRDT).
• Минусы: рост данных, проблемы разрешения конфликтов, сложность прав и миграций, ограниченная поддержка SSR-ценящих разработчиков.
• Некоторые считают, что SSR всё ещё важен для первой загрузки, но не решает офлайн/коллаборацию.
• Подводный камень: большинство инструментов заточены под веб, хотя мобильные сценарии офлайна выглядят более естественными.