Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's make the worst Htmx

zserge.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Let's make the worst Htmx

#21

Post by sodapopcan »

ameliaquining wrote: post #19
sodapopcan wrote: post #17

Earlier quoted context omitted.

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 G…

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.

Thanks for engaging me and my confusion.

Re: Let's make the worst Htmx

#22

Post by traverseda »

deadbabe wrote: post #15
yawaramin wrote: post #6

Earlier quoted context omitted.

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.

What? It handles your password fields.

Re: Let's make the worst Htmx

#24

Post by n4pw01f »

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

Re: Let's make the worst Htmx

#25

Post by Rohansi »

yawaramin wrote: post #6
wren6991 wrote: 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.

Supply chain attacks are not a JavaScript or npm exclusive risk. If you pull in any dependencies you have a supply chain risk.

Re: Let's make the worst Htmx

#26

Post by robertoandred »

yawaramin wrote: post #6
wren6991 wrote: 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.

How is htmx invulnerable to vulnerabilities and attacks?

Re: Let's make the worst Htmx

#27

Post by [deleted] »

grebc wrote: post #13
inigyou wrote: post #10

Earlier quoted context omitted.

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.

[deleted]

Re: Let's make the worst Htmx

#28

Post by yyyk »

wren6991 wrote: 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 problem with HTMX is not network traffic but needing to use hyperscript for anything advanced.

Re: Let's make the worst Htmx

#29

Post by esperent »

n4pw01f wrote: post #24

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.
Post reply on HN