Gluon - Créer des applications desktop à partir de sites web avec le navigateur de l’OS et Node.js
(gluonjs.org)- Utilise le navigateur déjà installé sur l’OS sans en embarquer un (pas une webview)
- Compatible avec Chromium et Firefox
- Taille de bundle réduite et builds rapides
- Prend en charge le prototypage rapide avec une API simple mais puissante
- Prend en charge Deno à la place de Node.js (phase expérimentale)
- Compatible Windows/Linux, prise en charge de Mac en cours
6 commentaires
On dirait que c’est similaire à Wails, qui repose sur un concept proche et est écrit en Go.
Cela ressemble à une technologie intéressante, mais je ne vois pas quel cas d’usage en aurait réellement besoin.
N’est-ce pas une sorte de solution qui cumule seulement les inconvénients de l’intégration d’un navigateur web et de l’utilisation de WebView… ?
N’est-ce pas plutôt pour réduire la taille du bundle et économiser de la mémoire ?
J’ai des réserves sur les deux points.
Gluon est présenté comme une architecture qui lance à la fois un navigateur web et NodeJS pour contrôler ce navigateur. Il y a de fortes chances qu’un navigateur web complet consomme autant, voire plus, de mémoire qu’un composant WebView (à cause de la partie UI/UX), donc y ajouter NodeJS en plus... je ne sais pas vraiment si cela permettra d’économiser de la mémoire.
Même le critère de taille du bundle indiqué sur le site web repose sur l’hypothèse que « NodeJS est déjà installé sur le système », d’où ce chiffre, et du côté de tauri, le temps de build correspond à un véritable cold build en repartant de zéro jusqu’aux crates Rust...
On dirait globalement que c’est le même concept que Tauri (utiliser le navigateur présent sur le système), mais implémenté en Node...
Si l’on pouvait réutiliser une instance de navigateur existante, cela permettrait d’économiser de la mémoire. Aujourd’hui, avec les applications Electron, chacune doit charger son propre moteur Electron en mémoire, ce qui pose problème.