Hyperflask – Full-Stack-Framework für Flask und Htmx

 (hyperflask.dev)
11 Punkte von GN⁺ 2025-10-17 | 1 Kommentare | Auf WhatsApp teilen
  • Ein backendzentriertes Web-Framework auf Flask-Basis, das schnelles und einfaches Zustandsmanagement ohne komplexe Frontend-Verwaltung bietet
  • Führt eine mit HTMX kombinierte Komponentenarchitektur ein, die eine serverbasierte Zusammenstellung interaktiver UIs ermöglicht
  • Integration moderner Web-Stacks wie dateibasiertes Routing, esbuild + TailwindCSS Asset-Pipeline und automatisierte Deployment-Umgebung
  • Integriert verschiedene Grundfunktionen wie E-Mail-Versand (MJML), Hintergrundaufgaben, SSE-basierten Push, Übersetzung und Authentifizierung
  • Unterstützt durch containerbasierte Standardisierung von Entwicklungs- und Deployment-Umgebungen sowie VS Code-Integration eine einfache Einrichtung und Cloud-Deployments

Überblick: Ein backendzentriertes Web-App-Framework auf Flask-Basis

  • Hyperflask ist ein Python-Web-Framework, das auf Flask aufsetzt und einen backendgetriebenen Entwurfsansatz verfolgt
  • Es reduziert die Komplexität des Frontend-Zustandsmanagements und bietet eine schlanke, serverzentrierte Architektur
  • Moderne Web-Technologien wie HTMX, TailwindCSS und esbuild sind standardmäßig enthalten
  • Durch die HTMX-Integration lassen sich Echtzeit-Interaktionen ohne vollständiges Neuladen der Seite umsetzen
  • Mit einer Komponentenarchitektur können Backend- und Frontend-Komponenten wiederverwendet werden
    • Durch die Einführung einer komponentenorientierten Struktur in die Flask-Umgebung lassen sich Frontend- und Backend-Komponenten direkt in Jinja-Templates verwenden
    • Es können serverseitige Komponenten in Verbindung mit HTMX erstellt werden, die sich auch natürlich mit React oder Web Components integrieren lassen
    • Das erhöht Wiederverwendbarkeit und Wartbarkeit des Codes und bietet eine auch für die Entwicklung großer Apps geeignete Struktur
  • Unterstützung für dateibasiertes und appbasiertes Routing
    • Verwendet ein neues .jpy-Dateiformat, das Python-Code und Jinja-Templates kombiniert
    • Inspiriert vom Seitensystem von Astro können Routendefinition und UI-Aufbau an einer Stelle verwaltet werden
    • Dadurch wird die Routing-Konfiguration vereinfacht und das Hinzufügen neuer Seiten wird intuitiv
  • Offenes Ökosystem
    • Hyperflask hat eine kleine eigene Codebasis und ist aus der organischen Kombination mehrerer Flask-Erweiterungen aufgebaut
    • Jede Erweiterung wird als eigenständiges Projekt verwaltet und kann frei ausgewählt und kombiniert werden
    • Alle Projekte sind in der Hyperflask-Organisation auf GitHub öffentlich zugänglich und fördern eine individuell anpassbare Framework-Zusammenstellung
  • „Batteries Included“
    • MJML-E-Mail-Versand, dramatiq-Hintergrundaufgaben, SSE-basierten Echtzeit-Push, gettext-basierte Übersetzung (i18n)
    • Authentifizierung und Session-Management, Bildoptimierung und Streaming, Generierung statischer Inhalte usw.
    • Bietet ein sofort einsatzbereites Funktionsset auf Produktionsniveau ohne zusätzliche Konfiguration
    • SQL-zentriertes ORM (sqlorm), optimiert für SQLite
  • Umgebungskonfiguration und Deployment
    • Standardisiert containerbasierte Entwicklungs- und Betriebsumgebungen, um Probleme bei der Umgebungskonfiguration zu minimieren
    • Die enge Integration mit VS Code erleichtert lokale Entwicklung und Debugging
    • Unterstützt einfache Deployments auf VPS oder bei großen Cloud-Diensten

Zusammenfassung

  • Hyperflask erweitert das Flask-Ökosystem und bietet ein modernes Full-Stack-Python-Webentwicklungserlebnis als Framework der nächsten Generation
  • Mit HTMX und Komponentensystem, dateibasiertem Routing und einer containerstandardisierten Entwicklungsumgebung wird maximale Produktivität bei minimaler Konfiguration erreicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-17
Hacker-News-Kommentare

  • Als Ersteller von hyperflask freue ich mich sehr, nach langer Vorbereitung das Projekt endlich vorstellen zu können.
    Den ausführlichen Ankündigungsbeitrag gibt es hier.
    Ich würde mich über viel Feedback freuen.

    • Es wäre vielleicht noch besser gewesen, wenn das eher eine Bibliothek gewesen wäre, die nicht an ein Backend gebunden ist.
      Ich habe bereits ein Django-Projekt mit über einer Million Zeilen und kann nicht einfach wechseln; ich frage mich, ob es eine einfache Möglichkeit gibt, das in eine Django-App zu integrieren.

    • Als htmx-Entwickler sieht dieses Projekt wirklich großartig aus.

    • Ein Kollege hat mit der Kombination aus flask/htmx/sqlalchemy interne Apps gebaut und gute Ergebnisse erzielt, bekam aber keine Open-Source-Freigabe.
      Deshalb bin ich gespannt auf den neuen Ansatz von hyperflask.

    • Mich würde interessieren, warum sqlorm als ORM gewählt wurde.
      Ich war lange von der Python-Entwicklung weg, dachte aber, alle nutzen SQLAlchemy; sqlorm ist mir nicht geläufig.

    • Beeindruckend, wie dieses neue Framework HTMX aufgreift.
      HTMX stößt verschiedene neue Strömungen an, die JS und React ersetzen sollen.
      Viele werden auch die Kombination aus Python und Flask mögen, und bei serverseitigem HTMX sind Komponenten zentral.
      Außerdem ist die Website angenehmer für die Augen als FastHTML.
      Im Vergleich zu harcstack.org:

      Language: Python vs. Raku  
Web framework: Flask vs. Cro  
ORM: ?? vs. Red  
Components: beide  
HTML: Templates vs. funktional  
CSS: DaisyUI/Tailwind/Bootstrap vs. Pico

      Durch diese Auswahl dürfte sich eine deutlich breitere Nutzerschaft ansprechen lassen.
      Der HARC-Stack als Vergleich wirkt eher attraktiv für eine kleine Gruppe, die HTML wie eine serverseitige Version der Elm-Sprache funktional behandeln will oder eine Allergie gegen die Denormalisierung von Tailwind hat.

  • Beim Entwickeln von Web-Apps mit htmx hatte ich das Gefühl, in einer Sackgasse zu landen.
    Das Hauptproblem ist, dass der Frontend-Anwendungszustand in der URL gespeichert werden muss.
    Bei modernen UIs mit vielen Bereichen, Widgets, Pop-ups usw., die jeweils lokalen Zustand und Navigation brauchen, ist es sehr schwierig, alles in einer einzigen globalen URL unterzubringen.
    Es ist je nach Bedarf sogar noch schwerer, etwas bewusst nicht in die URL zu packen.
    In Frameworks wie React oder Vue, die einen eigenen State Store bieten, ist das leicht lösbar.
    Wenn man es wie ein phpBB-Forum aufbaut, ist es okay, aber heutige Nutzer erwarten ein weiterentwickeltes Erlebnis.

    • Es ist nicht nötig, Zustand nur in der URL zu speichern.
      Es gibt viele Wege: serverseitiger Speicher, Sessions, localstorage, Cookies usw.
      Zum Beispiel braucht eine benutzerdefinierte App-Layout-Anpassung keine URL, aber bei Suchergebnissen, die geteilt werden sollen, müssen die Suchparameter unbedingt in der URL stehen.
      Man muss sich überlegen, was genau erreicht werden soll.
      Und unter dem Schlagwort „moderne UI“ viele Widgets und Pop-ups alle auf einem Bildschirm bzw. unter einer URL zu bündeln, kann eher übermäßige Komplexität sein.
      Oft ist der State Store von React/Vue nur eine Verdopplung dessen, was ohnehin schon auf dem Server verwaltet werden kann.

    • Auch der Hypermedia-Ansatz kann ausreichend komplexe UIs abbilden.
      Man muss nicht auf allem in der URL bestehen.
      Mit Sessions, Cookies, Tab-IDs usw. kann Zustand pro Tab geteilt oder isoliert werden, und der Zustand lässt sich aus der Backend-Datenbank laden.
      Hypermedia ist auch in Echtzeit-/Multiplayer-Umgebungen stark.
      Eher ist die Schwäche von HTMX, dass es nicht noch mehr Zustand ins Backend verlagert, und ich fände es besser, wenn es da mutiger wäre.

    • Ich glaube einfach, dass das nicht zu meinem Anwendungsfall passt.
      Es ist auch interessant, React/Vue für „einfach“ zu halten.

    • Ich glaube nicht, dass React oder Vue alle Probleme lösen, die Nutzer erwarten.

    • Solange die Komplexität nicht extrem hoch ist, komme ich in der Praxis mit htmx (in Kombination mit unpoly, alpinejs und localstorage) in den meisten Fällen gut zurecht.

  • In hyperflask habe ich einige interessante Konzepte gefunden.

    • Komponenten-Implementierung: Link
    • Die Art, View und Controller in einer Datei zu bündeln: Link
      Allerdings sind Komponenten intern im Grunde nur normale Makros, daher frage ich mich, ob man nicht besser direkt Makros verwenden sollte.
      Auch die Wahl von Flask interessiert mich.
      Ich habe früher mit /dev/push einen ähnlichen Ansatz versucht und bin dann auf FastAPI + Jinja2 + Alpine.js + HTMX gewechselt.
      Ich habe erkannt, dass FastAPI nicht nur für APIs gedacht ist, und mich wegen des Async-Supports dafür entschieden.
      Ich mag Flask ebenfalls, hatte aber das Gefühl, dass es Grenzen hat.

    • Diese Art, View und Controller in einer Datei zu bündeln, erinnert mich an frühere PHP-Entwicklung.
      Je nach Projektgröße war das tatsächlich ein Vorteil, weil die Entwicklung deutlich einfacher wurde.

    • Ich denke auch, dass die Kombination FastAPI + HTMX sehr effektiv ist.

  • Aus meiner Erfahrung mit Django musste ich dank der Admin-Scaffolding-Funktionen fast nie selbst eine UI für Diagnose und Kundensupport bauen.
    Bei Projekten auf Basis anderer Frameworks implementiert man solche Funktionen selbst, und das Ergebnis ist oft nicht so zufriedenstellend wie bei Django.
    Es gibt viele attraktiv wirkende Frameworks wie Hyperflask, aber auf Djangos Admin-Framework zu verzichten, ist ein entsprechend hoher Preis.
    Mich würde interessieren, ob Leute echte Alternativen oder Ersatzmuster für Django Admin gefunden haben.

    • Ich hatte dasselbe Gefühl.
      Beim Wechsel zu FastAPI habe ich an Django vor allem die vielen Apps vermisst, aus denen sich ein Projekt zusammensetzt.
      Erst später wurde mir klar, wie bequem diese nach Funktionen gegliederte Struktur mit Migrationen, statischen Dateien, Templates usw. war.

    • Ich nutze meistens Supabase.
      Über die Supabase-Oberfläche schule ich auch Admins ein, damit sie dringende Verwaltungsaufgaben übernehmen können.
      Oder, wenn möglich, verwende ich Airtable als Backend.
      Aber meistens vermisse ich Django Admin sehr, und die Kombination Django+HTMX wirkte immer verlockend.

    • Es gibt auch Flask-Admin, aber das ist viel einfacher als Django Admin.
      Dieses Problem würde ich in Zukunft gern lösen.

  • Nachdem ich HTMX mit verschiedenen Frameworks ausprobiert habe, finde ich, dass die Kombination Go + Templ + HTMX Vielseitigkeit und Einfachheit gut verbindet.

    • Meiner Erfahrung nach ist Go zu wortreich, deshalb überlege ich eher, von Go+Templ+HTMX auf Flask + Jinja + HTMX umzusteigen.
      Die Art, wie in Go Templates definiert werden, empfinde ich als umständlich.

    • Die Kombination, die ich als Nächstes unbedingt ausprobieren möchte, ist FastAPI + Jinja2 + HTMX.
      Diesen Stack nutze ich gerade.

  • hyperflask wirkt, als stünde es im Widerspruch zur Philosophie von Flask und htmx.
    Es gibt zu viele Abstraktionsschichten, und auch Integrationspunkte mit htmx sind kaum sichtbar.
    Ich hatte eher einen Ansatz wie bei FastHTML erwartet, wo htmx eingebaut ist.

    • FastHTML macht mir wirklich viel Spaß.

  • Wenn bei Projekten eine starfield-Demo erscheint, hoffe ich immer auf eine Geschwindigkeitsregelung und einen Effekt, bei dem die Sterne dem Mauszeiger folgen.
    Ich würde mir wünschen, dass das in einer zukünftigen Hyperflask-Version hinzukommt.
    Das Projekt selbst ist großartig, und ich mag Htmx, aber in letzter Zeit schaue ich mir auch Datastar genauer an.

    • Wenn man den folgenden Code in der Konsole ausführt, bekommt man verschiedene Effekte wie Geschwindigkeitsanpassung.

      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"
});

    • Meinst du vielleicht Funktionen dieser Art?

    • nova.app ist das Beste, was ich bisher gesehen habe.

  • Wer mit HTMX eine vollständige Fullstack-Async-Erfahrung will, sollte sich auch Litestar ansehen.

  • Als ich es zum ersten Mal sah, fiel es mir schwer zu verstehen, warum man HTML-Templates direkt an Python-Controller-Dateien anhängen sollte.
    Es wirkte, als würde alles komplizierter, nur um sich eine einzige Render-Funktion zu sparen.
    Ich frage mich, was ich dabei übersehe.

  • Viele sprechen über die Grenzen von Flask und fragen „warum nicht FastAPI“, aber persönlich halte ich Litestar für die beste Alternative.
    Litestar bringt htmx-Unterstützung standardmäßig mit.
    Mehr Informationen gibt es hier.