4 ms·

HTMX is signaling they're around for the long haul, we'll see if they break backwards compatibility or rewrite their API 15 times in the next year. I had one o

HTMX is signaling they're around for the long haul, we'll see if they break backwards compatibility or rewrite their API 15 times in the next year. I had one of my dev's do several node/js framework POCs in _September_ last 2023 (current year is Jan 2024 at the time of this writing). Nearly all of the POCs won't even run or build any more because the developers have rewritten something and broke all backwards compatibility. The Javascript/Node ecosystem is terrible for businesses and you're incinerating cash if your company running in the Node/Javascript rat race. I'm hoping HTMX injects some sanity into frontend development.

taeric 3y ago
This feels extreme? Any chance you could share numbers or more details on these prototypes? I agree that the ecosystem seems crazy fast on moving. I wouldn't have thought it was that bad. React, in particular, I thought had been fairly stable? (Yes, there are new ways of doing things, but most of the old still work there, to their credit.)
- jokethrowaway 3y ago
  I don't think it's been the case for the last few months in particular, but Next has been historically terrible for this case. It sucks because it's also the best way of developing a React app without worrying much about tons of boilerplate crap. I have different next projects started at different times and whenever I need to change a single line of text, I have a 50% chance something won't work and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host. I got hit by OpenSSL issues for a static website. Then a potential solution is to upgrade the framework (next or react) but then you start running into a bunch of other issues and you find yourself 8 hours deep for a copy change. Performance is also a pain to get right as the abstractions keep piling up and especially the rendering cycle of React is a massive pain. The move from class to functional (for the majority a net positive as the functional version is way more readable and clear) made accessing some hooks harder, so know you need to remember some special rules or functions to call in order to get the behaviour you want. For all new projects I just use solid.js which is a bit nicer compared to React while keeping most of React syntax. The abstraction layer is much smaller compared to React (no vdom, no custom rendering cycle, your function gets executed once, not once per re-render). You just have to remember you are dealing with Proxy instances and you're good to go. Somehow I didn't have problems with updates but there is way less activity compared to React. I have some projects from 3 years ago just using solid.js, and a bunch of projects with solid-start. I didn't bother updating them, they keep on running, can't complain.
  - radicalriddler 3y ago
    > and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host Oh, you're not using Vercel? There's your first mistake \s
chatmasta 3y ago
It sounds like your devs are not following best practices with regards to lockfiles and version pinning.
- satvikpendem 3y ago
  Indeed. If half won't even build anymore, that's insane. It seems like they want to be on the latest version all the time which obviously will have breaking changes.
  - gkbrk 3y ago
    > they want to be on the latest version all the time which obviously will have breaking changes Not very common in sane ecosystems.
    - satvikpendem 3y ago
      It's common everywhere that at least one dependency will have some breaking change, even in "same ecosystems."
      - zo1 3y ago
        No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order of magnitude smaller. One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semantic versioning" and you have devs that willy nilly change public facing interfaces.
        satvikpendem 3y ago
        Not really. Python's is worse for example.
        3y ago
staminade 3y ago
Any POCs your devs wrote would have been targeted at a specific version of their framework dependencies via their NPM package.json / package-lock.json. So why would any later changes made by framework authors, even backwards incompatible ones, made you unable to run or build them?
- jmull 3y ago
  I assume they mean they updated their dependencies to the latest. That's somewhat valid. The trap is this: you have a strong need to update a dependency for a bug fix (particularly security fixes), but the update isn't compatible. So you've got no good option: either live with unfixed bugs or pay the price to update your app to the latest version. There is some wiggle room though. (1) libraries will often maintain a compatible branch for important fixes. (2) you can often find and apply just the fix/fixes you want to your own version of the library. Obviously, you start to lose the benefit of someone else maintaining the library for you, but when you aren't paying for it, you should always understand that is a nice but temporary state of affairs, so enjoy it while it lasts. (Actually, even when you are paying -- maybe even a lot -- you can still get left behind.)
recursivedoubts 3y ago
htmx 2.0 will be 99% compatible w/ htmx 1.0, and we'll provide a backwards compatibility extension: https://github.com/bigskysoftware/htmx/blob/v2.0v2.0/www/content/docs.md#htmx-1x-to-2x-upgrade-guide https://github.com/bigskysoftware/htmx/blob/v2.0v2.0/www/con... we will also continue to support htmx 1.0 for the forseeable future for people who need IE support or don't want to upgrade
pupppet 3y ago
That's the JS framework lifecycle. Get yourself noticed with minimal boilerplate. Then add more boilerplate.

taeric 3y ago

This feels extreme? Any chance you could share numbers or more details on these prototypes? I agree that the ecosystem seems crazy fast on moving. I wouldn't have thought it was that bad. React, in particular, I thought had been fairly stable? (Yes, there are new ways of doing things, but most of the old still work there, to their credit.)

jokethrowaway 3y ago
I don't think it's been the case for the last few months in particular, but Next has been historically terrible for this case. It sucks because it's also the best way of developing a React app without worrying much about tons of boilerplate crap. I have different next projects started at different times and whenever I need to change a single line of text, I have a 50% chance something won't work and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host. I got hit by OpenSSL issues for a static website. Then a potential solution is to upgrade the framework (next or react) but then you start running into a bunch of other issues and you find yourself 8 hours deep for a copy change. Performance is also a pain to get right as the abstractions keep piling up and especially the rendering cycle of React is a massive pain. The move from class to functional (for the majority a net positive as the functional version is way more readable and clear) made accessing some hooks harder, so know you need to remember some special rules or functions to call in order to get the behaviour you want. For all new projects I just use solid.js which is a bit nicer compared to React while keeping most of React syntax. The abstraction layer is much smaller compared to React (no vdom, no custom rendering cycle, your function gets executed once, not once per re-render). You just have to remember you are dealing with Proxy instances and you're good to go. Somehow I didn't have problems with updates but there is way less activity compared to React. I have some projects from 3 years ago just using solid.js, and a bunch of projects with solid-start. I didn't bother updating them, they keep on running, can't complain.
- radicalriddler 3y ago
  > and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host Oh, you're not using Vercel? There's your first mistake \s

chatmasta 3y ago

It sounds like your devs are not following best practices with regards to lockfiles and version pinning.

satvikpendem 3y ago
Indeed. If half won't even build anymore, that's insane. It seems like they want to be on the latest version all the time which obviously will have breaking changes.
- gkbrk 3y ago
  > they want to be on the latest version all the time which obviously will have breaking changes Not very common in sane ecosystems.
  - satvikpendem 3y ago
    It's common everywhere that at least one dependency will have some breaking change, even in "same ecosystems."
    - zo1 3y ago
      No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order of magnitude smaller. One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semantic versioning" and you have devs that willy nilly change public facing interfaces.
      - satvikpendem 3y ago
        Not really. Python's is worse for example.
        3y ago

staminade 3y ago

Any POCs your devs wrote would have been targeted at a specific version of their framework dependencies via their NPM package.json / package-lock.json. So why would any later changes made by framework authors, even backwards incompatible ones, made you unable to run or build them?

jmull 3y ago
I assume they mean they updated their dependencies to the latest. That's somewhat valid. The trap is this: you have a strong need to update a dependency for a bug fix (particularly security fixes), but the update isn't compatible. So you've got no good option: either live with unfixed bugs or pay the price to update your app to the latest version. There is some wiggle room though. (1) libraries will often maintain a compatible branch for important fixes. (2) you can often find and apply just the fix/fixes you want to your own version of the library. Obviously, you start to lose the benefit of someone else maintaining the library for you, but when you aren't paying for it, you should always understand that is a nice but temporary state of affairs, so enjoy it while it lasts. (Actually, even when you are paying -- maybe even a lot -- you can still get left behind.)

recursivedoubts 3y ago

htmx 2.0 will be 99% compatible w/ htmx 1.0, and we'll provide a backwards compatibility extension: https://github.com/bigskysoftware/htmx/blob/v2.0v2.0/www/content/docs.md#htmx-1x-to-2x-upgrade-guide https://github.com/bigskysoftware/htmx/blob/v2.0v2.0/www/con... we will also continue to support htmx 1.0 for the forseeable future for people who need IE support or don't want to upgrade

pupppet 3y ago

That's the JS framework lifecycle. Get yourself noticed with minimal boilerplate. Then add more boilerplate.