Mesh: I tried Htmx, then ditched it

Original Article ↗ Hacker News Discussion ↗

Blazor, LiveView, and server-driven UIs

  • Several commenters praise Blazor for letting them avoid JavaScript and share C# between front and back end; others find it heavy, complex, and overkill for simple needs.
  • Concerns: Microsoft’s history of abandoning tech, comparison to Silverlight, and risk of vendor lock-in. Supporters reply that Blazor is MIT-licensed and built on open web standards.
  • Performance criticisms focus on WASM: large bundle sizes (multi‑MB to tens of MB), high memory use, slow on low‑power devices (e.g., Raspberry Pi, mobile). Rust/Leptos is suggested as a more efficient WASM path due to lack of GC and true native compilation.
  • Phoenix LiveView is frequently cited as more efficient and ergonomic, especially given BEAM’s preemptive actors; some teams use LiveView at home “for sanity” and Blazor or Vaadin at work.
  • Skeptics liken Blazor to a modern WebForms/GWT/JSF: great for .NET shops that won’t learn browser tech, but questionable future beyond that niche.

HTMX: strengths, limits, and fit

  • Many agree HTMX is excellent for “oldschool” multipage apps, admin dashboards, and low‑to‑medium interactivity, with minimal dependency churn.
  • Several report HTMX becoming hard to manage once apps exceed a certain complexity (drag‑and‑drop, rich component state, heavy interdependence), leading them to React or other frameworks.
  • Debate over complexity: defenders say it’s easy if you know HTML; critics note quirks, custom headers, attribute inheritance, and trigger DSLs that rival a SPA framework in conceptual load.
  • The HTMX author explicitly says this app wasn’t a good fit, points to guidance on when to use hypermedia, and highlights upcoming improvements (e.g., better shadow DOM handling, experiments like fixi.js).
  • Philosophical divide: HTMX fans generally don’t want something that “feels like an SPA”; they value high cohesion (page and endpoints together) and low coupling (no shared DTOs, routers, or state stores).

MESH, Datastar, and SSE-centric approaches

  • MESH’s principle “one component = one endpoint” plus SSE updates is seen as exploring the same attractor as LiveView, Blazor, and server components—server is source of truth, HTML fragments streamed to clients.
  • Some like the idea; others worry many endpoints will become a “mess” and that it combines SPA modeling overhead with tight backend coupling.
  • Datastar is highlighted as a related but different approach: one SSE connection per page, full-page morphing, CQRS style. It’s praised for multiplayer/streaming use cases.
  • Datastar’s “pro” license triggers debate: supporters see it as sustainable and optional; critics worry about partial proprietary lock‑in and inability to share improvements.

SPA frameworks, React, and “no-build”

  • React is viewed as having an enormous moat via its component ecosystem and vendor‑supplied React integrations, even if alternatives may be simpler.
  • Some call React/tooling a “monstrosity”; others argue the core library is small and its power justifies complexity.
  • A few report success leaving React for Lit/web components, or going “no-build”; others find no-build impractical once Tailwind‑style utilities or richer tooling are desired.