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

htmx 2.0.0-beta1

v2-0v2-0.htmx.org

Post reply on HN
Print view View original

71–80 of 88 posts

Re: htmx 2.0.0-beta1

#71

Post by hirvi74 »

lukevp wrote: post #56
leptons wrote: post #33

Earlier quoted context omitted.

Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260

SPAs require implementing safety checks on both sides in 2 different languages. Many junior devs believe the client code is trustworthy and put important validation only in the client. I’ve worked with many codebases like this. If there’s only one place to specify validation, it should always be the server. So server side frameworks have this built in to their model and thus are less susceptible to this whole class o…

> SPAs require implementing safety checks on both sides in 2 different languages.

This isn't exclusive to SPAs. For example, I am a .Net dev, and I have both front-end and back-end validation in most of my applications without ever using any SPA frameworks.

If I am in a pinch for time, I sometimes just drop front-end validation completely, and let the server handle the validation and then have the front-end handle the server validation responses accordingly.

Re: htmx 2.0.0-beta1

#72

Post by hirvi74 »

blopker wrote: post #26
wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

I'm using HTMX with Django for totem.org[0]. My over all experience is good. I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependen…

> The main downside I have with it though, is I just can't seem to remember how to use it

I've noticed the more I use HTMX, the more I tend to end up needing to use the JS API too.

For example, if I have an HTML table with inline editing, and I need there to be validation on what people are entering. So, I have HTMX firing when people save their changes via a button, then I need to use the JS API for conditional logic e.g., if valid, then update table. If invalid, then display some kind of message or whatever.

HTMX has been working great for my needs, but the more I tend to get into the weeds of the JS API, I cannot help but sometimes question whether I am truly gaining that much more over using plain AJAX requests. However, HTMX is definitely more concise, so that's a nice benefit I suppose over a unmaintainable slew of AJAX requests.

Re: htmx 2.0.0-beta1

#73

Post by paulddraper »

chuckadams wrote: post #45
paulddraper wrote: post #5

Earlier quoted context omitted.

Query params. DELETE cannot have request body, just like GET cannot have a request body. (Well, it's a syntactically valid HTTP message, but there's no semantic meaning to the body.)

DELETE and GET can have bodies, the spec is just vague about it. Elasticsearch commonly uses request bodies for GET, treating it identically to POST. It's not always regarded as a good idea, but it does work.

That's why I said:

> (Well, it's a syntactically valid HTTP message, but there's no semantic meaning to the body.)

To quote RFC 9110:

> Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

For this reason, Elasticsearch also accepts queries as POST.

Re: htmx 2.0.0-beta1

#74

Post by ledgerdev »

tomcam wrote: post #38
ledgerdev wrote: post #22

Earlier quoted context omitted.

I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setti…

Super balanced & informative writeup, thank you. Can you tell me what you mean by tab sleep restoration?

Last year chrome started discarding background tabs to save memory, probably should have said discard rather then sleep it's been a while since I worked on that. Our user base keeps tabs in background often in mobile devices and we saw some reports of it. https://arstechnica.com/gadgets/2023/02/chrome-110-will-auto...

When you do an htmx navigation to a new page, a discarded tab will "restore" only the last htmx fragment loaded, not the entire html page with style tags. Fix is to use unique url on push that isn't in local cache which forces a server reload on tab wake from discard.

Re: htmx 2.0.0-beta1

#75

Post by ledgerdev »

rasso wrote: post #69
ledgerdev wrote: post #22

Earlier quoted context omitted.

I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setti…

I‘d also like to know what you mean by tab sleep restoration.

answered here. https://news.ycombinator.com/item?id=39737557

Re: htmx 2.0.0-beta1

#76

Post by hirvi74 »

dinkumthinkum wrote: post #66
stavros wrote: post #12

Earlier quoted context omitted.

I don't know if HTMX is an alternative to React/Vue/etc, it always struck me as an alternative to a purely HTML site, which I think 95% of web apps should be. I don't know what we get from avoiding full page loads that we don't then lose when we make sites janky and taking ages to load.

Well there has been this push forever to eliminate desktop apps in favor of just web apps. Now, imagine we do this crazy thing that most businesses are convinced they need to do and we do what you’re saying, which is make all web apps do page reloads. All of sudden (maybe not so suddenly) computing in 2026 is much more frustrating than it was in 1996 (86?).

I've mainly been a full stack dev for most of my career, though I do have a some experience in low-level domains. Lately, I have been mulling over if I want to jump into different field of development.

I know Rust is gaining traction, and I have always found languages like assembly, C/C++ to be more enjoyable than the higher level languages. So, I might try and take a stab at Rust and see where it can take me. I'm just so fatigued from all the web dev stuff. The whole field feels too scatter-brained to me.

Instead of trying to solve useful problems, I feel like much of web dev's frameworks are just focused solving an already solved problem with slightly differing and dogmatic opinions.

Re: htmx 2.0.0-beta1

#77

Post by [deleted] »

hirvi74 wrote: post #72
blopker wrote: post #26

Earlier quoted context omitted.

I'm using HTMX with Django for totem.org[0]. My over all experience is good. I'd say the main thing I like is testing. With a JS framework I have to have tests spread over both JS and Python, with HTMX I can mostly just focus on Python tests and assume the HTMX is going to work correctly. There's a good, stable testing story for Django, so I know the tests I write won't have to be rewritten all the time when dependen…

> The main downside I have with it though, is I just can't seem to remember how to use it I've noticed the more I use HTMX, the more I tend to end up needing to use the JS API too. For example, if I have an HTML table with inline editing, and I need there to be validation on what people are entering. So, I have HTMX firing when people save their changes via a button, then I need to use the JS API for conditional logi…

[deleted]

Re: htmx 2.0.0-beta1

#78

Post by dinkumthinkum »

hirvi74 wrote: post #76
dinkumthinkum wrote: post #66

Earlier quoted context omitted.

Well there has been this push forever to eliminate desktop apps in favor of just web apps. Now, imagine we do this crazy thing that most businesses are convinced they need to do and we do what you’re saying, which is make all web apps do page reloads. All of sudden (maybe not so suddenly) computing in 2026 is much more frustrating than it was in 1996 (86?).

I've mainly been a full stack dev for most of my career, though I do have a some experience in low-level domains. Lately, I have been mulling over if I want to jump into different field of development. I know Rust is gaining traction, and I have always found languages like assembly, C/C++ to be more enjoyable than the higher level languages. So, I might try and take a stab at Rust and see where it can take me. I'm ju…

Well that is exactly right. These web frameworks, while they have their uses and have has some improvement on software engineering of web apps and have enabled sone benefits for users … largely the churn of these web frameworks with all these cute names are just reformulating the same technology over and over just with different opinions and aesthetics. People act like “technology changes all the time” but that’s not really what’s happening. We are “rediscovering” things so much in Web dev because we are still fundamentally doing, for the most part, what CGI programs did 30 years ago, pushing text back and forth with http verbs and return codes. Then, we make a huge deal when we get a web app to do something a desktop app could do 10-30+ years before.

Re: htmx 2.0.0-beta1

#79

Post by shouldcode »

wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

You might want to check out https://hypermedia.gallery

Disclosure: I built it (without HTMX).

Re: htmx 2.0.0-beta1

#80

Post by infogulch »

I'm just glad I was able to submit my patch before 2.0 released: "Add config option to ignore nested oob-swaps instead of processing them (#1235)"

Setting this config makes it easier to use 'template fragments' with oob-swaps, since you can set the hx-swap-oob=true attribute on the element and reuse it to render a whole page or just a fragment of the template. Very nice to use with Go template blocks for example.

https://htmx.org/essays/template-fragments/

Post reply on HN