FastUI : créer des interfaces web plus rapidement et plus efficacement avec Python

• FastUI propose une nouvelle manière de construire des interfaces utilisateur d’applications web avec du code Python déclaratif
• Un ensemble de modèles Pydantic et d’interfaces TypeScript qui définissent l’interface utilisateur
• Les développeurs Python peuvent créer des web apps réactives avec React sans utiliser JavaScript ni npm
• Les développeurs front-end peuvent se concentrer sur la création de composants réutilisables sans devoir faire du copier-coller à répétition
• Cela permet une véritable séparation des responsabilités : le backend définit toute l’application, tandis que le front-end implémente uniquement l’interface utilisateur pour tous les utilisateurs
• Nombreux composants fournis par défaut : authentification par jeton, GitHub OAuth, Markdown, Text, Paragraph, Heading, Code, Button, Link, Navbar, Modal, ServerLoad, Image, Iframe, Video, Table, Pagination, ModelForm

Utilisation concrète

• FastUI se compose de quatre éléments :
  • package PyPI fastui : fournit des modèles Pydantic et des utilitaires pour les composants UI. Il fonctionne très bien avec FastAPI, mais n’en dépend pas et peut aussi être utilisé avec d’autres frameworks web Python.
  • package npm @pydantic/fastui : package React TypeScript qui permet d’implémenter ses propres composants tout en réutilisant la mécanique et les types de FastUI.
  • package npm @pydantic/fastui-bootstrap : implémente/personnalise tous les composants FastUI à l’aide de Bootstrap.
  • package npm @pydantic/fastui-prebuilt : fournit une version précompilée d’une application React FastUI, sans qu’il soit nécessaire d’installer des packages npm ni de construire quoi que ce soit soi-même. Le package Python fournit une simple page HTML qui sert cette application.

Principes (version longue)

• FastUI est une implémentation des principes RESTful, mais pas au sens habituellement compris : il suit les principes définis dans la thèse de doctorat de Roy Fielding.
• Selon les principes RESTful, le front-end n’a pas besoin de connaître l’application qu’il construit ; il doit seulement fournir tous les composants nécessaires à la composition de l’interface.
• Construire une application de cette façon présente plusieurs avantages importants :
  • il suffit d’écrire le code à un seul endroit pour créer de nouvelles fonctionnalités ;
  • il est possible de séparer complètement le déploiement du front-end et du backend ;
  • il est possible de réutiliser un ensemble de composants open source, car ceux-ci n’ont pas besoin de connaître le contexte dans lequel ils seront utilisés ;
  • Pydantic, TypeScript et JSON Schema permettent de garantir que les deux côtés communiquent via un schéma convenu.

Au-delà de Python et React

• Ce principe ne se limite pas aux applications Python et React : il peut être utilisé avec n’importe quel front-end et backend qui implémentent le schéma, à condition qu’ils communiquent en utilisant le même schéma convenu et le même encodage.

Avis de GN⁺

• FastUI a le potentiel de simplifier le processus de développement en offrant aux développeurs backend un moyen efficace d’étendre une application sans développement front-end supplémentaire.
• Cette technologie clarifie la répartition des rôles entre front-end et backend, créant un environnement où l’expertise de chacun peut être exploitée au maximum.
• FastUI est encore un projet en cours de développement ; sa stabilité et ses fonctionnalités doivent donc être examinées avec soin avant toute utilisation en production.
• Lors de l’adoption de FastUI, il faut prendre en compte la compatibilité avec les workflows front-end existants, la réutilisabilité et l’extensibilité des composants, ainsi que la maintenance à long terme du projet.
• Les bénéfices potentiels de ce choix sont une réduction du temps de développement et un workflow centré sur le backend, mais en contrepartie la flexibilité du front-end peut être plus limitée, et le support communautaire ainsi que la documentation peuvent être relativement plus faibles.

[GN⁺]

Avis sur Hacker News

• Avis sur le couplage entre la couche de présentation et le code

  • Couplage entre la couche de présentation et le code : la couche de présentation ne devrait pas être trop étroitement liée au code. Un langage de templates est plus adapté que Python, et il est préférable de pouvoir rendre les templates dans différents langages.

• Expérience de développement d’applications avec FastUI et Streamlit

  • Utilisation de FastUI et Streamlit : le prototypage a été réalisé avec Streamlit, mais cela s’est parfois révélé inconfortable. FastUI a encore des lacunes, mais pour des applications légères, son utilisation a permis d’obtenir une réactivité plus rapide que Streamlit.

• Avis sur Django et HTMX

  • Django et HTMX : la combinaison de Django et HTMX est élégante et fonctionne rapidement. Elle permet d’envoyer uniquement le code rendu côté frontend, tout en gardant la possibilité de gérer la base de données quand l’échelle grandit.

• Utilité des applications internes pour le traitement des événements côté serveur

  • Traitement des événements côté serveur : ce concept n’est pas nouveau, et il existe d’autres exemples comme Solara, basé sur React, ou NiceGUI, basé sur Vue. C’est très pratique pour les applications internes, mais il faut accepter une légère latence lorsque les événements de tous les contrôles sont traités côté serveur.

• Multiplication des frameworks frontend nécessitant un serveur backend

  • Complexité des frameworks frontend : de nombreux frameworks frontend doivent exécuter un serveur backend pour rendre du HTML de base. On peut se demander si les fonctionnalités qu’ils offrent justifient réellement cette complexité.

• Comparaison des expériences entre FastUI et NiceGUI

  • FastUI et NiceGUI : NiceGUI offre une expérience agréable dès la première utilisation. FastUI ressemble surtout à un adaptateur de formulaires pour les modèles Pydantic.

• Impact des progrès de l’IA sur les cas d’usage de ce type de projet

  • IA et développement frontend : l’idée de permettre aux développeurs backend de générer rapidement une UI dans leur propre langage reste valable, mais le fait de pouvoir produire une UI de base en quelques heures avec l’IA pourrait réduire la nécessité de tels projets.

• Expérience de développement de side projects avec Dart/Flutter

  • Utilisation de Dart/Flutter : écrire des side projects avec Dart/Flutter permet de réduire au minimum les frictions et les contraintes. S’il fallait développer une application web et que Flutter n’était pas adapté, HTMX serait le choix privilégié.

• Comparaison avec Java Server Faces et limites des abstractions côté serveur

  • Expérience avec Java Server Faces : cela rappelle Java Server Faces. Les tentatives de déplacer les subtilités du développement frontend vers des abstractions côté serveur ne fonctionneront probablement que pour un ensemble limité d’applications, comme les interfaces d’administration.

• Question sur la pertinence des allers-retours avec le serveur pour construire une interface utilisateur

  • Allers-retours avec le serveur : cela soulève la question de savoir si faire un aller-retour vers le serveur à chaque interaction côté client est toujours une bonne idée pour construire une interface utilisateur.