Live data from Hacker News

Htmx 2.0.4 Released

github.com

31–40 of 136 posts

Re: Htmx 2.0.4 Released

#31
post #20
post #17

Nothing new under the sun. This is just a rip off of intercooler js. Only without jQuery. Times moved on and someone copied the idea (exactly) but with the aid of modern JavaScript didn't need jQuery. I mean it's nice that it's a bit more modern but still.

Just in case this isn’t sarcasm, you may be interested to know they’re made by the same person. https://news.ycombinator.com/item?id=23330881

[deleted]

Re: Htmx 2.0.4 Released

#34

Earlier quoted context omitted.

Maybe because I'm "old" and use browsers the way they were used when I first started using the Internet, but I refresh often enough that I'd quickly lose patience with an "app" that broke because I used a very basic feature of the web.

If the site wasn't working it wouldn't break, it would download each page when you hit the back button. That would actually be a welcome result if I hit the refresh button wanting to make sure I was only looking at fresh data.

Any resource (ie page/URL) should function correctly with no regard to how that resource was loaded. That's the contract any server has with the client (browser), with no regard to what technology is being used to deliver the resource.

If a website or application basically has to do the 2024 equivalent of "don't hold it that way", it's the result of a broken development model.

Re: Htmx 2.0.4 Released

#35

> Calling htmx.ajax with no target or source now defaults to body (previously did nothing) This one jumped out to me as an interesting one for a patch release. Changing the default behavior feels like a breaking change, though hopefully there weren't sites expecting an ajax call to not do anything.

Actually this was just a stupid bug I introduced in 2.0.3 which was found soon after 2.0.3 shipped. I fixed a bug that allowed ajax api to target body and blow away your whole page in error if one of the selectors you pass in was not found. But It broke the default no source and target behavior but this is now fixed that 2.0.4 is shipped

Re: Htmx 2.0.4 Released

#36

Earlier quoted context omitted.

If the site wasn't working it wouldn't break, it would download each page when you hit the back button. That would actually be a welcome result if I hit the refresh button wanting to make sure I was only looking at fresh data.

Any resource (ie page/URL) should function correctly with no regard to how that resource was loaded. That's the contract any server has with the client (browser), with no regard to what technology is being used to deliver the resource. If a website or application basically has to do the 2024 equivalent of "don't hold it that way", it's the result of a broken development model.

The correct function comes down to what the browser APIs say is valid in navigation. Both loading cached data and making the request again are valid. In the case of soft page navigation (onpushstate/onreplacestate) it's very clear that both are valid, as SPAs aren't expected to cache nothing, nor are they expected to cache everything.

Re: Htmx 2.0.4 Released

#38

> Calling htmx.ajax with no target or source now defaults to body (previously did nothing) This one jumped out to me as an interesting one for a patch release. Changing the default behavior feels like a breaking change, though hopefully there weren't sites expecting an ajax call to not do anything.

> Changing the default behavior feels like a breaking change

I'm fine with breaking changes personally. An adherence to maintaining backward compatibility always is what leads to bloat and criticisms of "poor design" from HNers in the future.

Keep it slim, have one way to do things, and avoid the disaster that is js and python today.

Re: Htmx 2.0.4 Released

#39

> Calling htmx.ajax with no target or source now defaults to body (previously did nothing) This one jumped out to me as an interesting one for a patch release. Changing the default behavior feels like a breaking change, though hopefully there weren't sites expecting an ajax call to not do anything.

> Changing the default behavior feels like a breaking change I'm fine with breaking changes personally. An adherence to maintaining backward compatibility always is what leads to bloat and criticisms of "poor design" from HNers in the future. Keep it slim, have one way to do things, and avoid the disaster that is js and python today.

It's not that there are breaking changes, but that breaking changes were introduced in a patch release.
Post reply on HN