- Permet de regrouper un projet Deno créé avec une application web et du code TypeScript dans un binaire d’application de bureau redistribuable selon la plateforme
- La sortie inclut à la fois le code de l’application, le runtime Deno et le moteur de rendu web ; la fonctionnalité est arrivée dans Deno v2.9.0, mais n’est pas encore une version stable
- Le backend WebView par défaut utilise le webview intégré au système d’exploitation pour viser de petits binaires, et si une cohérence de rendu est nécessaire, il est possible de choisir le backend Chromium (CEF)
- Détecte les projets Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start et Vite SSR, puis exécute le serveur selon le mode release ou le mode de développement
--hmr
- La communication entre le code Deno et le webview utilise des canaux en processus plutôt qu’un IPC basé sur des sockets, et le périmètre couvre aussi la compilation croisée ainsi que les mises à jour automatiques basées sur bsdiff
Rôle et état actuel de deno desktop
deno desktop transforme un projet Deno en application de bureau autonome
- L’entrée peut aller d’un simple fichier TypeScript à une application Next.js
- La sortie est un binaire redistribuable propre à chaque plateforme
- Le binaire inclut le code de l’application, le runtime Deno et un moteur de rendu web
- Cette fonctionnalité est incluse dans Deno v2.9.0, mais il ne s’agit pas encore d’une version stable
- Pour l’essayer dès maintenant, il faut installer un build
canary avec deno upgrade canary
- Les commandes, clés de configuration et l’API TypeScript peuvent encore changer avant stabilisation
Choix du backend et exécution des projets web
- L’approche consiste à utiliser les technologies web comme toolkit d’interface de bureau, tout en réduisant les compromis habituels des outils d’applications de bureau fondés sur les stacks web existantes
- Des outils comme Electron, Tauri ou Electrobun peuvent présenter des compromis tels que de gros binaires, un support incomplet selon les plateformes, l’absence de certains éléments de l’écosystème JavaScript, l’absence de mise à jour intégrée ou encore le manque d’intégration avec les frameworks
- Le backend WebView par défaut utilise le webview du système d’exploitation pour viser des binaires légers
- L’écosystème npm peut être utilisé via la couche de compatibilité Node de Deno
- Si le même rendu est nécessaire sur macOS, Windows et Linux, il est possible de choisir le backend CEF, avec Chromium embarqué
- La détection automatique des frameworks permet d’exécuter sur le bureau des projets web existants sans modification de code
- Les frameworks visés incluent Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start et Vite SSR
- En mode release, le serveur de production est lancé
- Avec
--hmr, c’est le serveur de développement avec hot reload qui est exécuté
Communication runtime, build et mises à jour
- La communication entre le backend et l’interface utilise des canaux en processus
- Les valeurs sont encodées lorsqu’elles traversent la frontière d’appel
- Il n’y a pas d’aller-retour inter-processus entre le code Deno et le webview
- Il est possible d’effectuer une compilation croisée depuis une seule machine vers macOS, Windows et Linux
- Le backend n’est pas compilé localement ; il est téléchargé à la demande
- Les mises à jour automatiques reposent sur une mise à jour différentielle binaire intégrée, utilisant un manifeste
latest.json et des patchs bsdiff
- Le runtime gère le polling, l’application des mises à jour et le rollback en cas d’exécution défaillante
Exemple simple et organisation de la documentation
- Une application de bureau en un seul fichier peut être créée en définissant un
main.ts qui renvoie une réponse HTML avec Deno.serve(), puis en exécutant deno desktop main.ts
Deno.serve(() =>
new Response("Hello, desktop
", {
headers: { "content-type": "text/html" },
})
);
deno desktop main.ts
- Le binaire compilé ouvre une fenêtre pointant vers un serveur HTTP local lié au gestionnaire
Deno.serve()
- Sur macOS/Linux, on l’exécute avec
./main
- Sous Windows, on l’exécute avec
.\\main.exe
Deno.serve() se lie automatiquement à l’adresse vers laquelle le webview navigue ; il n’est donc pas nécessaire de fournir un port ou un nom d’hôte- La documentation associée est organisée en sections sur la configuration, les backends, le service HTTP, les frameworks, la gestion des fenêtres, les bindings, les menus, le tray et le dock, les boîtes de dialogue, les notifications, HMR, DevTools, les mises à jour automatiques, les rapports d’erreur, le déploiement, la comparaison et la référence CLI
Deno.BrowserWindow concerne le cycle de vie des fenêtres, les fenêtres multiples et les événementsDeno.autoUpdate() concerne le manifeste, bsdiff et le rollbackbindings.() est le mécanisme de binding permettant d’appeler du code Deno depuis le webview
1 commentaires
Avis sur Hacker News
Deno Desktop semble avoir choisi ce compromis de façon assez affirmée : « petit par défaut, compatibilité Node complète »
J’ai essayé
deno desktop index.tsavec le Hello World en 5 lignes de l’article, et le résultat faisait 442 MB sous Windows 10Je pensais que ce serait plus petit qu’un build Electron, mais c’était bien plus gros que prévu ;
libcef.dllfaisait 247 MB etdeno-test.dll, qui contenait le Hello World, 78 MBJe me demande si j’ai raté quelque chose
Donc j’espérais qu’en réutilisant un webview système ou quelque chose du genre on puisse arriver à une solution sous les 20 MB, mais dépasser 400 MB me paraît un peu trompeur
J’ai peut-être mal configuré quelque chose, donc je me demande s’il faut faire autre chose que
deno desktop test.tsLe passage disant que « plutôt que de bundler CEF dans chaque application, ils pourraient gérer un runtime CEF partagé, ce qui réduirait la taille du binaire à quelques MB par app, et c’est sur la roadmap » est intéressant
Je connais mal CEF, donc je me demande comment la gestion des versions fonctionnerait
Si chaque application demande une version différente de CEF, est-ce qu’on retombe au final sur le modèle d’Electron où chaque app embarque son propre navigateur, ou bien est-ce qu’un runtime partagé garde quand même des avantages dans ce cas ?
https://docs.deno.com/runtime/desktop/comparison/
https://github.com/chromiumembedded/cef
Le résultat n’était pas fameux, mais je ne sais pas si c’était dû à CEF lui-même ou à d’autres composants / processus
https://www.riotgames.com/en/news/architecture-league-client...
En pratique, les applications Electron sur desktop utilisent presque toutes des versions différentes de Chromium, et certaines gardent de vieilles versions à cause du risque de casse lors des mises à jour
Sous Windows, ce serait une approche de type WebView2
Deno continue d’être impressionnant
Ça fait un bon moment que je n’ai pas démarré de nouveau projet sans Deno, et je soutiens désormais complètement l’écosystème Deno plutôt que Node.js
Je ne sais pas à quelle fréquence j’utiliserai cette fonctionnalité, mais c’est vraiment bien d’avoir ce choix
Travail impressionnant
Ça pourrait être particulièrement intéressant pour créer des applications desktop en vibe coding
Des outils comme Lovable, Bolt ou v0 utilisent déjà TypeScript par défaut pour générer des applis web, donc ça semble très bien coller ici
Pour de petites applications desktop, j’utilisais plutôt Go/Wails au lieu de bundler Chromium et Node, et même si Electron faisait bien le job, ces gros bundles m’ont toujours franchement rebuté
Je me demandais comment cela s’intègre avec le système de permissions de Deno, qui est l’un de ses plus gros points forts
C’est particulièrement important quand on laisse des agents se balader librement sur sa machine
La documentation de référence de la CLI dit que « les permissions accordées à la compilation sont intégrées dans le binaire compilé »
Ce serait bien que ce soit exposé de manière à ce que l’utilisateur puisse savoir et décider quelles permissions accorder
https://docs.deno.com/runtime/reference/cli/desktop/#runtime...
Afficher à ce moment-là une invite de permissions Deno me semblerait même trompeur, puisqu’il n’y aurait aucune garantie d’intégrité sur ces permissions
Autrement dit, appliquer le système de permissions de Deno au sandboxing desktop, avec des invites pour chaque accès au système de fichiers ou au réseau
C’est une fonctionnalité intelligente à lancer
Ça me semblerait tout à fait digne d’être pris en compte au moment de choisir une plateforme
Avec une petite taille d’installation et le multiplateforme, ça ressemble à une alternative crédible à Electron ou Tauri
Je ne pense pas que la formule « les technologies web sont la boîte à outils UI la plus connue au monde » soit très appropriée
Si les apps Electron sont souvent critiquées, c’est justement presque pour la raison inverse d’une boîte à outils UI
Elles ne respectent souvent pas correctement les patterns UI de l’OS hôte
Les technologies web restent simplement des technologies web : elles peuvent afficher un bouton, mais rien ne garantit qu’un bouton même non stylé aura un aspect natif pour l’OS, et cela varie selon le navigateur
L’objectif n’a jamais été simplement une « boîte à outils UI » ni « suivre les patterns UI de l’OS hôte »
Chromium embarque énormément de fonctionnalités, et Electron récupère directement toute cette utilité, ce qui est un avantage
Par exemple, si vous avez déjà travaillé sur la vidéo, vous savez que pouvoir exploiter toutes les capacités d’un navigateur moderne dans une application desktop change complètement la donne
Non seulement pour la lecture vidéo, mais aussi pour le transcodage rendu possible par le web moderne et WebCodecs : tout réimplémenter soi-même représenterait un énorme travail, surtout pour une app desktop censée fonctionner sur Windows/macOS/Linux
J’ai une app faite avec Electron en quelques dizaines d’heures ; autrement, cela aurait probablement pris des dizaines de jours, et même avec l’IA cela aurait été difficile sans être spécialiste de la vidéo
Il n’a jamais été prétendu que l’UI était « native »
L’UI native de Linux m’a toujours semblé très laide ; je préfère largement une mise en page HTML+CSS bien soignée
D’après mon expérience, Electron est surtout critiqué parce qu’il est lourd et lent ; le fait qu’il ne soit pas natif est plutôt un reproche annexe que les gens ajoutent
Depuis longtemps, je voulais une intégration directe du navigateur qui utilise HTML+CSS pour la mise en page sans nécessiter de runtime JavaScript
Je ne sais pas à quel point Servo est léger, mais j’aimerais qu’une idée comme celle-là devienne réalité un jour
En tant qu’utilisateur, j’en suis très satisfait ; il lui manque encore quelques bases comme l’accessibilité, mais je pense que cela arrivera bientôt
Du point de vue développeur, à part Rust je ne vois pas très bien où est la barrière à l’entrée, et en même temps Rust est aussi ce qui le différencie
C’était déjà un sujet il y a environ 25 ans, et depuis que Microsoft lui-même a commencé à ne plus s’en soucier, plus grand monde n’y attache vraiment d’importance
Je ne veux pas que mon application ait un aspect différent selon l’OS
Je n’ai pas les ressources pour tester sur tous les appareils, et le fait qu’un écran testé sur un système ait exactement le même rendu sur les autres est un énorme avantage
Ravi de voir apparaître un concurrent dans ce domaine
J’apprécie surtout que Deno, contrairement à l’implémentation actuelle de Node qui ne fait qu’enlever les types, puisse exécuter directement du vrai TypeScript
Cela dit, j’ai l’impression que cela va prendre une bonne partie du marché de Tauri
Pourquoi utiliser Tauri désormais ?
Sur la plupart des connexions internet, 150 MB de bundle en plus ne représentent qu’une différence de 1 à 10 secondes au téléchargement, en échange d’un moteur de rendu fiable
Pour faire la vérification de types, il faut lancer
deno run --checkou utiliser séparément la sous-commandedeno checkEn pratique, pendant le développement, l’IDE fait généralement automatiquement la vérification de types et le linting, donc ce n’est pas un gros problème
En fait, il n’est même pas nécessaire d’utiliser JavaScript
Et on a déjà vu plusieurs startups de frameworks pour développeurs comme Astro, Nuxt, UV, Bun ou Vite se faire racheter
Pour des logiciels qui doivent être maintenus et supportés pendant des années, ce genre d’évolution n’inspire pas vraiment confiance
Deno Desktop et Tauri n’utilisent-ils pas tous les deux la webview système ?
Pourquoi faudrait-il utiliser ça, mais pas Electron ?
Parmi les contenus publiés par Deno, c’est de loin la section de comparaison que j’ai préférée
Sur la dernière ligne, le support iOS/Android est indiqué comme « no » pour Electron et « not yet » pour Deno ; s’ils y parviennent réellement, ce sera bien plus important
Ça a l’air vraiment idéal pour distribuer un jeu web comme application Steam ou comme app pour des achats en ligne
Je pense que je vais essayer