GPUI KIT : des interfaces desktop denses en Rust, déjà éprouvées en production
⏱️ Temps de lecture estimé : 3 minutes
https://gpui-kit.com/versions/main/
📌 GPUI KIT est un framework Rust pour applications desktop, construit sur GPUI, le moteur d’interface de Zed. Il assemble plus de 75 composants documentés, des tables de données taillées pour des centaines de milliers de lignes, un éditeur de code, des graphiques et un système de dock. Surtout, il n’est pas né dans une tour d’ivoire : Longbridge l’a extrait des besoins de Longbridge Pro, son poste de trading livré au public, et l’y fait tourner depuis le premier jour.
GPUI, seul, vous donne un moteur : rendu GPU, modèle d’entités, fenêtres. Pas un seul bouton. GPUI Kit comble ce vide avec un catalogue complet, publié sous Apache-2.0 et déjà suivi par près de 15 000 étoiles sur GitHub. La promesse affichée reste honnête jusqu’au bout : le support 120 Hz y est présenté comme un budget d’environ 8,3 ms par image, que toute l’application doit tenir. Aucun chiffre magique, juste une contrainte de conception.
Le catalogue vise clairement les logiciels où l’information est dense. Les tables gèrent colonnes fixes et redimensionnables, tri et sélection de cellules sur un scroll virtualisé. Les listes ne rendent que la plage visible, tailles hétérogènes comprises. L’éditeur de code s’appuie sur une rope, reste stable à 200 000 lignes et parle à Tree-sitter pour la coloration comme au LSP pour les diagnostics, la complétion et le survol. Le dock empile panneaux redimensionnables, onglets à faire glisser et splits imbriqués, le tout sérialisable. Le Markdown et le HTML se rendent nativement, graphiques intégrés.
- 📊 Tables de données : tri, colonnes figées, scroll virtuel sur des centaines de milliers de lignes
- ✍️ Éditeur stable à 200 000 lignes, Tree-sitter et LSP embarqués
- 🪟 Dock sérialisable : panneaux, onglets, splits imbriqués
- 🎨 Thèmes pilotés par des tokens sémantiques, clair et sombre inclus
- 🧪 Tests d’interface en fenêtres headless : pointer, clavier, focus, accessibilité
C’est l’empilement qui me convainc le plus. gpui-base fournit le comportement sans style : focus, overlays, virtualisation, accessibilité. gpui-component pose par-dessus un système visuel complet et cohérent. Et gpui-shell ouvre l’application livrée à des extensions JavaScript : l’hôte reste en Rust, n’accorde ses capacités qu’une à une, et le script se recharge à chaud sans fork ni nouvelle version. La doc résume tout en une phrase que j’aurais aimé écrire : le comportement appartient à la fondation, la présentation appartient à l’application. Ceux qui viennent du web reconnaîtront la logique shadcn, Base UI en dessous et la couche stylée au-dessus. En tant que designer, c’est exactement la frontière que je veux pouvoir tracer dans une codebase.
Deux détails encore plus rares dans ce domaine. L’accessibilité AccessKit est intégrée à la couche d’interaction — rôles, noms, états, actions — et non greffée après coup. Et on peut piloter pointeur et clavier dans des fenêtres headless pour tester de vrais composants : état, focus, layout, accessibilité.
Les limites sont documentées, et c’est rafraîchissant. Le WebAssembly fait tourner les mêmes composants dans le navigateur, mais reste réservé aux vitrines : ce n’est pas un chemin supporté pour livrer une application web. Le mobile est expérimental et volontairement restreint ; l’équipe ne prétend pas concurrencer Flutter. Desktop d’abord, clairement.
Si vous concevez un logiciel de bureau où l’information déborde — trading, IDE, console d’exploitation — GPUI Kit mérite une fenêtre de votre temps. Moi, c’est cette séparation entre comportement et présentation qui me donne envie d’y construire quelque chose.
Sources
