Hyperflask – Full stack Flask and Htmx framework

Original Article ↗ Hacker News Discussion ↗

Overall reception

  • Many commenters find Hyperflask attractive: “simple, easy, batteries-included” Flask + HTMX with a pleasant design.
  • Some are excited to try it for greenfield apps, especially those already using Flask, Tailwind/DaisyUI, and HTMX.
  • Others see it as “too abstracted” given Flask and HTMX’s original simplicity, and question whether it adds enough beyond vanilla Flask + HTMX.

Flask vs FastAPI / async debate

  • Several question choosing Flask in 2025, arguing that non-async foundations limit scalability and that FastAPI (or Litestar) offer integrated async, DI, OpenAPI, and Pydantic.
  • Defenders of Flask emphasize:
    • Stability, maturity, and small issue backlog vs FastAPI’s high-maintenance surface area.
    • Simplicity of threaded request model and global context (g), and skepticism about async Python ergonomics and bugs.
    • Many real-world apps don’t need massive scale; “boring tech” is a plus.
  • Counterpoints:
    • Flask lacks first-class typing, DI, and async; add-on libraries exist but feel fragmented or under-maintained.
    • Some see building a new sync-only framework as “bizarre,” though others call this FUD and argue that not all scaling needs async.

HTMX: strengths, limits, and team fit

  • Solo developers report very positive experiences with HTMX + server-rendered HTML (Flask/Django/FastAPI/Go).
  • One concern: HTMX is “structureless,” making larger teams harder to coordinate vs opinionated SPA frameworks.
  • Big debate over state management:
    • Critique: with HTMX, too much UI state must live in URL/session/cookies/DB, which becomes spaghetti for complex UIs with many zones/popups; React/Vue’s centralized state is seen as simpler.
    • Rebuttals: that’s just “web dev 101”; URL vs session vs DB is a design decision, and modern SPAs often duplicate server state and add bloat.
    • Some hypermedia advocates go further: most state should live on the server (even popups), trading some latency for consistency and multi-user features; others reject storing such ephemeral UI state server-side.

Framework design: components, jinjapy, ORM

  • Interesting features called out:
    • Components built on Jinja macros.
    • “Locality of behavior” approach: controller + template in one .jinjapy file, inspired by Astro pages and old-school PHP.
    • sqlorm: a new lightweight ORM heavily based on Pydantic and SQL-in-docstrings; intriguing but seen as too new for production.
  • Concerns:
    • “Batteries included” means a long list of Flask extensions; some wish the component system were more backend-agnostic or Django-compatible.

Alternatives and ecosystem

  • Mentioned alternatives: FastAPI + HTMX, Litestar (with HTMX support), Quart (async Flask), Go + Templ + HTMX, plain Django + HTMX, and FastHTML.
  • Django’s admin and “apps” structure are missed by some when using lighter frameworks; a richer admin story for Hyperflask is requested for serious adoption.