Live data from Hacker News

Let's make the worst Htmx

zserge.com

11–20 of 85 posts

Re: Let's make the worst Htmx

#11
post #3

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?

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.

Re: Let's make the worst Htmx

#12
post #3

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?

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.

Re: Let's make the worst Htmx

#13
post #10
post #3

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 network is faster than so much shitty client-side JS these days.

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.

Re: Let's make the worst Htmx

#15
post #3

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?

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 tag on the page, and you're done.

Who is worrying? If JavaScript is on the front end the supply chain attacks are really not your problem.

Re: Let's make the worst Htmx

#16
post #9

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.

Change the period from "last 3 months" to "all".

Re: Let's make the worst Htmx

#17

Earlier quoted context omitted.

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.

Change the period from "last 3 months" to "all".

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?

Re: Let's make the worst Htmx

#19

Earlier quoted context omitted.

Change the period from "last 3 months" to "all".

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?

You're seeing only three contributors at https://github.com/bigguysoftware/htmxxx/graphs/contributors...? I have no explanation for that, it doesn't match what I'm seeing.

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.

Re: Let's make the worst Htmx

#20
post #12
post #3

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?

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.

[dead]
Post reply on HN