Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • We already have the naughtiest htmx

    https://github.com/bigguysoftware/htmxxx

  • Is there something known wrong with github rn (aside from everything, I guess)? It claims there are 422 contributors but when you click in there are only three.
  • >Or you can just use htmx?

    great idea thank you for the recommendation

  • The Github link at the bottom contains a `,` char, might want to fix it.
  • Huh, so every interactive event has a network request in the loop, with perceptible latency? And you still end up obligating client-side JS for the plumbing? I'd been meaning to look into HTMX but based on the content of this post it seems like a worst-of-all-worlds technical solution. Is it at least pleasant to work with?
  • The problem with HTMX is not network traffic but needing to use hyperscript for anything advanced.
    by yyyk
  • Datastar has a lean and mean signals implementation that handles all the front-end reactive stuff - so you don’t have to go to the server for interactivity.
  • the network is faster than so much shitty client-side JS these days.
  • It's for building extremely backend-brained frontend stuff, like a sort of anti-NextJS. Also like NextJS, this sort of domain-bending has some unfortunate operational consequences.
  • It’s only has a network request in the loop if the interaction requires a network request.

    Htmx is a replacement for network interactions, not every bit of UI interactivity.

  • That's why many times HTMX is used together with alpinejs [1].

    For areas that need server side, if you use say react and return a JSON you have to deserialize and do the render. It might be much more efficient to just replace.

    Having said that I use HTMX /alpinejs for small projects, and still trust react for bigger more interactive ones.

    [1] https://alpinejs.dev/

  • No, every interactive event doesn't need to have a network request in the loop. And you only need a tiny bit of client-side JS for a most of the plumbing.

    It is quite pleasant to work with, because you don't have to worry about a constant stream of vulnerabilities or supply chain attacks. You just vendornthe script in your repo, add it as a <script> tag on the page, and you're done.

  • Bravo! I never would have thought this would be so simple. As a direct consequence of this exercise: I now know something about what, precisely, htmx does.

    cheers

  • I wrote a really tiny web app using Django and HTMX to do a find-as-you-type telephone directory, and it worked really well.

    I wish I did more front-end stuff so I could play with it more.

  • Have a pretty large application running HTMX + WebComponents + Hono + Cloud Functions to serve up frontends, happy with it for about 2 years now

    People throw salt at my stack but it’s fast, and straightforward to manage attack surface

  • I'm using Hono + Tanstack Router as a Next.js replacement. Best software related decision I ever made, it feels like I stopped fighting with the stack.
  • Part of the beauty of htmx is how simple it is to recreate. As this post shows, the fundamental concepts of htmx really are straightforward.

    Of course, there are all sorts of edge cases and minor features to add to make it complete.

  • Nice, I really like this series, this made me really understand those web frameworks much better as before. Thank you.
  • They didnt mention the real side benefit of HTMX, and thats the twitter account memes.
  • I really want to try htmx but it specifically prohibits my most common usecases:

    1) I want to take a JSON response, create HTML from it, and replace the target element with the generated HTML.

    2) Similar to the above, take a JSON response, perform some action, and do nothing to the source element.

    Is there a plugin to add this? I want to move away from jQuery, and having a small framework to wire up hooks would be useful.

  • Why are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend, which can then return html to your frontend

    (1) the exception is I think in one place concerned a flow for uploading images, where client side requests a signed url, uploads to that url, then registers completion. Getting the signed url back is JSON meant for the uploader

  • Sounds like you are going through similar struggles as a few backend developers I had trying out htmx. Years of muscle memory with returning JSON and letting the frontend (javascript/jquery) to handle the html.

    They were making a big deal with this change. In the end the change is rather minimal. The outcome is reduced javascript code and more server side html templates. Pretty much most of the code is now handled on the server side. Just organise the html templates!

    Pseudo example

    Instead of :-

    <code>

    // returning as Json

    [Get]

    Response GetUser(int id) {

       var user = getUser(id);
    
       return ToJson(user);
    
    }

    </code>

    You are just doing :-

    <code>

    // returning as HTML

    [Get]

    Response GetUser(int id) {

       var user = getUser(id);
    
       return View("som-user-template", user);
    
    }

    </code>

    I don't know what 'hooks' you need, but whatever they are doing you can move them over to returning/updating section of html on the screen with htmx.

  • I highly recommend everyone to give htmx or datastar a try, especially if your main experience is react or nextjs.

    We recently rewrote a half-million LOC codebase from react to datastar, with a detour through htmx first, and the results are staggering.

    First page load is 20KB down from a 750KB js bundle. 1 network request vs 40+. Total load time 0.1 seconds down from 2 seconds of spinners. Page refresh is so fast, the browser doesn’t even flash - there’s no massive js bundle to parse, so it can start rendering instantly.

    But the most staggering result is that in-document navigation over SSE achieves up to 5000:1 compression ratio for network requests within the Brotli compression window. Yes, 5000:1, you read that right. When changing server state we rerender the entire page, like an immediate-mode game engine, and push it to the client over an SSE “fat morph”, in about 100 bytes.

    It’s so fast and so much more stable, our users are literally having fun. With a medical device.

    And this ends up ~50% less code to maintain for a VASTLY superior UIX.

    You are really missing out if you don’t learn how this works. It can give you a significant competitive edge if you care enough to try.

    Edit: Big BIG thanks to bigskysoftware and the datastar team for making the web a sane place again. You really deserve all the props.

  • If anyone is looking for a TypeScript framework that embraces hypermedia the same way that HTMX does (and is very easy to use with HTMX), check out Hyperspan: https://www.hyperspan.dev

    Disclaimer: I built Hyperspan :)

  • How do you debug SSE messages since they don’t show up in chrome dev tools with Datastar?
  • I’m getting about 800:1 compression with Brotli. I wonder if need to tune anything? Although tbh I have no performance issues at all.

    It took me a minute to change my mindset to Datastar’s way of doing things. But it’s been amazing. Firstly to keep 99% of the state and logic on the back end is just so nice - no more having to deal with two sources of state at the same time (front end and back end). Secondly the ability to regenerate the entire view from scratch anytime something changes and then have Datastar efficiently morph just the changes is just such a simple mental model. Every fiber in me was like “no way that can work, the cpu, bandwidth, latency etc” - but it is buttery smooth.

  • Since you tried both, what made you choose datastar over htmx?
  • My experience was similar. I'd wound down a startup and as a solo developer could no longer afford to do react + a backend. So I tried HTMX, then turbo (which introduced me to morph and push based re-fetch). Finally moved to datastar because I could drop alpine and it has best in class morph, signals and SSE support. Immediate mode over the network is amazing DX.

    Makes multiplayer out of the box over large datasets trivial. See these demos if you don't believe me [1][2] (open them in multiple tabs and have fun)

    [1] https://checkboxes.andersmurphy.com

    [2] https://example.andersmurphy.com