Flet 1.0 : un framework Python pour applications multiplateforme sur Flutter
En bref
- Flet 1.0 est sorti, c'est une couche Python au-dessus de Flutter permettant de construire des applications desktop et mobile cross-platform en Python.
- La valeur affichée est la vitesse et la couverture (tous les OS majeurs) sans passer par Dart, avec une distribution facile.
- Le fil HN révèle des tensions : partisans convaincus vs. sceptiques sur l'intérêt d'ajouter une abstraction de plus, et des doutes sur la maturité (documentation, edge cases, services comme Bluetooth).
Ce que dit la source
Flet positionne le framework comme la réponse pour les développeurs Python cherchant à construire des applications GUI modernes et multiplateforme sans sacrifier la performance ni la portabilité. L'approche est de wrapper Flutter (écrit en Dart/C++) pour offrir une API Python, évitant ainsi le travail natif par langage tout en conservant les performances du rendu Flutter.
- Flet est une couche Python sur Flutter, pas un framework indépendant : les utilisateurs accèdent aux widgets Flutter via une interface Python
- Support multiplateforme revendiqué : desktop (Windows, macOS, Linux) et mobile (iOS, Android), ainsi que web
- Documentation et exemples limités selon plusieurs commentateurs, créant une friction pour les nouveaux utilisateurs confrontés à des problèmes de layout ou d'alignement
- Service Bluetooth absent des fonctionnalités supportées, ce qui réduit l'intérêt pour certains cas d'usage matériel
- Dépendances du projet aux contributions d'IA (Claude, Copilot) mentionnées comme risque potentiel par un commentateur pour la pérennité
Dans les commentaires
Débat partage entre enthousiasme pragmatique et scepticisme de principe. Pas de consensus sur l'utilité réelle d'ajouter une abstraction Python supplémentaire dans une stack déjà fragmentée (Flutter, Dart, Python). Les partisans valorisent la simplicité et la couverture ; les détracteurs dénoncent la complexité accrue, la dépendance documentaire, et questionnent la pertinence de Python pour l'infra.
- Plusieurs commentateurs rejettent le concept même d'une surcouche interprétée (Python sur Flutter) comme source de problèmes diagnostiques supplémentaires comparé au natif ; un lecteur cite son expérience frustrante avec Xamarin, React Native et Electron
- Tension sur la stratégie de design : Flet réinvente certains widgets Flutter (ex. Container) au lieu de les exposer directement, ce qui éloigne les utilisateurs de la documentation et des solutions Flutter existantes
- Maturité contestée : deux utilisateurs rapportent des obstacles concrets (layouts, Bluetooth) et reconnaissent que le framework n'est pas encore prêt pour leur besoin, mais envisagent un retour dans 1-2 ans
- Critique large sur Python lui-même en tant que choix pour l'infrastructure : un commentateur estime que le langage encourage les mauvaises abstractions et les bugs subtils, indépendamment du framework
Alternatives citées : Kivy (framework Python legacy, l'alternative la plus citée mais jugée clunky), Tauri (approche modulaire, Rust + web), Flutter (natif, en Dart), React Native, Electron, développement natif par plateforme (Kotlin, Swift, C#).
Notre lecture
Flet répond à un cas d'usage réel : les équipes attachées à Python et cherchant une sortie desktop/mobile rapide sans apprendre Dart ou Kotlin/Swift. La preuve existe (au moins un utilisateur l'utilise en production). Mais le fil expose les limites : c'est un outil de gateway plutôt qu'une solution de long terme. Pour les DSI et tech leads, c'est « à tester sur un prototypage interne », pas à retenir pour une app critique. La dépendance à la couche Flutter (et son évolution) reste un risque structural. Les équipes sans expertise Python existante devraient préférer Tauri ou Flutter direct.