Ludic: New framework for Python with seamless Htmx support

Original Article ↗ Hacker News Discussion ↗

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.