Show HN : une bibliothèque GUI Rust via Flutter

 (cjycode.com)
3 points par GN⁺ 2024-08-12 | 1 commentaires | Partager sur WhatsApp
  • Rust a été désigné pendant 8 ans comme le « langage de programmation le plus apprécié », et beaucoup de personnes veulent écrire des applications GUI en Rust.
  • Partage d’une approche utilisant Flutter et flutter_rust_bridge
  • Avantages
    • Flutter est une plateforme populaire et mature, utilisée par de nombreux développeurs et des marques connues, avec un vaste écosystème qui permet d’implémenter facilement les fonctionnalités souhaitées
    • La fonctionnalité de « hot reload » accélère le développement UI, et le support cross-platform permet d’exécuter la même base de code sur plusieurs plateformes
  • Inconvénients
    • Cette approche n’est pas 100 % pure Rust
      • Cependant, cela ressemble à beaucoup d’autres UI Rust qui utilisent des macros ou d’autres langages comme HTML/CSS/Slint pour écrire un DSL personnalisé
    • Il existe des critiques concernant la plateforme web
      • Elle convient mieux aux « apps » web et autres plateformes (par ex. Google Earth, l’éditeur d’animations de Rive, etc.) qu’aux pages web statiques
    • Flutter nécessite beaucoup de code boilerplate

Qu’est-ce que flutter_rust_bridge ?

  • Il crée un pont entre deux langages pour les faire fonctionner comme un seul
  • Convertit automatiquement divers types, &mut, l’async, les traits, les résultats, les closures, etc.
  • Au-delà de l’implémentation d’une GUI Rust avec Flutter, il existe de nombreux autres cas d’usage
    = par exemple utiliser n’importe quelle bibliothèque Rust dans Flutter, ou écrire en Rust des parties comme les algorithmes et le reste en Flutter

À lire aussi

1 commentaires

 
GN⁺ 2024-08-12
Commentaires sur Hacker News

  • Je l’ai utilisé pendant plusieurs années de développement d’apps, et dans l’ensemble j’en ai été satisfait

    • La mise à niveau de la v1 vers la v2 n’a pas été difficile, et la v2 a apporté de grands changements avec beaucoup de fonctionnalités utiles, une meilleure expérience de génération de code, la prise en charge de l’async de tokio, etc.
    • Écrire la logique métier en Rust et utiliser Dart pour le frontend s’est révélé très efficace
    • Je trouve Flutter/Dart plus facile à comprendre que React
    • Merci à @fzyzcjy pour son travail sur FRB

  • Je ne vois pas très bien l’intérêt d’écrire l’UI en Dart plutôt qu’en Rust, mais je suis fan de flutter_rust_bridge

    • Le travail de fzyzcjy et de la communauté pour permettre d’appeler du code Rust de manière fluide depuis Dart est un énorme atout pour les apps Flutter
    • Pendant le week-end, j’ai reconstruit ImageOptim avec Flutter, et j’ai pu créer une app plus puissante et plus rapide grâce aux bibliothèques d’images Rust
    • Grâce à l’intégration de Rust, l’app est plus capable et plus rapide

  • Bel effort. J’utilise actuellement Tauri et je suis curieux de connaître les avantages et inconvénients des deux approches

  • J’utilise Flutter pour l’UI desktop et Rust pour le backend

    • J’utilise gRPC au lieu d’un bridge pour séparer les deux parties
    • Je pense que cette approche est agnostique vis-à-vis du langage et offre une interface plus propre pour mocker le backend depuis le frontend
    • L’UI et le backend peuvent être placés sur des machines différentes pour mettre en place une véritable architecture client/serveur
    • L’inconvénient est que l’interface peut être plus verbeuse

  • Bien joué. Je n’ai entendu que du bien de rust_flutter_bridge

    • Je me demande à quel point Flutter est plus lourd que le natif mobile (Java, Swift) en comparaison de la taille finale de l’app, ainsi que du point de vue des performances UI

  • J’aimais l’approche de Flutter pour construire l’UI, mais je n’aimais pas vraiment Dart

    • En théorie, je me demande s’il ne serait pas possible de créer un langage de programmation dédié uniquement à l’UI
    • Un langage pouvant s’interfacer avec les principaux langages de programmation, par exemple à la manière du format IDL de protobuf, mais qui déclarerait des interfaces utilisateur au lieu de définir des données
    • Cela fait penser à QT et XAML, mais QT n’est pas open source et XAML semble ne plus être vraiment utilisé depuis longtemps

  • Je ne pense pas que le Material Design de Google et ses effets un peu tape-à-l’œil soient ce qu’il y a de plus réussi visuellement

  • Je me demande ce qu’il en est de la prise en charge de l’accessibilité (a11y)

    • Je n’ai rien trouvé à ce sujet dans la documentation, mais j’ai du mal à imaginer qu’on puisse lancer un toolkit GUI en 2024 sans support de l’accessibilité, donc je me demande pourquoi ce n’est pas mentionné

  • C’est bien meilleur que de dépendre d’un shell Chrome ou de widgets web, bravo pour l’effort

  • Intéressant. IIUC, je me demande si cela a été réalisé à l’aide d’une traduction entre sources

    • La documentation est rédigée de façon claire pour l’utilisateur, ce qui est impressionnant
    • J’aimerais en savoir plus sur cette approche et sur la comparaison avec les frameworks web Rust basés sur wasm
    • Un avantage de combiner Rust et Flutter est que Flutter est déjà un framework complet, et qu’il est possible de partager du code et des structures de données entre les côtés serveur et client