9 октября 2026 года Cloudflare объявила о покупке Deno. Анонс «Deno is joining Cloudflare» опубликован в блоге Cloudflare за подписью Kenton Varda и Ryan Dahl и в тот же день — в блоге Deno с подзаголовком «Putting ourselves in the best place to build the future of the web». По описанию Simon Willison, Cloudflare приобретает Deno целиком, чтобы развивать celldпроект, который работает за счёт объектного хранилища для координации и персистентности и сделать workerdрантайм, на котором работают Cloudflare Workers с самостоятельным хостингом «first-class supported way to build and run apps using the Workers programming model».
Ключевое следствие для сообщества: Cloudflare будет поддерживать рантайм Deno ещё год ежемесячными релизами с исправлениями ошибок и обновлениями безопасности, после чего разработка рантайма прекратится. Сам Deno останется открытым, и Cloudflare приглашает других продолжить его разработку.
Что именно объявлено
Формулировка в блоге Cloudflare описывает цель сделки так: команда Deno присоединяется к Cloudflare, чтобы радикально упростить самостоятельный хостинг Workers и Durable Objectsпримитив Cloudflare для хранения состояния и координации, привязанный к отдельному экземпляру приложения, чтобы разработчики могли использовать одни и те же примитивы в большем числе мест.
Simon Willison уточняет, что приобретение идёт целиком, а не в формате партнёрства, и что срок поддержки рантайма ограничен годом. Ryan Dahl в комментарии на Hacker News назвал решение совместным и сказал, что согласен с ним.
Из конкретных активов прямо названы только сам рантайм Deno и celld.
Следы анонса на deno.com
Страница deno.com/blog/deno-joins-cloudflare отдаёт 404 — по этому адресу материала нет. При этом в списке записей на deno.com/blog анонс ведёт по другой ссылке — на https://deno.com/blog/cloudflare — с тем же заголовком и подзаголовком. Сверху на странице блога остаётся баннер «Deno is joining Cloudflare! Learn more →» с кнопкой «Dismiss». В обсуждении на Lobsters участник просит восстановить удалённый пост для https://deno.com/blog/cloudflare.
Как устроен рантайм Deno
Исходники Deno показывают, что рантайм — это не тонкая обёртка над V8, а многослойная система с отдельными механизмами для Web Worker и для Node-совместимых worker_threads.
При запуске рантайма ему передаётся загрузчик ES-модулей: именно его V8 вызывает, когда запрашивает загрузку модулей, и без него рантайм выдаст ошибку при попытке загрузить модули. Отдельно настраивается проверка атрибутов импорта. Логика проверки такая: если активны пользовательские хуки загрузчика, проверка откладывается; иначе допускаются типы "json" и "text", а "bytes" и "css" — только при включённом enable_raw_imports.
let valid_attribute = |kind: &str| {
matches!(kind, "json" | "text")
|| (enable_raw_imports.load(Ordering::Relaxed)
&& matches!(kind, "bytes" | "css"))
};Каждый Web Worker — это реализация Web API Worker, содержащая собственный js_runtimeсреда выполнения JavaScript, в которой исполняется код воркера и WorkerThreadTypeтип воркера, определяющий, как он загружает код: как классический скрипт или как ES-модуль; каждый Web Worker является потомком главного воркера или другого Web Worker.
Создание воркера как хоста устроено так: Classic-воркерворкер, загружаемый как обычный скрипт, а не как ES-модуль запрещён, если не включены тестовые фичи; при наличии собственных разрешений у воркера требуется нестабильная фича Worker.deno.permissions; дочерние разрешения формируются на основе родительских, иначе родительские клонируются; спецификатор резолвится через deno_core::resolve_url; для blob-схемы объект синхронно захватывается из blob_store, чтобы гонка с отзывом blob-URL после new Worker(blobUrl) не привела к сбою загрузки воркера. Затем порождается поток с размером стека stack_size_mb (из resource_limits, иначе DEFAULT_WORKER_STACK_SIZE_MB) и запускается воркер.
В cli/factory.rs фабрика главного воркера собирается из загрузчика модулей, файловой системы, резолверов Node и npm, blob-хранилища, проверки фич и других сервисов, а затем оборачивается в CLI-фабрику.
Два механизма обмена сообщениями между потоками
В рантайме есть два независимых механизма обмена сообщениями. Для Web Worker предусмотрен быстрый путь: уже сериализованный буфер передаётся напрямую через канал воркера, минуя накладные расходы на сериализацию структуры сообщения. Он работает только для сообщений без transferables.
Для Node-совместимого способа отправки сообщения конкретному потоку реализованы отдельные операциивнутренние функции рантайма, которые JS-код вызывает через служебный мост между JavaScript и Rust. Одна из них регистрирует поток в глобальном реестре и возвращает идентификатор ресурса приёмного канала, который вызывающий должен держать живым и опрашивать. Другая обновляет счётчик слушателей сообщений у потока-адресата: отправка потоку с нулём слушателей синхронно падает с ошибкой ERR_WORKER_MESSAGING_FAILED, как в Node.js. Третья сообщает, зарегистрирован ли поток, есть ли у него слушатели и удалось ли поставить сообщение в очередь; при force=true проверка счётчика слушателей пропускается для внутренних ack-сообщений.
При спавне потока размер стека берётся из настроек ресурсных лимитов, если он задан и больше нуля, иначе используется DEFAULT_WORKER_STACK_SIZE_MB — это соответствует поведению Node.js, а не меньшему стеку Rust по умолчанию. После уничтожения tokio-рантайма и V8-изолята воркера на Linux вызывается libc::malloc_trim(0), чтобы вернуть освобождённую память ОС и не держать высокий RSS после создания и уничтожения множества воркеров.
npm/JSR-резолюция, import map и permissions
За npm/JSR-резолюцию и связанные кэши отвечает отдельная фабрика установщика npm-пакетов: она создаётся лениво и получает HTTP-клиент для npm-реестра, исполнитель lifecycle-скриптов (управляемый npm-резолвер использует один исполнитель, неуправляемый — другой), отчёт об установке и набор опций: очистка при установке, дедупликация вариантов peer-зависимостей в lockfile, настройка и стратегия кэширования, режим production, пропуск типов и разрешение снимка npm-резолюции.
Резолюция JSR и npm-версий идёт через общую фабрику резолверов. Import map задаётся там же через провайдер указанной import map, а внешний загрузчик import map берётся из фабрики workspace.
Permissions обслуживает парсер дескрипторов разрешений, создающий парсер на основе системного окружения, и контейнер корневых разрешений, который строит разрешения из опций и оборачивает их в контейнер. Отдельно правила --deny-import применяются только к загрузке модулей, а не к npm/jsr-резолюции: правило, записанное как IP-литерал, покрывает и хосты, резолвящиеся в этот адрес, но npm и jsr — это не import.
Кэши прогреваются в зависимости от подкоманды: база анализа зависимостей, база анализа Node, база быстрой проверки, база кэша проверки типов и база кэша кода. Дополнительно создаются кэш информации о модулях, кэш кода, кэш разобранных исходников, кэш npm, директория кэша npm и сервисы кэша npm.
Предыстория
Вехи развития Deno, перечисленные в блоге проекта: Deno 1.5 улучшил deno bundle за счёт tree shakingудаление из итоговой сборки кода, который нигде не используется, а также 15-кратного ускорения, добавил API alert, confirm и prompt и улучшил REPL. Deno 1.6 добавил сборку проектов в полностью автономные исполняемые файлы через deno compile, встроенный LSP для редакторов и экспериментальную поддержку Apple Silicon. Deno 1.23 изменил поведение проверки типов по умолчанию, поставляется с TypeScript 4.7 и обновляет deno task. Deno 1.26 добавил Cache Web API, улучшил систему разрешений, экспериментальную поддержку npm и совместимость с Node.js, поставляется с TypeScript 4.8. Deno 1.40 представил Temporal API, декораторы TC39, ряд устареваний и стабилизаций, а также улучшения в совместимости с Node.js, LSP, диагностике и обработке нестабильных функций, прокладывая путь к обновлению до Deno 2.
Fresh 1.0 — полнофункциональный веб-фреймворк для Deno, который по умолчанию отправляет ноль JavaScript на клиент. Fresh 1.6 добавил плагин Tailwind CSS и упрощённые типизации. Fresh 2.0 beta представил опциональную интеграцию с Vite — с горячей перезагрузкой, более быстрым запуском, бесшовным алиасингом React и полной экосистемой плагинов Vite.
Отдельно в блоге Deno упоминается судебный конфликт с Oracle за отмену товарного знака JavaScript: Oracle удерживает товарный знак, и Deno преследует юридические средства, чтобы #FreeJavaScript.
Почему это сделали
Simon Willison приводит слова Ryan Dahl: решение совместное, и он с ним согласен. Dahl объясняет его так: в Deno есть хорошие идеи и он хорошо спроектирован, но в конечном счёте не решает больших проблем — его затянуло в «гравитационный колодец совместимости с Node», которая заставляет вести себя точно так же, как Node. Переписывать Node смысла нет: он работает, а маргинальной выгоды в производительности, UX или безопасности недостаточно. Dahl говорит, что заинтересован в построении мощных новых абстракций, и что celld работает замечательно, завися только от объектного хранилища для координации и персистентности.
Willison отмечает, что его любимой функцией Deno давно была система разрешений, позволяющая указать, какие файлы и папки скрипт может читать и писать и к каким сетевым хостам обращаться.
Реакция сообщества
Обсуждение на Lobsters озаглавлено «Cloudflare shutting down Deno is news, not just PR». Автор поста conartist6 просил восстановить удалённую публикацию, считая покупку значимой технической новостью, а не просто пиаром: по его формулировке, Cloudflare скупает команды открытого ПО и при этом сворачивает поддерживаемые ими проекты. Модератор pushcx отклонил просьбу, заявив, что практики найма лучше обсуждать на HN или Reddit, и отметил, что тред начался плохо: 18 из 22 комментариев были о бизнес-практиках. Участник andyc согласился, что тред был полон нападок, плохо отражающихся на сообществе. Участник lilac возразил против трактовки как злого умысла: по его мнению, покупка Deno была «mercy killing», а не конспирацией, и ничего не сворачивается.
Что это меняет на практике
Для пользователей рантайма Deno конкретика одна: поддержка продлится ещё год ежемесячными релизами с исправлениями ошибок и обновлениями безопасности, после чего разработка рантайма прекратится. Deno останется открытым исходным кодом, и Cloudflare приглашает других продолжить его разработку. Это касается именно рантайма, а не Deno Deploy, JSR или Subhosting.
Ограничения и открытые вопросы
Условия сделки не раскрыты: в блоге Cloudflare сказано лишь, что команда Deno присоединяется к Cloudflare, а у Willison — что приобретение идёт целиком, без финансовых или юридических деталей. Судьба команды Deno описана только косвенно — через срок поддержки рантайма и объяснение Dahl. О будущем Deno Deploy как конкурента Cloudflare Workers сведений нет: есть лишь упоминание его общедоступности и обучающих статей. Вопросы о том, как сделка повлияет на Deno Deploy, JSR и Subhosting, остаются без ответа.
