Ludic: New framework for Python with seamless Htmx support

Original Article ↗ Hacker News Discussion ↗

A new Python web framework called Ludic aims to build HTML with typed, React-style components on the server and integrate seamlessly with htmx, sparking renewed interest in HTML-from-Python approaches. Commenters weigh the benefits of type safety, reusability, and keeping all logic in Python against concerns about mixing markup with backend code, maintainability on larger projects, and the complexity of async/ASGI. The conversation situates Ludic among many similar libraries and broader trends, with some preferring minimalist tools or separate frontends, and others seeing strong productivity gains in component-based server rendering.

Overall impressions of Ludic

  • Lightweight Python framework that builds HTML via “components,” integrates tightly with htmx, and uses Starlette and modern typing.
  • Some find the component example (a custom Link) illustrative of the style; others find it confusing or underwhelming as a first impression and want clearer framing and docs.
  • Several commenters like the idea of type-safe, reusable HTML components in Python and see productivity benefits.

HTML-in-Python vs templates

  • A recurring split: some dislike “sneaking HTML into Python” (or JavaScript) and prefer traditional templates and separation of concerns.
  • Others argue embedding HTML in Python:
    • Enables static analysis (mypy, linters, formatters, tests) over “templates.”
    • Improves reuse and composability versus many template engines.
    • Makes side effects more explicit (no hidden DB calls in templates).
  • Critics worry about tight coupling of front-end markup and back-end logic and long-term maintainability, especially as examples mix DB access with rendering.

Syntax, typing, and structured representations

  • Debate over using f-strings versus representing HTML as structured data/objects (SXML/hiccup-style).
  • Proponents of structured objects want easy traversal, pattern-matching, and better tooling.
  • Author-side constraints: wants to stay within standard Python typing; notes lack of macro systems like Rust’s Yew/JSX-style typing.

Async/ASGI concerns

  • Some report being “burned” by Python async: surprising bugs, difficult debugging, and concurrency pitfalls.
  • aiohttp-style single-threaded async servers can suffer from head-of-line blocking and underuse multi-core hardware.
  • Others note concurrency is hard in any ecosystem, not unique to Python.

Comparisons to other HTML generation tools

  • Many similar ideas cited: dominate, hotmetal, neat-html, htpy, fast_html, Mixt/pyxl, yattag, etc., plus non-Python analogs (Elm, hiccup, Kotlin’s kotlinx-html).
  • Some report significant productivity and speed gains over Jinja-like string templates.

htmx’s role and integration limits

  • htmx is praised for productivity but characterized as an “appliance,” not a full framework.
  • Works well when used purely via HTML attributes and server-rendered snippets.
  • Integrating more complex client-side JS and state (React, jQuery, etc.) can be awkward due to lifecycle interactions; some suggest Alpine.js, Stimulus, or custom elements for light interactivity.

Skepticism about new frameworks

  • A few express fatigue with ever-new web frameworks and worry that wrapping htmx in larger abstractions reintroduces complexity HTMX tries to avoid.
  • Preference from some for minimal, composable libraries over opinionated, full-stack frameworks.