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

Htmx 2.0.4 Released

github.com

Post reply on HN
Print view View original

81–90 of 136 posts

Re: Htmx 2.0.4 Released

#81

Post by sublinear »

xupybd wrote: post #45
sublinear wrote: post #44

Earlier quoted context omitted.

Sick and tired of any server-side rendering of web pages. If you don't have to deal with incident response you can be quiet. It doesn't scale and it complicates meeting any client requirements. Get this trash outta here. For real.

I worked with server side rendering for close to a decade. It's very reliable.

It's not reliable when your precious servers go down because they're far more complicated than one that simply runs apache or nginx and needs constant patching.

(fully aware of the origin of the name "apache")

Re: Htmx 2.0.4 Released

#83

Post by bjackman »

ianpurton wrote: post #62

Do some people have examples of interactivity they were able to replace with Htmx? For me, I've been able to get turbo style links with the boost to get nice page transitions. I can also see how I could use the class-tools extension to enable buttons to open dialogs etc. I'm curious to see when people say they needed an SPA for interactivity, what interactive features Htmx can already do and when do we need to break…

I recently tried out htmx for rendering a web clone of the terminal UI for https://github.com/bjackman/limmat

It's a simple usecase but nonetheless I was blown away by how trivial HTMX made it! Very cool.

Re: Htmx 2.0.4 Released

#84

Post by mirekrusin »

ahoka wrote: post #68
latent22 wrote: post #35

Earlier quoted context omitted.

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

This is why I think semver is impossible to do in practice.

Agree, behavior vs misbehavior (aka feature vs bug) is user's decision (at call site), not author's decision (at implementation side).

Semver is just _indicative_ attempt at describing changes.

If this wasn't true, we wouldn't have lockfiles.

Ie. semver is just approximate attempt at change description that aids/helps development/maintenance but should never be fully trusted.

The only way it could fully work in automated fashion is if the whole program would be written in some formal proof language – then dependency upgrades could be considered as breaking or non breaking. But again, easier and more precise from end user position, not author's position because breaking change in one project can always be non breaking in other if that part is not used/used in more relaxed manner.

Re: Htmx 2.0.4 Released

#85

Post by withinboredom »

benatkin wrote: post #36
bdcravens wrote: post #34

Earlier quoted context omitted.

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.

If I’m currently filtering some search data and hit refresh (or the browser tab went to sleep and wakes up, or restored after a reboot) I expect it to be in the same place without having to search and filter again.

Re: Htmx 2.0.4 Released

#86

Post by xupybd »

sublinear wrote: post #76
spirodonfl wrote: post #59

Earlier quoted context omitted.

Imagine being this delusional

Go ahead and tell me how cacheable your SSR page is. If it was a static file? Oh yeah it never changes! How convenient! Maybe that's the point! People who promote SSR are simply trying to rope frontend devs into their P2 or P1 incident responses and use them as whipping boys. This shit has to stop. If you don't suspect your web devs are doing all kinds of cache-busting dog shit on your backend ruining your performanc…

Why can't you use HTMX with a static back end?

It's a front end library?

Re: Htmx 2.0.4 Released

#87

Post by Babawomba »

Tried Htmx a while back... mixed feelings. Love how easy it is to get basic interactivity—honestly, adding a filter or an upvote button in a couple of lines of HTML feels like magic. No messing with a frontend framework, no bundlers - just works.

But I hit walls when I needed more complex stuff. Like, if I want to keep state on the client (e.g., a live calculator or sliders updating a table), Htmx feels clunky. Sending a request to the server every time a user adjusts a slider—yeah, no. React or Svelte is a better fit there. And if you're already using those tools. Htmx starts to feel redundant. Why add more when you've got everything in one place?

Also, not sure about the recent patch release - Changing default behavior in a minor update? Feels risky, even if it's "fixing a bug." Imagine waking up to find your body tag wiped because you updated without reading the changelog, yikes. Makes me think twice about trusting it in production.

Butfor MPAs or projects that lean heavily on server-side rendering, it’s a game-changer. You’re not rebuilding the wheel, just enhancing it. Htmx has a sweet spot—it’s just not always the right tool for every job. Depends what you're building, I guess...

Re: Htmx 2.0.4 Released

#88

Post by sethammons »

hipadev23 wrote: post #38
_heimdall wrote: post #2

> 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.

Backwards compatibility is a mainstay in Go and I don't experience bloat, and, I believe, such goals are a hallmark of good api design. Source: over the last 20 years, built several and used many large code bases that have used for years and years that had different teams and individuals regularly committing into them.

Re: Htmx 2.0.4 Released

#89

Post by adzm »

Babawomba wrote: post #87

Tried Htmx a while back... mixed feelings. Love how easy it is to get basic interactivity—honestly, adding a filter or an upvote button in a couple of lines of HTML feels like magic. No messing with a frontend framework, no bundlers - just works. But I hit walls when I needed more complex stuff. Like, if I want to keep state on the client (e.g., a live calculator or sliders updating a table), Htmx feels clunky. Sendi…

Same here. I honestly love react, it just seems to make sense, integrates well with legacy stuff, great tooling, really nothing else comes close
Post reply on HN