3 ms·

I enjoyed reading this. It follows a similar experience with our first htmx website, away from using modern frontends, or just simple jQuery with ajax json data

I enjoyed reading this. It follows a similar experience with our first htmx website, away from using modern frontends, or just simple jQuery with ajax json data. I remember, working with a co-worker, we planned out the process (a step-by-step on the application like this post) and it made sense to me - but this journey was much harder for my co-worker. Why is this? Simply because he is familiar with MVC pattern of sending json data back and forth, and getting the frontend to update and render it, etc. The idea of html flying with htmx as the behaviour (inside html tags) was just too much. For me, I always preferred the old school way of just letting the server-side generate the html. All htmx does is adds extra functionality. I tried hard to explain that we are sending html back, and to break things down one at a time but each new task was left scratching his head. In the end, our website had somewhere around 20-50 lines of javascript! Much smaller footprint than over 400 lines in our previous project (that being generous). Sure, our server side code was larger, but it was all organised into View/PartalView files. To me, it made really good sense. In the end, I dont think I won htmx over with my co-worker. As for another co-worker, who had a chance to build a new project with htmx, decided on some client javascript tool instead. I dont think I got a legit answer why he did that. With all this above, I learned that some (perhaps most... perhaps all) struggle to adapt to htmx based on their many years building websites a particular way, with popular tools and javascript libraries. Overall htmx does not really change anything - you are still building a website. If anything htmx just add an additional layer to have website really work. Yoda's words now have new meaning :- "No! No different. Only different in your mind. You must unlearn what you have learned." For some its just not happening. I guess Luke Skywalker really shows his willpower, being able to adapt to htmx easier than others. :-)

ksec 1y ago
I remember someone on HN puts it really well. There is a whole generation of developers that thinks frontend = React. And more importantly they are in much larger number than those of us who went through DHTML and Ajax. We are now the minority, and they are the norm.
- owebmaster 1y ago
  In 10 years, the people that knows React will be the minority compared to the ones that only know vibecoding.
  - xp84 1y ago
    True, but all the FE generated by that will be echoes of React, so my head will still hurt
  - switknee 1y ago
    Not only that, but interviewers will only value one particular vibecoding framework with a silly name, and will expect 10 years of experience in it.
- emseetech 1y ago
  Not just developers, but designers. Finding designers who understand hypermedia in that way is nearly impossible. A team that decides to shift towards this approach to development has to get buy-in from the designers as well. It's not just the devs who have to retrain.
  - masfoobar 1y ago
    > Not just developers, but designers. Finding designers who understand hypermedia in that way is nearly impossible. This is true. 100% The difference for me and my AppDev career history is -- I never worked with a team of dedicated frontend developers. We are primarily backend developers who are frontend devs as well (though we can admit it is secondary to our backend skills) Personally, the change for us was placing our html on the server side. So, to me, styling is not a problem and easy to test. It should be, with some training, easy for a dedicated frontend developer to jump in as well... though we might have to shuffle things around with their tools, to gel nicely with the backend team. If anything, I think this transition would keep the two departments closer together - communication is needed especially for htmx webapps. I think it can be difficult to win over other backend developers with htmx, as my original post suggests. Adding a frontend layer as well... it is unlikely htmx will be taken seriously when the majority want to stick with what they know.
zero_shift 1y ago
The change was mobile. Once you had multiple clients, with varying levels of thick state (e.g. offline first for Android), it started making sense to streamline around a data-driven API and rich client apps. That's honestly the main reason. It's so you can build all three channels the same(ish) way

ksec 1y ago

I remember someone on HN puts it really well. There is a whole generation of developers that thinks frontend = React. And more importantly they are in much larger number than those of us who went through DHTML and Ajax. We are now the minority, and they are the norm.

owebmaster 1y ago
In 10 years, the people that knows React will be the minority compared to the ones that only know vibecoding.
- xp84 1y ago
  True, but all the FE generated by that will be echoes of React, so my head will still hurt
- switknee 1y ago
  Not only that, but interviewers will only value one particular vibecoding framework with a silly name, and will expect 10 years of experience in it.
emseetech 1y ago
Not just developers, but designers. Finding designers who understand hypermedia in that way is nearly impossible. A team that decides to shift towards this approach to development has to get buy-in from the designers as well. It's not just the devs who have to retrain.
- masfoobar 1y ago
  > Not just developers, but designers. Finding designers who understand hypermedia in that way is nearly impossible. This is true. 100% The difference for me and my AppDev career history is -- I never worked with a team of dedicated frontend developers. We are primarily backend developers who are frontend devs as well (though we can admit it is secondary to our backend skills) Personally, the change for us was placing our html on the server side. So, to me, styling is not a problem and easy to test. It should be, with some training, easy for a dedicated frontend developer to jump in as well... though we might have to shuffle things around with their tools, to gel nicely with the backend team. If anything, I think this transition would keep the two departments closer together - communication is needed especially for htmx webapps. I think it can be difficult to win over other backend developers with htmx, as my original post suggests. Adding a frontend layer as well... it is unlikely htmx will be taken seriously when the majority want to stick with what they know.

zero_shift 1y ago

The change was mobile. Once you had multiple clients, with varying levels of thick state (e.g. offline first for Android), it started making sense to streamline around a data-driven API and rich client apps. That's honestly the main reason. It's so you can build all three channels the same(ish) way