Профиль: Аноним (вход | регистрация) неRU opennet.me  
The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Платформа Deno 2.9 c поддержкой Deno Desktop для создания десктоп-приложений

25.06.2026 23:21 (MSK)

Опубликован выпуск платформы Deno 2.9, предназначенной для обособленного выполнения серверных и настольных приложений на языках JavaScript и TypeScript с использованием движка V8, применяемого в браузерах на основе Chromium. Проект развивает Райан Даль (Ryan Dahl), создатель Node.js, с целью предоставления более защищённого окружения и устранения концептуальных ошибок, допущенных в архитектуре Node.js. Для повышения безопасности обвязка вокруг движка V8 написана на языке Rust, а для обработки запросов в неблокирующем режиме применяется платформа Tokio. Код проекта распространяется под лицензией MIT. Сборки подготовлены для Linux, Windows и macOS.

Новая версия примечательна реализацией экспериментального инструментария Deno Desktop, позволяющего создавать пользовательские приложения с графическим интерфейсом, построенные с использованием web-технологий, по аналогии с платформой Electron. Логика и интерфейс приложения определяются на языке JavaScript или TypeScript с использованием типовых web-фреймворков, а работа организуется с использованием браузерного движка. Приложение поставляется в форме самодостаточного исполняемого файла и по взаимодействию с пользователем не отличается от классических программ с графическим интерфейсом.

В Deno Desktop предлагаются бэкенды для работы поверх двух браузерных движков - предоставляемого операционной системой WebView и интегрируемого в приложение CEF (Chromium Embedded Framework). Бэкенд на базе WebView позволяет уменьшить размер исполняемых файлов за счёт работы поверх системного браузерного движка WebView2 в Windows и WebKit в macOS и Linux, а бэкенд CEF даёт возможность добиться одинаковой отрисовки интерфейса на платформах Linux, macOS и Windows, но ценой существенного увеличения размера исполняемых файлов.

Размер исполняемого файла тестового приложения при использовании WebView оценивается в 40 МБ, а при использовании CEF - 150 МБ. Для сравнения для Electron этот показатель составляет 100 МБ, Electrobun - 61 МБ, а Tauri - 2-10 МБ (в Electron применяется встраиваемый в приложение CEF, а в Electrobun и Tauri системный WebView). В разработке находится механизм совместного использования общего движка CEF в разных приложениях, который даст возможность снизить размер исполняемых файлов.

В Deno Desktop реализована полная совместимость с Node.js, экосистемой NPM и такими web-фреймворками, как Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start и Vite SSR. Предоставляется API для доступа к нативным десктопным API, например, можно из программы управлять размером, позицией и видимостью окна, создавать меню, прикреплять свои обработчики, выставлять пиктограммы для системного лотка и панелей, выводить родные для ОС диалоги. Возможна сборка web-приложений в форме десктоп-программ без изменения их кода, а также автоматическое определение используемых web-фреймворков и кросс-компиляция на одной системе для Linux x64/arm64, Windows x64 и macOS x64/arm64. Для Linux могут генерироваться пакеты в форматах AppImage, deb и rpm.

В отличие от Electron, Electrobun и Tauri в Deno Desktop применяется не многопроцессная модель выполнения с IPC на базе сокетов, а многопоточная модель для CEF или модель на основе групп процессов для WebView с взаимодействием между бэкендом и кодом графического интерфейса через каналы внутри одного процесса. Имеется встроенный механизм проверки и автоматической установки обновлений, для экономии трафика загружающий только изменившиеся относительно прошлой версии данные (применяются бинарные патчи на базе bsdiff) и поддерживающий откат на прошлую версию в случае сбоя при запуске новой версии.

Среди других новшеств Deno 2.9:

  • Поддержка в команде "deno install" прямого чтения lock-файлов для упрощения миграции на Deno с npm, pnpm, yarn и Bun.
  • Поддержка импорта CSS-модулей.
  • Реализация совместимости с платформой Node.js 26.
  • Новые команды "deno link", "deno unlink" и "deno list".
  • Поддержка API Web Locks для выставления блокировок на ресурсы.
  • Включение по умолчанию 24-часовой задержки (min-release-age=24h) перед установкой новых версий зависимостей для защиты от атак через компрометацию зависимостей.
  • Сокращение времени запуска (~2x), снижение потребления памяти (~2.2x) и повышение пропускной способности при работе с HTTP (~1.2x).


  1. Главная ссылка к новости (https://deno.com/blog/v2.9...)
  2. OpenNews: Выпуск Electron 40, платформы создания приложений на базе движка Chromium
  3. OpenNews: Tauri 1.0 - конкурирующая с Electron платформа для создания пользовательских приложений
  4. OpenNews: В библиотеку ANGLE, используемую в Chrome и Android, добавлена поддержка Wayland
  5. OpenNews: Доступна серверная JavaScript-платформа Bun 1.0, более быстрая, чем Deno и Node.js
  6. OpenNews: Доступна платформа Deno 2.0, развиваемая автором Node.js
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65770-deno
Ключевые слова: deno, desktop, electron
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (22) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, q (ok), 23:41, 25/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Мой тейк:

    Электрон-подобная фигня абсолютно не нужна. Вместо этого авторы должны стремиться пилить PWA-приложения. В большинстве случаев их хватает. А там, где нужны расширенные функции (необычные для браузеров протоколы, прямой доступ к файлам...), нужно делить приложение по-старинке на фронтенд и бэкенд, и распространять это в OCI-контейнерах. В этом случае не придется держать в системе кучу хромов.

    Конкретно Дено надеюсь не взлетит, потому что он плюшевый. Он не готов для продакшна, в отличие от Node.js и Python. Например, всем известно, что имя файла в линуксе -- это NUL-терминированная строка, в которой может быть любая бинарная хрень, кроме байтов '/' и '\0'. Не обязательно UTF-8. Но именно Дено, из всех платформ, считает, что имя файла это строго WTF-16-строка. Это значит, что даже readdir в нем работает некорректно, так как пропускает файлы с не-WTF-16-названиями. Это значит, что даже файловый менеджер на нем не напишешь. Платформа, в которой не напишешь корректный ФМ, не нужна и не готова.

     
     
  • 2.3, Аноним (3), 00:02, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Электрон-подобная фигня абсолютно не нужна. Вместо этого авторы должны стремиться пилить PWA-приложения.

    Ага, надо давать сайтам еще больше доступа к ос, и со 100% привязкой к серверу где-то в облаке.

    > В большинстве случаев их хватает. А там, где нужны расширенные функции (необычные для браузеров протоколы, прямой доступ к файлам...), нужно делить приложение по-старинке на фронтенд и бэкенд, и распространять это в OCI-контейнерах. В этом случае не придется держать в системе кучу хромов.

    Куча хромов (один системный вебвью) - это плохо, куча контейнеров со всем юзер спейсом - это хорошо.

     
  • 2.4, Аноним (4), 00:05, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    есть куча людей которые собирают марки, почему ваш тейк игнорирует их? чем разработчики этого хуже/лучше всех прочих кто занимается бесполезной фигней?

    запретить им мб? а потом запретить влюбленным юношам писать стихи, а потом запретить всем остальным писать хоть чтото что не прославляет партию, ну было вроде.

    Если другие платформы не дадут большей удобности, гибкости и производительности, то обязательно взлетит, это не зависит от разработчиков даже.

    Лучшая политика - игнорировать, иначе плохой пиар тоже пиар, сами же рекламируете.

     
  • 2.5, Смузихеб забывший пароль (?), 00:09, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема в том, что на разных системах могут быть разные версии или даже типы браузерных движков с совершенно разной поддержкой того или иного функционала или некоторыми специфическими особенностями этого
    Т.е получится классическое - у разработчика работает, у пользователя с другой версией - либо нет, либо криво

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

    Ну и бонусом к этому можно всякую нативщину норм прикрутить и многое иное

     
  • 2.6, Анон1110м (?), 00:22, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +5 +/
    JavaScript и вэбня за границами WWW абсолютно не нужны и вредны. Их нужно бойкотировать. Значимость и нужность кроссплатформености довольно сильно преувеличина и всегда нужно стремиться писать родные программы тем более что копрораций на это деньги есть.
     
     
  • 3.21, Не ной (?), 14:28, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Когда нативная разработка будет такая же удобная как и web, тогда и начнут писать. А пока сам в своем кале копашись
     
     
  • 4.22, Анон1110м (?), 14:53, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Когда нативная разработка будет такая же удобная как и web, тогда и
    > начнут писать. А пока сам в своем кале копашись

    Позиция неосилятора.

     
     
  • 5.26, Аноним (-), 17:24, 26/06/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.9, Colorado_House_of_Representatives (?), 01:43, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Электрон-подобная фигня абсолютно не нужна.

    Настолько не нужна, что используется повсеместно. Де-факто нужна.

     
  • 2.15, test (??), 07:08, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    A Wails взлетит?
     

  • 1.7, Аноним (7), 00:24, 26/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    как у webassembly дела вообще?
     
     
  • 2.8, Аноним (-), 01:18, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    https://hl2.slqnt.dev/
     
     
  • 3.23, Анон1110м (?), 15:18, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > https://hl2.slqnt.dev/

    Exception thrown, see JavaScript console

     
  • 2.14, Дед100лет (?), 06:57, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Так себе. 1) Слишком много человекочасов (и достаточно квалифицированных) вбито в движок V8. В результате, если придерживаться по возможности мономорфичности и не сильно допускать мегаморфизм в коде, оно после разогрева относительно неплохо компилирует js в достаточно шустрый код (относительно, конечно). По состоянию на пару лет назад, все попытки в одном проекте (рисование сложной прикладной графики в браузерах энтерпрайз клиента) перейти на webassembly после тестов отбрасывались из-за отсутствия явного преимущества. А иногда получали даже замедление, потому что 2) исторически есть сильно хреновое взаимодействие с API браузера, т.е. требует обвязки на js для каждого чиха - что сразу рождает вопрос, "а оно надо? не проще ли все на js сделать". Ну и 3) возня с плюсами - это слишком сложно и напряжно для среднего веб синьора, а плюсисты в массе своей слишком уж белая каста и супер-элита чтобы опускаться и идти в неприкасаемые (прикладнуху), да еще работать под каким-нибудь тимлидом-фронтэнщиком.
     
     
  • 3.20, Аноним (7), 13:11, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    согласен

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

    не стал особо углубляться почему нельзя тупо открыть это _окно в ад_, но поскольку мне жбскрипт не зашёл, а выглядело так, что легче просто всё на нём переписать без всякого васм - просто плюнул и пошёл другим путём

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

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

     

  • 1.12, Ivan_83 (ok), 02:25, 26/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Притом что нативное вендовое приложение на WinAPI уровня хэлловорлд с окошком можно уместить где то в 5кб после пары трюков.

    GTK3 приложение на пару окон с ползунками и без хаков уменьшения размера - 58кб.

    А в 100+мб влезацет целая ОС, а не просто какое то хэлловорлд в браузере.

     
     
  • 2.19, Аноним (19), 12:13, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Проблемы начинаются, когда на WinAPI пытаешься создать что-то посложнее HelloWorld.
     
     
  • 3.24, Анон1110м (?), 15:20, 26/06/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Какие именно?
     
     
  • 4.25, Аноним (25), 16:44, 26/06/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.16, ааа (??), 07:50, 26/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уж лучше десктоп на расте с родным тулкитом для de, чем на этих жсах с зоопарком движков и браузеров
     
  • 1.17, Аноним (17), 09:09, 26/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это вы еще на Lazarus бочку катите на размер бинарника. %)
     
  • 1.18, Я (??), 11:38, 26/06/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ребята заигрались. Слишком сильное переусложнение простых вещей
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру