Hacker News Digest

Предоставленный фрагмент содержит навигационное меню сайта Heroku, но не содержит самой статьи о поддержке .NET 10 LTS. В разделе "Languages" упоминается .NET как один из поддерживаемых языков, но нет конкретной информации о версии 10 LTS или детальных технических деталей.

В меню также есть ссылки на различные продукты Heroku, включая Heroku Platform, Heroku AI, Heroku Data Services, Heroku Enterprise и Heroku Elements Marketplace, что указывает на широкий спектр услуг платформы. Однако без доступа к полной статье о поддержке .NET 10 LTS невозможно предоставить точный пересказ её содержания.

• Обсуждение началось с жалоб на стоимость Heroku, которая оказалась выше AWS даже с учетом DevOps-инженера.
• Участники вспомнили, что Heroku когда-то был первым выбором для MVP и мелких проектов, но теперь у них есть альтернативы вроде Vercel и Netlify.
• Разговор перешел к тому, что экосистема .NET и инструменты вроде Cloud Native Buildpacks всё ещё открыты и могут быть использованы где угодно.
• Несколько человек отметили, что даже несмотря на то, что Heroku всё ещё работает, он уже давно не является конкурентоспособным вариантом для большинства проектов.

Vercel представил Workflow DevKit — библиотеку, добавляющую надёжность, устойчивость и наблюдаемость в асинхронный JavaScript. С помощью простого директивного подхода "use workflow" разработчики могут превращать обычные TypeScript-функции в долговременные процессы, способные приостанавливаться, возобновляться и сохранять состояние. Это устраняет необходимость в ручной реализации очередей и механизмов повторных попыток.

Библиотека предлагает декларативный API для определения и использования рабочих процессов, поддерживает шаги с директивой "use step" и предоставляет встроенные инструменты наблюдаемости — отслеживание выполнения, возможность паузы, повтора и "путешествия во времени" по шагам с автоматическим сбором трассировок, логов и метрик. Код работает одинаково на локальной машине, в Docker, на Vercel или любом другом облаке, обеспечивая переносимость без привязки к платформе.

• Обсуждение в основном крутится вокруг критики Vercel Workflow за то, что он представляет собой еще один слой абстракции, который скрывает детали реализации и ограничивает прозрачность, а также заставляет разработчиков использовать магические строки вроде "use workflow", что делает код менее читаемым и более трудным для отладки.
• Участники также отмечают, что это похоже на попытку создать vendor lock-in, поскольку Workflow требует специфичной для Vercel инфраструктуры, и что это может быть частью более широкой тенденции к созданию проприетарных инструментов вместо использования открытых стандартов.
• Некоторые участники также высказывают сомнения в том, что Vercel Workflow может быть не более чем оберткой вокруг очередной системы очередей/конечных автоматов, и что это может быть не более чем попытка создать vendor lock-in.
• Также поднимается вопрос о том, что если бы Vercel предоставил бы возможность самостоятельно хостить "Workflow" движок, это могло бы быть более приемлемо для сообщества, и что это могло бы быть шагом в сторону открытости и само-хостинга.

Пользователь работает с несколькими моделями одновременно, каждая из которых выполняет атомарные коммиты. Основной стек — TypeScript и React, развернутый на Vercel.

Основная идея — использование инструмента codex (предположительно, внутренний инструмент или API) в качестве основного драйвера для разработки. Вместо того чтобы писать код вручную, пользователь использует несколько экземпляров codex (до 8 одновременно), каждый из которых работает над своей частью задачи. Каждый агент коммитит изменения самостоятельно, что позволяет поддерживать чистую историю.

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

• Контекст и координация. Несмотря на то, что агенты работают параллельно, пользователь тщательно управляет их работой, чтобы избегать конфликтов. Например, при работе над крупными изменениями он сначала запускает один агент для оценки, а затем уже основную группу.
• Инкрементальный подход. Вместо того чтобы пытаться решить все сразу, пользователь разбивает задачи на мелкие, атомарные шаги. Например, при обновлении зависимостей он не просто запускает скрипт, а сначала проверяет каждое изменение, затем тестирует, и только потом обновляет.
• Отказ от излишеств. Пользователь избегает сложных систем вроде прекоммит-хуков для валидации, так как они замедляют процесс. Вместо этого он полагается на то, что агенты достаточно умны, чтобы не допускать ошибок.
• Практичность. Инструменты выбираются по принципу "работает — не трогай". Например, codex используется вместо Claude Code, потому что последний стал слишком абстрактным (например, он может часами "думать" над простой задачей). codex же просто делает.

В целом, подход напоминает принцип "двигайся быстро и не ломай" (move fast and don't break things), но с уклоном в "двигаться быстро", даже если иногда что-то сломается. Это компенсируется скоростью: один агент может заменить целую команду, и даже если он ошибся, это быстро фиксится.

• Дискуссия разделилась на два лагеря: «AI пишет почти весь код» против «никакой AI не заменит разработчика»; при этом обе стороны сходятся в том, что важно уметь читать и ревьюить весь код, независимо от того, кто его написал.
• Участники обсуждали, что 300k строк кода, которые, как утверждается, были написаны ИИ, на самом деле могут быть просто увеличены в 10-15 раз по сравнению с тем, что написал бы человек, и что это вызывает сомнения в надёжности такого подхода.
• Поднимался вопрос о том, насколько можно доверять ИИ-написанному коду, и какие именно навыки требуются, чтобы эффективно использовать такие инструменты.
• Также обсуждалось, что важно ли вообще писать статьи о таких инструментах, если они не раскрывают, как именно они используются, и какие именно задачи они решают.

После публикации результатов тестов, показывающих, что Cloudflare Workers значительно уступают по производительности Vercel, команда Cloudflare проанализировала тест и обнаружила ряд факторов, повлиявших на результат.

Во-первых, выяснилось, что в тесте использовалась более старая версия Cloudflare Workers, которая не была оптимизирована для этого конкретного типа нагрузки. Cloudflare немедленно выпустила обновление, улучшающее производительность.

Во-вторых, в тесте использовалась библиотека, которая вносила дополнительные накладные расходы на стороне Cloudflare, но не на стороне Vercel. После замены библиотеки на более оптимизированную, разница в производительности значительно сократилась.

Кроме того, команда обнаружила, что тест не полностью изолировал переменные — часть замедления была вызвана сетевыми задержками, а не производительностью самого Workers. После настройки теста для измерения только времени выполнения кода, разница стала минимальной.

В конечном счете, Cloudflare удалось не только догнать, но и превзойти Vercel по некоторым показателям, просто устранив узкие места в своем стеке.

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

• Cloudflare и Vercel продолжают обмениваться тестами и оптимизациями, но вместо обвинений они фактически сотрудничают, чтобы улучшить свои продукты.
• Стороны соревнуются в прозрачности: Cloudflare публикует исходные данные теста, а Vercel делает тот же тест открытым исходным кодом.
• Сообщество отмечает, что обе платформы теперь демонстрируют лучшую производительность, чем раньше, и что конкуренция в конечном счете выгодна для пользователей.

Meta и Linux Foundation запустили React Foundation — новый дом для React и React Native. Фонд возьмёт на себя инфраструктуру, конференции и финансирование экосистемы, а техническое руководство останется в руках команды React. Meta вложит $3 млн и инженерную поддержку на 5 лет, чтобы обеспечить плавный переход к независимому управлению.

• React Foundation объявлена как шаг к «децентрализации» React, но участники обсуждения подчеркивают, что фактически Vercel и другие корпорации продолжают контролировать развитие библиотеки, и что это может быть просто маркетинговым ходом.
• Обсуждение затрагивает тревожный факт, что React становится всё более сложным, и что это может отпугнуть новых разработчиков, особенно если учесть, что даже такие базовые вещи как Jest и Create React App были убиты.
• Участники также обсуждают, что влияние Vercel на React может привести к тому, что React становится менее доступным для сообщества, и что это может быть не лучшим путем для такой важной библиотеки.
• Некоторые выразили обеспокоенность тем, что React может быть «захвачен» корпоративными интересами, и что это может быть не лучшим путем для такого важного проекта.

Devpush — это опенсорсная альтернатива Vercel, предназначенная для автоматического деплоя приложений на любых языках программирования. В отличие от коммерческих решений, он не ограничивается JavaScript-экосистемой и работает с любым стеком технологий, предоставляя непрерывную доставку из Git-репозитория.

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

• Пользователи обсуждают и сравнивают различные инструменты для развертывания и управления контейнеризированными приложениями на собственном железе, такие как Coolify, Dokploy, CapRover, Cosmos Cloud, Piku и /dev/push.
• Ключевые темы: простота использования и UX (сравнение с Vercel), поддержка различных рантаймов и Docker, безопасность установки (curl | sh), зрелость и стабильность проектов.
• Автор /dev/push объясняет фокус на удобстве и опыте, близком к Vercel, в отличие от более мощных, но сложных container-centric решений, и анонсирует планы по добавлению новых функций.
• Поднимаются вопросы о необходимости глубоких знаний Linux для самохостинга и ответственности, а также о альтернативных подходах (Kubernetes vs более простые решения).
• Упоминаются recent controversies вокруг Vercel как возможный драйвер роста интереса к альтернативам и открытым решениям.

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

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

• Участники обсуждают личный опыт аутизма и ADHD, включая сенсорную чувствительность, трудности с маскировкой и выгорание на работе.
• Критики задаются вопросами о механике симулятора, отмечая неясность логики выбора и его последствий для игровых показателей.
• Поднимается вопрос о разнообразии аутистического спектра и необходимости учитывать индивидуальный опыт, а не обобщать.
• Обсуждается проблема стигматизации и недостаточной поддержки нейроотличных людей на рабочем месте.
• Некоторые пользователи видят ценность симулятора как инструмента для развития эмпатии и понимания трудностей нейроотличных коллег.

Нельзя сделать скриншот этого.

• Представлен эффект текста, который исчезает при попытке скриншота, но виден в движении.
• Обсуждаются технические обходные пути: запись видео, наложение кадров, изменение масштаба или режимов съёмки.
• Упоминаются аналогичные визуальные эффекты в играх (Branta Games) и на обложках альбомов (Soulwax).
• Предлагаются потенциальные применения: защита конфиденциальных данных, CAPTCHA, недоступные для ИИ задачи.
• Отмечаются проблемы доступности для людей с нарушениями зрения и вызываемая эффектом тошнота.
• Поднимается вопрос о возможности создания обратного эффекта — текста, читаемого только на скриншоте.
• Делается вывод, что метод не является абсолютной защитой, так как обходится видеозаписью.

Сборник коротких серверлес-кошмаров

• $1189 – Webflow снял за месяц вместо $69.
• $100 000 – DoS на игровом сайте → счёт за Firebase за сутки.
• $738 – Vercel Pro + лимит $120 ≠ защита от «сюрприза».
• $70 000 – Проснулся с таким счётом за Firebase при тарифе $50.
• $22 640 – BigQuery на публичных данных.
• $250/мес – 9 тыс. просмотров в Framer.
• $1274 – AI Devin случайно устроил ддос в PostHog.
• $530 – Платный PostHog после нулевого периода.
• $384 – Документация на Mintlify.
• $103 – AWS Free Tier ловушка.
• $96 281 – Vercel: «я просто молчу».
• $120 000 – Cloudflare выключает сайт, требуя деньги за сутки.
• $1301 – Пустой приватный S3 + ддос.
• $11 000 – Mailgun во время атаки.
• $104 500 – Письмо от Netlify «переплата».
• $23 000 – Спам-атака на EchoFox в Vercel.
• $3000 – Тестовый деплой в Vercel.
• $620 – Sitemap.txt сожрал трафик.
• $72 000 – Тест Firebase + Cloud Run чуть не разорил.

Хочешь поделиться своим счётом-ужасом — пиши в твиттере или PR на GitHub.

• Пользователи делятся историями о «серверлес-ужасах» — внезапных счетах за десятки и сотни тысяч долларов из-за DDoS, ошибок в конфигурации или забытого ресурса.
• Критика сосредоточена не на технологии serverless, а на модели оплаты «плати за использование» без жёстких потолков: бюджет — лишь уведомление, а не отключение.
• Многие считают, что провайдеры могли бы автоматически отключать сервис при превышении лимита, но не делают этого, теряя деньги на «ошибках» новичков.
• Участники советуют: ставить rate-limit, использовать VPS с фиксированной ценой, поднимать bare-metal или хотя бы включать billing-alerts и «пауz-лимиты» вроде Vercel.
• Поддержка AWS/GCP/Azure часто прощает счета после публичных твитов, но это выживший эффект: официальной политики нет, и никто не гарантирует прощение.

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.