4 ms·

> This means accepting and documenting the quirks of the current implementation. If you're planning no new features as a feature, why not first remove those qu

> This means accepting and documenting the quirks of the current implementation. If you're planning no new features as a feature, why not first remove those quirks? Why keep them around? > People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed Truly, there exists a middle path: you can make breaking changes and user still can upgrade at their own pace (using future flags, codemods, etc.), you don't have to refuse progress - it's just a "more" work for the creator.

recursivedoubts 2y ago
That's true but we're doing it this way instead.
- andybak 2y ago
  Are you tired, distracted or answering on the go? A couple of your replies in this thread have seemed a little half-hearted. Sometimes it's better not to reply at all - or to reply at a later date.
  - recursivedoubts 2y ago
    I do have a pretty bad knee injury I'm dealing with. Maybe that's distracting me.
yawaramin 2y ago
> why not first remove those quirks? Why keep them around? To preserve backward compatibility. > there exists a middle path:...it's just a "more" work for the creator. I think you just answered your own question. Unpaid maintainers of a free open source software project are trying to reduce their maintenance burden. This is normal and actually a good thing if it means they will be able to stick around for the longer term. Consider that you are asking a guy who has been maintaining open source projects for more than a decade, with some degree of success. So his strategy is probably working for him.
- jakubmazanec 2y ago
  > To preserve backward compatibility. What backwards compatibility? There is already migration guide from v1 to v2.
  - yawaramin 2y ago
    And the guide is mostly 'Everything is pretty much the same, just a couple of minor tweaks and default changes'.
    - jakubmazanec 2y ago
      Then why v2? If there are no breaking changes, why increase the major version? And if there are breaking changes, why not fix the quirks? Seriously, decisions like this show me the maintainers are just blinded by their lack of front-end skills, whining about JavaScript and striving for questionable "purity" - it's the same with the codebase (as mentioned by other commenters): one large unmaintainable file, because build step is too complex or whatever nonsense. Anyway, excellent article and discussion that showed me I can forget about HTMX :D
      - yawaramin 2y ago
        Did you read the v2 release notes? The big thing they got rid of was IE11 support. Everything else was relatively minor. Having a bunch of breaking changes in v2 would have made the upgrade much more difficult for users, and a big part of their philosophy is making upgrades easy. Of course, no one is forcing you to use htmx. Please use whatever you like.

recursivedoubts 2y ago

That's true but we're doing it this way instead.

andybak 2y ago
Are you tired, distracted or answering on the go? A couple of your replies in this thread have seemed a little half-hearted. Sometimes it's better not to reply at all - or to reply at a later date.
- recursivedoubts 2y ago
  I do have a pretty bad knee injury I'm dealing with. Maybe that's distracting me.

yawaramin 2y ago

> why not first remove those quirks? Why keep them around? To preserve backward compatibility. > there exists a middle path:...it's just a "more" work for the creator. I think you just answered your own question. Unpaid maintainers of a free open source software project are trying to reduce their maintenance burden. This is normal and actually a good thing if it means they will be able to stick around for the longer term. Consider that you are asking a guy who has been maintaining open source projects for more than a decade, with some degree of success. So his strategy is probably working for him.

jakubmazanec 2y ago
> To preserve backward compatibility. What backwards compatibility? There is already migration guide from v1 to v2.
- yawaramin 2y ago
  And the guide is mostly 'Everything is pretty much the same, just a couple of minor tweaks and default changes'.
  - jakubmazanec 2y ago
    Then why v2? If there are no breaking changes, why increase the major version? And if there are breaking changes, why not fix the quirks? Seriously, decisions like this show me the maintainers are just blinded by their lack of front-end skills, whining about JavaScript and striving for questionable "purity" - it's the same with the codebase (as mentioned by other commenters): one large unmaintainable file, because build step is too complex or whatever nonsense. Anyway, excellent article and discussion that showed me I can forget about HTMX :D
    - yawaramin 2y ago
      Did you read the v2 release notes? The big thing they got rid of was IE11 support. Everything else was relatively minor. Having a bunch of breaking changes in v2 would have made the upgrade much more difficult for users, and a big part of their philosophy is making upgrades easy. Of course, no one is forcing you to use htmx. Please use whatever you like.