3 ms·

> But they're still too new and unproven for the React-embroiled companies to switch just yet. I've seen a few of HTMX projects attempted in production, at my

> But they're still too new and unproven for the React-embroiled companies to switch just yet. I've seen a few of HTMX projects attempted in production, at my previous employer. Decently sized, moderately complex web products for serious commercial purposes I will say though, all three were complete disasters.

recursivedoubts 1y ago
Nothing magic about htmx or hypermedia: you still need to organize your code properly, and there are tasks for which it is not suited: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ However, in many case, it can be much simpler architecture than alternative approaches: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
- mnemonk 1y ago
  I disagree about the magical part :) It is truly refreshing to see how simple web development can be when using htmx instead of a full spa framework. I do full stack (angular, aspnet core, mssql) development in my daytime job. It can be... tiresome. Past couple of years i've built a soundcloud-like app using htmx, nodejs, express, mysql. Loved every minute. Thank you for all your effort on htmx. Edit: spelling.
andai 1y ago
Could you elaborate? What went wrong?
- zero_shift 1y ago
  I'll tell you about one of them. It was a kiosk app running on mobile tablets. It could have been a small native app, but the team, who were all pure Pythonists, tried that and decided it was too hard. So someone said React would be easy; after all it's just gluing together components, right? The React app was built in ~3 months but the deadlines had created technical debt. When the team had problems modelling all the state, and the Redux store became an incomprehensible mess, someone said, "The problem is React. HTMX will finally make things simple". They spent ~9 months on their HTMX rewrite and got even less far than the React version. It had numerous bugs; the UX had various regressions; it couldn't properly interact with some custom hardware; the state was now in the DB and apparently was not looking much nicer than it was in Redux, and eventually management pulled the plug. I didn't work on it directly so I don't know how much HTMX itself stymied the project. From my interactions with the team, I think the real problem was the attitude of the developers. They decided they "hated React" when in truth they were bad at thinking about UI, particularly UI state, and unwilling to learn. And HTMX gave succour to the fantasy they could continue not to. In fact that's how the initiative was sold to management, a way to turn non-UI devs into UI programmers.
ksec 1y ago
But why? And what is a moderately complex web products? For example is Gmail a moderately complex web products? I am guessing there is a whole generation of developers growing up where front end equals React and HTMX / HTML / CSS is somewhat of an alien. Compared to some of us growing up with HTML, DHTML and Ajax.
- exiguus 1y ago
  I think it depends on how seriously you take the frontend. Serious in the sense of design system, component library, reusability, accessibility and how well you want to test the frontend and its components in all variants independently. Then there is the independent work. Separation of concerns would be the keyword. If I now look at how I use htmx in go, I need something like templ to develop reusable components that I can test independently. To be able to work independently, it would make sense to mock the properties of the components. So I could build a design system or component library with go and htmx that I can test before I use it in the "real" application. That's how I know it from the Ajax era, when SpringBoot was used, for example. You copied the html of the frontend component and "translate" it into Spring. When I remember that time, I praise today, when it is enough to have an openapi spec with which you can make agreements. On the other hand, I clearly see the advantage of htmx if the project has one or two developers and you use an already finished design system or component library.
- zero_shift 1y ago
  I described one of them elsewhere. No, not like Gmail. Orders of magnitude less complex than that. No, being JS/React "native" wasn't the problem there. Actually the opposite. The developers were not willing to think about an application with state, and when they found modelling this hard (with Redux), they decided that React (a different technology) was the problem.
- chrisldgk 1y ago
  While React and JSX/TSX might be somewhat of an abstraction on top of HTML and CSS, you absolutely still need intricate knowledge of HTML and CSS to build anything good with React. In the end what you get out of your React code after your build process is vanilla HTML, CSS and JS. While you might be able to abstract some of those things away using libraries, all you‘re doing in your React code is building and manipulating HTML DOM trees within your React code and styling them using CSS (or using some abstraction like CSS-in-JS, CSS modules, etc.). To do so efficiently, you not only require knowledge of how exactly HTML and CSS work but also what React tends to do under the hood to render out your application. Even more so when things like a11y are required. A good dev also knows when to use JS to reimplement certain interactions (hover states, form submits, etc.) and when to use the native functionality instead (for example CSS pseudo selectors or HTML form elements). All this is to say that I disagree with the notion that React devs don’t know or understand the underlying technologies. It might be different and more abstracted, but it’s still the same technologies that require the same or more understanding to be used efficiently.

recursivedoubts 1y ago

Nothing magic about htmx or hypermedia: you still need to organize your code properly, and there are tasks for which it is not suited: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ However, in many case, it can be much simpler architecture than alternative approaches: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/

mnemonk 1y ago
I disagree about the magical part :) It is truly refreshing to see how simple web development can be when using htmx instead of a full spa framework. I do full stack (angular, aspnet core, mssql) development in my daytime job. It can be... tiresome. Past couple of years i've built a soundcloud-like app using htmx, nodejs, express, mysql. Loved every minute. Thank you for all your effort on htmx. Edit: spelling.

andai 1y ago

Could you elaborate? What went wrong?

zero_shift 1y ago
I'll tell you about one of them. It was a kiosk app running on mobile tablets. It could have been a small native app, but the team, who were all pure Pythonists, tried that and decided it was too hard. So someone said React would be easy; after all it's just gluing together components, right? The React app was built in ~3 months but the deadlines had created technical debt. When the team had problems modelling all the state, and the Redux store became an incomprehensible mess, someone said, "The problem is React. HTMX will finally make things simple". They spent ~9 months on their HTMX rewrite and got even less far than the React version. It had numerous bugs; the UX had various regressions; it couldn't properly interact with some custom hardware; the state was now in the DB and apparently was not looking much nicer than it was in Redux, and eventually management pulled the plug. I didn't work on it directly so I don't know how much HTMX itself stymied the project. From my interactions with the team, I think the real problem was the attitude of the developers. They decided they "hated React" when in truth they were bad at thinking about UI, particularly UI state, and unwilling to learn. And HTMX gave succour to the fantasy they could continue not to. In fact that's how the initiative was sold to management, a way to turn non-UI devs into UI programmers.

ksec 1y ago

But why? And what is a moderately complex web products? For example is Gmail a moderately complex web products? I am guessing there is a whole generation of developers growing up where front end equals React and HTMX / HTML / CSS is somewhat of an alien. Compared to some of us growing up with HTML, DHTML and Ajax.

exiguus 1y ago
I think it depends on how seriously you take the frontend. Serious in the sense of design system, component library, reusability, accessibility and how well you want to test the frontend and its components in all variants independently. Then there is the independent work. Separation of concerns would be the keyword. If I now look at how I use htmx in go, I need something like templ to develop reusable components that I can test independently. To be able to work independently, it would make sense to mock the properties of the components. So I could build a design system or component library with go and htmx that I can test before I use it in the "real" application. That's how I know it from the Ajax era, when SpringBoot was used, for example. You copied the html of the frontend component and "translate" it into Spring. When I remember that time, I praise today, when it is enough to have an openapi spec with which you can make agreements. On the other hand, I clearly see the advantage of htmx if the project has one or two developers and you use an already finished design system or component library.
zero_shift 1y ago
I described one of them elsewhere. No, not like Gmail. Orders of magnitude less complex than that. No, being JS/React "native" wasn't the problem there. Actually the opposite. The developers were not willing to think about an application with state, and when they found modelling this hard (with Redux), they decided that React (a different technology) was the problem.
chrisldgk 1y ago
While React and JSX/TSX might be somewhat of an abstraction on top of HTML and CSS, you absolutely still need intricate knowledge of HTML and CSS to build anything good with React. In the end what you get out of your React code after your build process is vanilla HTML, CSS and JS. While you might be able to abstract some of those things away using libraries, all you‘re doing in your React code is building and manipulating HTML DOM trees within your React code and styling them using CSS (or using some abstraction like CSS-in-JS, CSS modules, etc.). To do so efficiently, you not only require knowledge of how exactly HTML and CSS work but also what React tends to do under the hood to render out your application. Even more so when things like a11y are required. A good dev also knows when to use JS to reimplement certain interactions (hover states, form submits, etc.) and when to use the native functionality instead (for example CSS pseudo selectors or HTML form elements). All this is to say that I disagree with the notion that React devs don’t know or understand the underlying technologies. It might be different and more abstracted, but it’s still the same technologies that require the same or more understanding to be used efficiently.