FastHTML – Modern web applications in pure Python

Original Article ↗ Hacker News Discussion ↗

Overview & Goals

  • Framework for building modern web apps in pure Python, using server-rendered HTML plus htmx for interactivity.
  • Built on ASGI/Starlette/Uvicorn with a Python “component” system (FastTag) instead of templates.
  • Aim: make web dev enjoyable again for Python users, minimize boilerplate, expose underlying web primitives instead of hiding them.

Target Users & Use Cases

  • Especially pitched at Python developers who dislike the JS toolchain or heavy frontend frameworks.
  • Seen as a good fit for: data/ML folks, hobbyists, internal tools, and small-to-medium apps; some users also consider it for full production sites.

Architecture & Technology Choices

  • Uses functional HTML builders (e.g., Div(…)) as a 1:1 mapping to tags; no extra template language.
  • Strong emphasis on “locality of behavior” and hypermedia: return HTML fragments over APIs where possible.
  • Encourages async I/O; integrates cleanly with websockets.

Comparisons to Other Frameworks

  • Django: praised but viewed by some as heavy/complex and not designed around htmx/ASGI; FastHTML is pitched as leaner and more direct.
  • FastAPI/Starlette: FastHTML sits on top with more batteries for HTML/htmx.
  • Streamlit/Gradio/Dash/Shiny: those are seen as great for quick data apps but limiting off the “happy path” and visually/opinionated; FastHTML offers more control and generality.
  • Reflex.dev and ReactPy: these hide web foundations behind abstractions; FastHTML intentionally does not.
  • htpy, ludic, other HTML builders: similar ideas; debates around syntax and ergonomics.

HTML-in-Python vs Templates / SPAs

  • Supporters: prefer Python components over template DSLs; better refactoring, tooling, typing, and reuse; no need for designers to touch logic-heavy templates.
  • Critics: find Div(Strong(...)) style unreadable, “Java-like,” and hostile to designers; worry about coupling frontend to Python, inability to drop in off-the-shelf HTML templates, and long-term maintainability.
  • Some argue HTML templating is legacy and should “die”; others strongly prefer classic templates or SPA+API separation.

Async, Scaling, and LLM Workloads

  • Recommended pattern: run LLMs on separate inference services or servers; use async HTTP from FastHTML so calls don’t block.
  • Uvicorn workers and async help with scaling; claims of low CPU use on modest hosting.
  • Some still distrust Python’s performance and threading, citing past issues and general slowness vs lower-level languages.

Ecosystem, Databases, and Tooling

  • Not yet full “Django-style batteries included,” but has a lightweight SQLite wrapper (Fastlite); plans for SQLAlchemy/Alembic integration.
  • Suggests Starlette test client for testing.
  • Early ecosystem: starter UI wrappers for Bootstrap, Flowbite, DaisyUI; mention of Pico CSS.
  • Packaging via pip; community added conda-forge support.

Critiques, Code Quality & Longevity

  • Concerns about mixing concerns, global-state examples in docs, and difficulty for dedicated frontend devs/CSS designers.
  • Some complain about repo style (nbdev, lack of visible linters/formatters, “old-style” Python).
  • Doubts about long-term maintenance and risk of yet another incompatible Python web stack; others argue experimentation is healthy and frameworks can coexist.