Rendered at 03:50:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
n4pw01f 1 hours ago [-]
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
wren6991 14 hours ago [-]
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?
yawaramin 13 hours ago [-]
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.
Rohansi 1 hours ago [-]
Supply chain attacks are not a JavaScript or npm exclusive risk. If you pull in any dependencies you have a supply chain risk.
deadbabe 4 hours ago [-]
Who is worrying? If JavaScript is on the front end the supply chain attacks are really not your problem.
traverseda 2 hours ago [-]
What? It handles your password fields.
deadbabe 2 hours ago [-]
Just do SSO.
dmoreno 13 hours ago [-]
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.
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.
muvlon 6 hours ago [-]
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.
draw_down 3 hours ago [-]
[dead]
inigyou 6 hours ago [-]
the network is faster than so much shitty client-side JS these days.
grebc 5 hours ago [-]
When you say these days, I’d argue since mid/late 2000’s for internet with a cable vs. radio waves.
Radio waves caught up in developed countries with 4G roll outs in my opinion(is that mid 2010’s?).
Large client side JS has been garbage for most things since it’s inception.
sparse-Matrix 16 hours ago [-]
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
oaxacaoaxaca 3 hours ago [-]
>Or you can just use htmx?
great idea thank you for the recommendation
pixel_popping 12 hours ago [-]
The Github link at the bottom contains a `,` char, might want to fix it.
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.
ameliaquining 4 hours ago [-]
Change the period from "last 3 months" to "all".
sodapopcan 3 hours ago [-]
I did. Still 3.
But then I'd ask my original question that I didn't post: how the hell does this repo have 422 contributors?
GitHub's contributor graph is based on authorship of Git commits, and doesn't track whether a given GitHub account ever actually interacted with a given GitHub repo. This Git repo is a fork of the htmx Git repo (though it's not marked as such on GitHub), so all contributors to htmx as of the fork date are also contributors here.
sodapopcan 3 hours ago [-]
Ahhh makes sense if it's a fork. Odd that it's not marked as one. Sort of an odd thing that you can get associated with a repo you don't even know exists.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
People throw salt at my stack but it’s fast, and straightforward to manage attack surface
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.
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/
Htmx is a replacement for network interactions, not every bit of UI interactivity.
Radio waves caught up in developed countries with 4G roll outs in my opinion(is that mid 2010’s?).
Large client side JS has been garbage for most things since it’s inception.
cheers
great idea thank you for the recommendation
https://github.com/bigguysoftware/htmxxx
But then I'd ask my original question that I didn't post: how the hell does this repo have 422 contributors?
GitHub's contributor graph is based on authorship of Git commits, and doesn't track whether a given GitHub account ever actually interacted with a given GitHub repo. This Git repo is a fork of the htmx Git repo (though it's not marked as such on GitHub), so all contributors to htmx as of the fork date are also contributors here.
Thanks for engaging me and my confusion.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.