3 ms·

I am (mostly) a backend developer - so I deal with languages like C#, communicating with databases like MySQL, SQL Server, etc.. and sending data back (to thing

I am (mostly) a backend developer - so I deal with languages like C#, communicating with databases like MySQL, SQL Server, etc.. and sending data back (to things like) the frontend, such as HTML/Javascript. Despite this - I can do frontend development as well - but I have reached a point where I cannot be asked to learn new Javascript framework or libraries. Personally I just think it has become bloated, so I leave that for those that do know/understand.. like full-time React developers. I cannot be bothered as I am sure some new toy will come out in the next few years and replaces it. My opinion... and I understand it is apples and oranges... is web development could be much easier than it is today. Back in '00s we were using old school PHP or Classic ASP to return compiled HTML content and, mostly, full screen refreshes. Eventually, Javascript gained more responsibilities giving us JQuery. We had simple GET and POST functionalities, allowing us to refresh part of the page, etc. By around the 2010's I remember KnockoutJS and, eventually, AngularJS. Web development was changing and I accepted this. While I saw some benefits with auto refreshing hooks or the like.. the end was a lot of bloat... more lines of code. Some of which is duplicated in the frontend as well as the backend. Between 2016 to 2021 I stopped web development. I started a job as a GUI application developer. When I returned to web development I am now seeing Node being used... Grunt being used... with some websites sticking to JQuery while another is using React. I am in shock at how complicated things has gotten! To me, with my years of experience, feel like I am going full circle back to the old methods of web development... just with modern tools! I leaned back to jQuery for personal projects. It is easy to follow (in my opinion) -- but I came across HTMX in 2023 and really enjoying it! Using HTMX, With odd exceptions, my javascript code is mostly a compliment to my CSS. The amount of code is reduced by 60-80%! Since then I have started using HTMX for web projects at work -- with positive feedback from the team. We are, one by one, moving our projects over to HTMX. It is just easier to deal with. Our team only has half a dozen developers. We are mostly backend devs but OK with react. Some are better than others. We have agreed that with HTMX we are getting things done a lot easier. We no longer have to bother with the additional layer that is React. We also stopped using jQuery. Now I am not suggesting HTMX replaces React for all cases. Its just, for our use cases, it has done the job remarkably well.. and we are doing complicated web sites. Having a team of React devs may be needed in a number of scenarios - I, thinking of all websites I have built over the last 20 years, struggle to find one. There is a saying that is going to offend, but I think those that dislike or hating on HTMX are those that have invested their time on (things like) React. I also hear that HTMX guys are like a cult. That might be true to a degree. I am sure some will suggest I am one of them with this comment. - React creates jobs, but HTMX gets rid of them.

meiraleal 2y ago
htmx apps can't run without internet. Assuming that users will have a stable connection all the time is a big assumption. As always with new tech, I think htmx will create more frontend jobs after the fad is over.
- masfoobar 2y ago
  As I mentioned, websites back in 2007 were entirely server side and worked very well. Its 2024 and our internet connections are better. 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!
  - meiraleal 2y ago
    > As I mentioned, websites back in 2007 were entirely server side and worked very well 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.
    - masfoobar 2y ago
      > In 2024 if your webapp can't open a settings page without internet connection it means your architecture is lame 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.

meiraleal 2y ago

htmx apps can't run without internet. Assuming that users will have a stable connection all the time is a big assumption. As always with new tech, I think htmx will create more frontend jobs after the fad is over.

masfoobar 2y ago
As I mentioned, websites back in 2007 were entirely server side and worked very well. Its 2024 and our internet connections are better. 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!
- meiraleal 2y ago
  > As I mentioned, websites back in 2007 were entirely server side and worked very well 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.
  - masfoobar 2y ago
    > In 2024 if your webapp can't open a settings page without internet connection it means your architecture is lame 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.