As always with new tech, I think htmx will create more frontend jobs after the fad is over.
As always with new tech, I think htmx will create more frontend jobs after the fad is over.
However, a client that has a reliable connection has more options available to them compared to an unstable one.
If their internet connection is poor, then I would argue it is not just an htmx issue -- it is an overall website one! Does not matter whether fetching json or html. In this case we do not want all interactions to be server ones.
Now we are entering the territory of understanding what the client wants. In this case, it might be easier to build a GUI application or Android/IOS app, with a SQLite local database, queue requests, etc. So when they do have a connection, even momentarily, the queued data can get sent out.
Again - it depends on the problem!
That's a terrible premise to start with. No, websites back in 2007 didn't work well otherwise we wouldn't have changed so much since then.
> If their internet connection is poor, then I would argue it is not just an htmx issue -- it is an overall website one! Does not matter whether fetching json or html. In this case we do not want all interactions to be server ones.
In 2024 if your webapp can't open a settings page without internet connection it means your architecture is lame. There is no way requesting a server to open a modal is a smart strategy, period.
Depends what you mean by a Settings page. Generally speaking, when it comes to web applications... any requests need to come from the server... or changes a user makes needs to go back to the server. Period. It if doesn't... it doesn't. Spit a user friendly message.
I have webapps that need to update user requests there and then, so their changes are exposed on other media/platforms. So, for me, a "settings page that can be used without internet connection" is pointless for my projects.
Again - what you want from a Settings page may have merit in your projects but they are a waste of energy for mine. Again, as I stated earlier, it is all about the problem you are trying to solve. What is lame architecture to you is additional bloat in mine.
In a number of scenarios, using htmx might not be the right approach. I could also say the same thing for React.
I have nothing further to add to this. As you mentioned, there could be more work for frontend devs. I doubt it is because of htmx fad being over... more likely it is some "cool toy" choo-choo train that replaces React.