4 ms·

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

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

cschep 2y ago
why would you call it expecting it to do nothing?
- beanjuiceII 2y ago
  why is the wrong question, because it doesn't matter
  - cschep 2y ago
    of course it matters. not all workflows are worth preserving at all costs. there could be a really important trade off lurking, I'm not familiar, which is why I asked! https://xkcd.com/1172/ https://xkcd.com/1172/
tomjakubowski 2y ago
> though hopefully there weren't sites expecting an ajax call to not do anything. thatsthebeautyofit.com in shambles
recursivedoubts 2y ago
yeah, the htmx JavaScript API is not widely used, but I agree it's right on the edge of what's acceptable in a patch release
chrismorgan 2y ago
> though hopefully there weren't sites expecting an ajax call to not do anything It didn’t need to do nothing, it just needed to have no visible effect. I would be absolutely astonished if this affected no one. It’s very easy to imagine someone having written htmx.ajax("GET", "/some-tracker-that-returns-nothing-or-json-or-something") And now your body is clobbered, leaving either nothing behind or a raw JSON response or some such thing. Seriously. Should such a person have used fetch() instead? I dunno, probably; I don’t use htmx. This is an extremely breaking change.
- recursivedoubts 2y ago
  Yeah I tend to agree this should have been in a minor rather than a patch release. The reality is that I tend to regard the JavaScript api as an afterthought (the html attributes are the main api) and the existing behavior seemed like a nonsensical bug, but on reflection I wouldn’t have changed the html api like that and should treat the JavaScript api the same way.
- _heimdall 2y ago
  That's fair, I guess someone could be doing that. Not quite sure why you would though, if you're already in JS and aren't updating the DOM, fetch() would make more sense. Either way it sounds like this was a fix to a bug introduced in the last patch so the semver makes more sense here.
latent22 2y ago
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
- ahoka 2y ago
  This is why I think semver is impossible to do in practice.
  - deleted 2y ago
    [deleted]
  - teruakohatu 2y ago
    > This is why I think semver is impossible to do in practice. The semver docs explicitly address this scenario. If a change in minor update breaks compatibility release a new minor update to revert the change.
    - foldr 2y ago
      It’s correct practice, but bad luck for anyone who ends up depending on the buggy behavior in 2.0.3. Their code will break when they upgrade to (say) 2.0.7.
      - joshmanders 2y ago
        This would make sense if 2.0.3 was released long enough ago for people to start using and relying on a bug, but it was released less than 2 months ago...
        latent22 2y ago
        The bug in 2.0.3 just breaks one default use case and where you pass in no source or target to the api so anyone using this feature their app broke on upgrade to 2.0.3 and they had to set a source explicitly or revert the version. 2.0.4 just fixes this with no downside unless you like seeing console errors
hipadev23 2y ago
> 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.
- Spivak 2y ago
  It's not that there are breaking changes, but that breaking changes were introduced in a patch release.
- intalentive 2y ago
  How is Python a disaster?
  - deleted 2y ago
    [deleted]
- izietto 2y ago
  I'm not fine with breaking changes in a patch bump, otherwise it means versioning is useless
- PhilippGille 2y ago
  In addition to what the siblings say, in case parent isn't aware of semantic versioning: https://semver.org/ https://semver.org/
- sethammons 2y ago
  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.

cschep 2y ago

why would you call it expecting it to do nothing?

beanjuiceII 2y ago
why is the wrong question, because it doesn't matter
- cschep 2y ago
  of course it matters. not all workflows are worth preserving at all costs. there could be a really important trade off lurking, I'm not familiar, which is why I asked! https://xkcd.com/1172/ https://xkcd.com/1172/

tomjakubowski 2y ago

> though hopefully there weren't sites expecting an ajax call to not do anything. thatsthebeautyofit.com in shambles

recursivedoubts 2y ago

yeah, the htmx JavaScript API is not widely used, but I agree it's right on the edge of what's acceptable in a patch release

chrismorgan 2y ago

> though hopefully there weren't sites expecting an ajax call to not do anything It didn’t need to do nothing, it just needed to have no visible effect. I would be absolutely astonished if this affected no one. It’s very easy to imagine someone having written htmx.ajax("GET", "/some-tracker-that-returns-nothing-or-json-or-something") And now your body is clobbered, leaving either nothing behind or a raw JSON response or some such thing. Seriously. Should such a person have used fetch() instead? I dunno, probably; I don’t use htmx. This is an extremely breaking change.

recursivedoubts 2y ago
Yeah I tend to agree this should have been in a minor rather than a patch release. The reality is that I tend to regard the JavaScript api as an afterthought (the html attributes are the main api) and the existing behavior seemed like a nonsensical bug, but on reflection I wouldn’t have changed the html api like that and should treat the JavaScript api the same way.
_heimdall 2y ago
That's fair, I guess someone could be doing that. Not quite sure why you would though, if you're already in JS and aren't updating the DOM, fetch() would make more sense. Either way it sounds like this was a fix to a bug introduced in the last patch so the semver makes more sense here.

latent22 2y ago

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

ahoka 2y ago
This is why I think semver is impossible to do in practice.
- deleted 2y ago
  [deleted]
- teruakohatu 2y ago
  > This is why I think semver is impossible to do in practice. The semver docs explicitly address this scenario. If a change in minor update breaks compatibility release a new minor update to revert the change.
  - foldr 2y ago
    It’s correct practice, but bad luck for anyone who ends up depending on the buggy behavior in 2.0.3. Their code will break when they upgrade to (say) 2.0.7.
    - joshmanders 2y ago
      This would make sense if 2.0.3 was released long enough ago for people to start using and relying on a bug, but it was released less than 2 months ago...
      - latent22 2y ago
        The bug in 2.0.3 just breaks one default use case and where you pass in no source or target to the api so anyone using this feature their app broke on upgrade to 2.0.3 and they had to set a source explicitly or revert the version. 2.0.4 just fixes this with no downside unless you like seeing console errors

hipadev23 2y ago

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

Spivak 2y ago
It's not that there are breaking changes, but that breaking changes were introduced in a patch release.
intalentive 2y ago
How is Python a disaster?
- deleted 2y ago
  [deleted]
izietto 2y ago
I'm not fine with breaking changes in a patch bump, otherwise it means versioning is useless
PhilippGille 2y ago
In addition to what the siblings say, in case parent isn't aware of semantic versioning: https://semver.org/ https://semver.org/
sethammons 2y ago
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.