Deno Desktop peut réduire la taille de vos applications de 70 %

하이라이트

• Deno 2.9 permet de créer des applications de bureau en TypeScript pur avec un seul binaire.

• La taille du binaire d'une application de prise de notes chute à 70 Mo avec Deno, contre 248 Mo avec Electron.

• Le rendu de l'interface utilise par défaut les moteurs système (WebView 2, WebKit), mais le drapeau --backend CEF permet d'intégrer Chromium pour une cohérence multiplateforme.

• Les performances de démarrage atteignent une moyenne de 375 millisecondes, un résultat comparable aux applications Electron.

• Une sécurité accrue est introduite avec un âge de dépendance minimum par défaut de 72 heures pour contrer les attaques de la chaîne d'approvisionnement.

• La compilation multiplateforme (macOS, Windows, Linux) est réalisable depuis n'importe quel hôte sans outils spécifiques grâce à l'implémentation en Rust pur.

타임라인

1. 00:00 - 01:25

   Introduction à Deno Desktop

   Cette version permet de concevoir des applications de bureau en TypeScript pur sans le poids de Chromium. Le processus est simplifié par une commande unique pointant vers un fichier TypeScript, avec un support pour le rechargement à chaud indispensable au développement actif.

   • Deno 2.9 introduit la création d'applications de bureau via la commande deno desktop.
   • Le système détecte automatiquement les frameworks comme Next.js, Svelte ou Remix.
   • Le drapeau HMR active le rechargement à chaud pour le développement.
2. 01:26 - 02:13

   API et communication

   Pour rendre les applications interactives, le runtime expose des API permettant de gérer nativement les fenêtres et les éléments système. La communication entre les couches backend et frontend s'effectue via des bindings, simplifiant ainsi les échanges de données comparé aux trois étapes requises par le pont IPC d'Electron.

   • L'objet global Deno fournit des API pour contrôler les fenêtres, les icônes de la barre d'état et les notifications.
   • La méthode bind facilite la communication entre le backend et la vue web.
   • L'intégration remplace le pont IPC complexe utilisé par Electron.
3. 02:14 - 03:03

   Gestion du rendu et taille des fichiers

   Le choix du moteur de rendu influence directement la taille et la compatibilité. L'utilisation des moteurs système réduit drastiquement le poids initial, tandis que le choix optionnel de Chromium garantit une cohérence visuelle parfaite au prix d'une augmentation de la taille du binaire.

   • Le mode par défaut utilise les moteurs natifs WebView 2 ou WebKit pour minimiser l'encombrement.
   • Le mode Chromium Embedded Framework (CEF) assure un rendu identique sur toutes les plateformes.
   • Electron nécessite environ 180 Mo avant l'ajout du code applicatif en raison de Chromium.
4. 03:04 - 06:05

   Compilation, performances et sécurité

   Le processus de build est simplifié par des drapeaux CLI ou un fichier deno.json, permettant de cibler toutes les plateformes depuis un seul hôte. Outre les gains en performance brute, Deno intègre des mesures de protection contre les vulnérabilités de la chaîne d'approvisionnement en imposant une ancienneté minimale aux dépendances.

   • La compilation génère des binaires natifs (.app, .exe, .deb) via Rust sans dépendances spécifiques à l'OS.
   • La version 2.9 réduit le temps de démarrage et la consommation mémoire par rapport à la 2.8.
   • Une sécurité par défaut bloque l'installation de dépendances créées depuis moins de 72 heures.