Hyperflask – framework full stack Flask et Htmx

• Framework web orienté backend basé sur Flask, offrant une gestion d’état rapide et simple sans gestion complexe du frontend
• Introduction d’une architecture à composants combinée à HTMX, permettant de construire une UI interactive côté serveur
• Intègre une stack web moderne avec routage basé sur les fichiers, pipeline d’assets esbuild + TailwindCSS et environnement de déploiement automatisé
• Intègre en natif de nombreuses fonctionnalités de base comme l’envoi d’e-mails (MJML), les tâches en arrière-plan, le push basé sur SSE, la traduction et l’authentification
• Prend en charge une configuration simple et le déploiement cloud grâce à la standardisation des environnements de développement et de déploiement basés sur des conteneurs et à l’intégration avec VS Code

---

Aperçu : framework de webapps orienté backend basé sur Flask

• Hyperflask est un framework web Python fonctionnant au-dessus de Flask, avec une approche de conception pilotée par le backend
• Il réduit la complexité de la gestion d’état côté frontend et propose une architecture concise centrée sur le serveur
• Il embarque par défaut des technologies web modernes comme HTMX, TailwindCSS, esbuild
• L’intégration de HTMX permet de mettre en œuvre des interactions en temps réel sans rechargement complet de la page
• Son architecture à composants permet de réutiliser les composants backend et frontend
  • En introduisant une structure orientée composants dans l’environnement Flask, il devient possible d’utiliser directement des composants frontend et backend dans les templates Jinja
  • Il permet de créer des composants backend côté serveur combinés à HTMX, tout en s’intégrant naturellement avec React ou les Web Components
  • Il améliore la réutilisation du code et la maintenabilité, offrant une structure adaptée au développement d’applications de grande taille
• Prise en charge du routage basé sur les fichiers et sur les applications
  • Utilise un nouveau format de fichier .jpy combinant code Python et templates Jinja
  • Inspiré du système de pages d’Astro, il permet de gérer au même endroit la définition des routes et la composition de l’UI
  • Cela simplifie la configuration du routage et rend l’ajout de nouvelles pages plus intuitif
• Écosystème ouvert
  • Hyperflask conserve une base de code légère et se compose d’une combinaison organique de plusieurs extensions Flask
  • Chaque extension est gérée comme un projet indépendant, librement sélectionnable et combinable
  • Tous les projets sont publics dans l’organisation Hyperflask sur GitHub et encouragent une composition de framework personnalisée
• “Batteries Included”
  • Envoi d’e-mails MJML, tâches en arrière-plan avec dramatiq, push temps réel basé sur SSE, traduction (i18n) basée sur gettext
  • Authentification et gestion de session, optimisation et streaming d’images, génération de contenu statique, etc.
  • Fournit un ensemble de fonctionnalités de niveau production utilisables immédiatement sans configuration supplémentaire
  • ORM centré SQL (sqlorm), optimisé pour SQLite
• Configuration de l’environnement et déploiement
  • La standardisation des environnements de développement et de production basés sur des conteneurs minimise les problèmes de configuration
  • Son intégration étroite avec VS Code facilite le développement local et le débogage
  • Il prend en charge un déploiement simple sur VPS ou sur les principaux services cloud

Résumé

• Hyperflask est un framework nouvelle génération qui étend l’écosystème Flask pour offrir une expérience moderne de développement web Python full stack
• Grâce à HTMX, au système de composants, au routage basé sur les fichiers et à un environnement de développement standardisé par conteneurs, il permet d’atteindre une productivité maximale avec une configuration minimale

[GN⁺]

Avis Hacker News

• En tant que créateur de hyperflask, je suis très heureux de pouvoir enfin dévoiler ce projet préparé depuis longtemps.
  Vous pouvez consulter l’annonce détaillée ici.
  J’aimerais beaucoup avoir des retours variés.

  • J’aurais trouvé ça encore mieux si cela avait été une bibliothèque non liée à un backend particulier.
    J’ai déjà un projet Django de plus d’un million de lignes, donc je ne peux pas changer facilement, et je me demande s’il existe un moyen de l’appliquer simplement à une app Django.

  • En tant que développeur htmx, ce projet a l’air vraiment génial.

  • Un collègue avait créé une app interne avec une combinaison flask/htmx/sqlalchemy et avait obtenu de très bons résultats, mais n’avait pas réussi à faire valider l’open source.
    Donc j’attends avec intérêt cette nouvelle tentative de hyperflask.

  • Je me demande pourquoi sqlorm a été choisi comme ORM.
    Je suis un peu éloigné du développement Python depuis longtemps, mais je pensais que tout le monde utilisait SQLAlchemy, et sqlorm m’est assez inconnu.

  • Il est impressionnant de voir un nouveau framework adopter HTMX.
    HTMX stimule diverses nouvelles tendances susceptibles de remplacer JS et React.
    Beaucoup de gens aiment aussi la combinaison Python + Flask, et côté HTMX server-side, les composants sont essentiels.
    Et le site a aussi l’avantage d’être plus reposant pour les yeux que FastHTML.
    Par rapport à harcstack.org :

    Language: Python vs. Raku  
    Web framework: Flask vs. Cro  
    ORM: ?? vs. Red  
    Components: les deux  
    HTML: templates vs. fonctionnel  
    CSS: DaisyUI/Tailwind/Bootstrap vs. Pico  
    

    Avec ce type de choix, cela semble pouvoir attirer une base d’utilisateurs bien plus large.
    En comparaison, la stack HARC séduira probablement surtout une minorité attirée par une approche fonctionnelle de HTML, comme une version server-side du langage Elm, ou allergique à la dénormalisation de Tailwind.

• En développant une webapp avec htmx, j’ai eu l’impression d’arriver dans une impasse.
  Le principal problème est que l’état de l’application frontend doit être stocké dans l’URL.
  Avec les UI modernes composées de nombreuses zones, widgets, popups, etc., chacun ayant son propre état local et sa propre navigation, il devient très difficile de faire tenir tout cela dans une seule URL globale.
  Concevoir une app de manière à ne pas mettre l’état dans l’URL quand c’est nécessaire est encore plus difficile.
  Ce problème se résout facilement avec des frameworks comme React ou Vue, qui fournissent leur propre store d’état.
  Si l’on construit quelque chose comme un forum phpBB, ça va, mais les utilisateurs d’aujourd’hui attendent une expérience plus évoluée.

  • Il n’est pas nécessaire de conserver l’état uniquement dans l’URL.
    On peut utiliser un stockage serveur, des sessions, le localStorage, des cookies, etc.
    Par exemple, une personnalisation de la disposition de l’app n’a pas besoin d’URL, mais pour des résultats de recherche qu’on veut partager, les critères doivent absolument être dans l’URL.
    Il faut réfléchir à ce que l’on cherche à accomplir.
    Et mettre une multitude de widgets et popups sur un seul écran / une seule URL au nom de l’"UI moderne" peut au contraire introduire une complexité excessive.
    Souvent, la gestion d’état fournie par React/Vue duplique en fait quelque chose que le serveur pourrait déjà gérer entièrement.

  • L’approche hypermédia peut tout à fait gérer des UI complexes.
    Il n’est pas nécessaire d’insister pour tout mettre dans l’URL.
    On peut utiliser sessions, cookies, identifiants d’onglet, etc., pour partager ou isoler l’état par onglet, puis lire cet état depuis la base backend.
    L’hypermédia excelle même dans les environnements temps réel / multijoueurs.
    En réalité, le défaut de HTMX est plutôt de ne pas mettre encore davantage d’état dans le backend ; j’aimerais presque qu’il pousse cette logique plus loin.

  • Je pense simplement que cela ne correspond pas à mon cas d’usage.
    C’est d’ailleurs amusant de considérer que React/Vue sont "simples".

  • Je ne pense pas non plus que React ou Vue résolvent tous les problèmes que les utilisateurs attendent.

  • Sauf dans les cas de très forte complexité, en pratique j’arrive à couvrir la plupart des besoins sans difficulté avec htmx (associé à unpoly, alpinejs et localStorage).

• J’ai trouvé des concepts intéressants dans hyperflask.

  • Implémentation des composants : lien
  • Approche qui regroupe vue et contrôleur dans un seul fichier : lien
    Cela dit, les composants ne semblent être au fond que de simples macros en interne, donc je me demande s’il ne vaudrait pas mieux utiliser directement des macros.
    Je m’interroge aussi sur le choix de Flask.
    J’avais autrefois tenté une approche similaire avec /dev/push, avant de migrer vers une combinaison FastAPI + Jinja2 + Alpine.js + HTMX.
    J’ai compris que FastAPI ne servait pas qu’aux API, et je l’ai choisi parce que j’avais besoin du support asynchrone.
    J’aime aussi Flask, mais j’ai parfois eu l’impression qu’il avait ses limites.

  • Le fait de regrouper vue et contrôleur dans un même fichier me rappelle l’ancien développement en PHP.
    Selon la taille du projet, cela simplifiait clairement le développement, ce qui était un vrai avantage.

  • Je pense aussi que la combinaison FastAPI + HTMX est très efficace.

• D’après mon expérience avec Django, grâce aux fonctions d’admin scaffolding, j’ai rarement eu besoin de construire moi-même une UI pour le diagnostic ou le support client.
  Sur des projets basés sur d’autres frameworks, il faut souvent implémenter ce type de fonctionnalité à la main, et le résultat est souvent moins satisfaisant que celui de Django.
  Il existe beaucoup de frameworks séduisants comme Hyperflask, mais renoncer au framework d’administration de Django a un coût énorme.
  Je me demande si certains ont trouvé de vraies alternatives ou des patterns de remplacement à Django admin.

  • J’ai eu exactement la même impression.
    En passant à FastAPI, ce qui m’a le plus manqué de Django, ce sont les différentes apps qui structurent le projet.
    Je me suis rendu compte après coup à quel point il était pratique d’avoir une organisation par fonctionnalités pour les migrations, les fichiers statiques, les templates, etc.

  • J’utilise surtout Supabase.
    J’ai parfois formé des administrateurs à l’interface de Supabase pour qu’ils puissent gérer les urgences.
    Ou alors, quand c’est possible, j’utilise Airtable comme backend.
    Mais la plupart du temps, Django admin me manque énormément, et la combinaison Django + HTMX m’a toujours semblé très tentante.

  • Il existe aussi Flask-Admin, mais c’est bien plus simple que Django Admin.
    J’aimerais résoudre ce problème à l’avenir.

• Après avoir utilisé HTMX avec plusieurs frameworks, j’estime que la combinaison Go + Templ + HTMX associe très bien polyvalence et simplicité.

  • D’après mon expérience, Go est trop verbeux, au point que j’envisage plutôt de passer de Go+Templ+HTMX à Flask + Jinja + HTMX.
    Je trouve la manière de définir les templates en Go assez fastidieuse.

  • La prochaine combinaison que je veux absolument essayer est FastAPI + Jinja2 + HTMX.
    C’est la stack que j’utilise actuellement.

• J’ai l’impression que hyperflask va à l’encontre de la philosophie de Flask et de htmx.
  Il y a trop de couches d’abstraction et je ne vois pas vraiment les points d’intégration avec htmx.
  Je m’attendais plutôt à une approche avec htmx intégré, comme FastHTML.

  • J’utilise FastHTML avec beaucoup de plaisir.

• À chaque fois qu’un projet affiche une démo starfield, j’espère toujours avoir un réglage de vitesse et un effet qui suit le curseur de la souris.
  J’aimerais voir cela ajouté dans une prochaine version de Hyperflask.
  Le projet lui-même est excellent, et j’aime Htmx, mais récemment je garde aussi Datastar à l’œil.

  • En exécutant le code ci-dessous dans la console, on peut ajouter divers effets comme le réglage de vitesse.

    new WarpSpeed("warpdrive", {
      "speed": 20,
      "speedAdjFactor": 0.03,
      "density": 2,
      "shape": "circle",
      "warpEffect": true,
      "warpEffectLength": 5,
      "depthFade": true,
      "starSize": 3,
      "backgroundColor": "hsl(224,15%,14%)", 
      "starColor": "#FFFFFF"
    });
    

  • Je me demande si vous parlez de quelque chose comme ceci.

  • nova.app est de loin le meilleur exemple que j’aie vu jusqu’à présent.

• Si vous voulez une expérience Fullstack Async complète basée sur HTMX, Litestar mérite aussi le détour.

• À première vue, j’ai eu du mal à comprendre pourquoi il fallait ajouter directement des templates HTML dans les fichiers de contrôleurs Python.
  J’ai eu l’impression qu’on ajoutait de la complexité juste pour éviter une simple fonction de rendu.
  Je me demande ce que j’ai raté.

  • Cette approche s’inscrit dans le principe de Locality of Behavior, auquel htmx accorde beaucoup d’importance.
    Elle est inspirée des Astro Pages de l’écosystème JavaScript.
    En pratique, l’expérience développeur était aussi très bonne.
    • Explication de Locality of Behaviour
    • Présentation des Astro Pages

• Beaucoup parlent des limites de Flask et demandent « pourquoi pas FastAPI ? », mais personnellement, je pense que Litestar est la meilleure alternative.
  Litestar propose un support htmx intégré nativement.
  Plus d’informations ici.