5 ms·

I'm personally betting on HTMX https://htmx.org/ https://htmx.org/

klabb3 3y ago
I like htmx too for its simplicity but it’s actually antithetical to another key HN trope: responsiveness. Round-tripping to the server is much slower than client-side JS. It should be terrible for fast keyboard navigation, for instance. You might not notice on a server on localhost or on fast internet (which is very user-hostile to assume). That said, this is me speaking about htmx based on what I know about it. They may have some tricks up their sleeves these days to account for those issues. But those tricks would need JS.
- catskull 3y ago
  If I had to architect a front end today, I'd start with HTMX. Very curious how far a HTMX+Deno stack could get you.
- infogulch 3y ago
  That's a common argument, but how often are you navigating around in a web app and you don't need data from the server? IME you do like 80+% of the time so "responsiveness" is false anyway, and when you don't you could get pretty far with basic http caching. And assuming high bandwidth is just as bad if not worse than assuming high latency, where typical web app dev platforms perform abysmially not to mention multiple extra round trips and device speed/power. And you could get into the hydration and SSR mess, but then you could just render on the server in the first place and simplify the entire system, reduce your LOC by 5x, opt out of the entire js ecosystem shitshow (or keep it for select high interactivity components, I won't judge), and eliminate an entire api that doesn't need to exist. If you are building the next google maps, maybe htmx isn't for you. But if you're building another LOB app with mainly forms and data views, or an ecommerce site, or another CMS, there's a 99% chance that htmx is plenty. Personally, I'm betting that you can make a whole interactive site on top of Go's html/template library + htmx, using a pattern I'm developing here: https://github.com/infogulch/caddy-xtemplate https://github.com/infogulch/caddy-xtemplate I'm currently co-developing this with an rss reader webapp to work out the kinks.
  - guggle 3y ago
    This… <ul> {{range .Query `SELECT id,name FROM contacts`}} <li><a href="/contact/{{.id}}">{{.name}}</a></li> {{end}} </ul> …reminds me of what we used to do in php3 days. That was convenient, performant and… unmaintainable. Am I missing something ?
    - infogulch 3y ago
      Who knows if it will be maintainable or not. Can you articulate why the php3 projects became unmaintainable?
      - guggle 3y ago
        I almost have ptsd from these dark days, I won’t go into details ;-) but there’s plenty of literature about separation of concerns. Having the templates doing the data access takes me back 20 years ago, but I can see why this idea comes back in a web component era.
        infogulch 3y ago
        Check out: https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ The proposal is that Locality of Behavior > Separation of Concerns. Maybe its true! We'll see. :)
        guggle 3y ago
        I actually like htmx (I find Unpoly superior so that’s what I use, but it’s the same general idea) and the example given makes sense, but one should not extend locality of behaviour to the point of sprinkling SQL in templates. I don’t think that’s what the htmx folks had in mind in this essay either, their canonical example being the html/css/js trio. But hey… there’s no better experience than first-hand experience, you will find soon enough if it works for you.
        3y ago
guggle 3y ago
I also like htmx. But one day someone pointed me to unpoly, which I find better. So I’ll spread the word here: https://unpoly.com/ https://unpoly.com/

I like htmx too for its simplicity but it’s actually antithetical to another key HN trope: responsiveness. Round-tripping to the server is much slower than client-side JS. It should be terrible for fast keyboard navigation, for instance. You might not notice on a server on localhost or on fast internet (which is very user-hostile to assume). That said, this is me speaking about htmx based on what I know about it. They may have some tricks up their sleeves these days to account for those issues. But those tricks would need JS.

catskull 3y ago
If I had to architect a front end today, I'd start with HTMX. Very curious how far a HTMX+Deno stack could get you.
infogulch 3y ago
That's a common argument, but how often are you navigating around in a web app and you don't need data from the server? IME you do like 80+% of the time so "responsiveness" is false anyway, and when you don't you could get pretty far with basic http caching. And assuming high bandwidth is just as bad if not worse than assuming high latency, where typical web app dev platforms perform abysmially not to mention multiple extra round trips and device speed/power. And you could get into the hydration and SSR mess, but then you could just render on the server in the first place and simplify the entire system, reduce your LOC by 5x, opt out of the entire js ecosystem shitshow (or keep it for select high interactivity components, I won't judge), and eliminate an entire api that doesn't need to exist. If you are building the next google maps, maybe htmx isn't for you. But if you're building another LOB app with mainly forms and data views, or an ecommerce site, or another CMS, there's a 99% chance that htmx is plenty. Personally, I'm betting that you can make a whole interactive site on top of Go's html/template library + htmx, using a pattern I'm developing here: https://github.com/infogulch/caddy-xtemplate https://github.com/infogulch/caddy-xtemplate I'm currently co-developing this with an rss reader webapp to work out the kinks.
- guggle 3y ago
  This… <ul> {{range .Query `SELECT id,name FROM contacts`}} <li><a href="/contact/{{.id}}">{{.name}}</a></li> {{end}} </ul> …reminds me of what we used to do in php3 days. That was convenient, performant and… unmaintainable. Am I missing something ?
  - infogulch 3y ago
    Who knows if it will be maintainable or not. Can you articulate why the php3 projects became unmaintainable?
    - guggle 3y ago
      I almost have ptsd from these dark days, I won’t go into details ;-) but there’s plenty of literature about separation of concerns. Having the templates doing the data access takes me back 20 years ago, but I can see why this idea comes back in a web component era.
      - infogulch 3y ago
        Check out: https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ The proposal is that Locality of Behavior > Separation of Concerns. Maybe its true! We'll see. :)
        guggle 3y ago
        I actually like htmx (I find Unpoly superior so that’s what I use, but it’s the same general idea) and the example given makes sense, but one should not extend locality of behaviour to the point of sprinkling SQL in templates. I don’t think that’s what the htmx folks had in mind in this essay either, their canonical example being the html/css/js trio. But hey… there’s no better experience than first-hand experience, you will find soon enough if it works for you.
        3y ago

guggle 3y ago

I also like htmx. But one day someone pointed me to unpoly, which I find better. So I’ll spread the word here: https://unpoly.com/ https://unpoly.com/