Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should choose HTMX for your next web-based side project (2024)

hamy.xyz

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Why you should choose HTMX for your next web-based side project (2024)

#61

Post by andai »

zero_shift wrote: post #39
redwall_hp wrote: post #34

Earlier quoted context omitted.

Yes. The cycle has completed and the old new things are new again. But they're still too new and unproven for the React-embroiled companies to switch just yet. HTMX is basically a framework for AJAX that lets you more quickly set up interactions in the markup instead of having to write scripts to manipulate the DOM yourself. It also tells on sending HTML fragments over the asynchronous request instead of JSON that ha…

> 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.

Could you elaborate? What went wrong?

Re: Why you should choose HTMX for your next web-based side project (2024)

#63

Post by ksec »

zero_shift wrote: post #39
redwall_hp wrote: post #34

Earlier quoted context omitted.

Yes. The cycle has completed and the old new things are new again. But they're still too new and unproven for the React-embroiled companies to switch just yet. HTMX is basically a framework for AJAX that lets you more quickly set up interactions in the markup instead of having to write scripts to manipulate the DOM yourself. It also tells on sending HTML fragments over the asynchronous request instead of JSON that ha…

> 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.

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.

Re: Why you should choose HTMX for your next web-based side project (2024)

#64

Post by wibbily »

I loooooooove HTMX. Most of the sites I build are small in scope and requirements. Using HTMX gives me a way to add a little tiny bit of interactivity at almost no cost - same templates and HTML and shit as a MPA but magically delivered as a SPA. Plus it can gracefully degrade into a normal website, which is good for everyone.

Re: Why you should choose HTMX for your next web-based side project (2024)

#65

Post by wibbily »

eric-p7 wrote: post #62

This seems like a good place to plug my own lightweight, compilation-free library that adds reactivity and local styles to native web components: https://vorticode.github.io/solarite

Interesting. It seems like an easy way to get JS to interact with HTML bits on the client side (if I understand it correctly).

Maybe it could be useful alongside HTMX even: client-side HTML manipulation for simple things and server-side HTML hydration and rendering for complex things.

Re: Why you should choose HTMX for your next web-based side project (2024)

#66

Post by AstroBen »

uh_uh wrote: post #30
sgt wrote: post #23

Earlier quoted context omitted.

Htmx can scale. It's very basic and Htmx isn't the only technology to use that approach.

It cannot scale because it doesn't have a solution for reusable components. That's why I have abandoned it. Frameworks like React solve this in a much saner way.

server-side templating languages solved this decades ago

Re: Why you should choose HTMX for your next web-based side project (2024)

#67

Post by exiguus »

ksec wrote: post #63
zero_shift wrote: post #39

Earlier quoted context omitted.

> 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.

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.

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.

Re: Why you should choose HTMX for your next web-based side project (2024)

#68

Post by zero_shift »

andai wrote: post #61
zero_shift wrote: post #39

Earlier quoted context omitted.

> 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.

Could you elaborate? What went wrong?

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.

Re: Why you should choose HTMX for your next web-based side project (2024)

#69

Post by [deleted] »

recursivedoubts wrote: post #50
zero_shift wrote: post #40

Earlier quoted context omitted.

As I mentioned in a comment above, I've seen a few commercial projects attempted. But I'm hesitant to recommend HTMX, all three of them were failures (and for technical reasons not business ones)

Would you be willing to write an essay on why they failed? I'd be happy to host it here: https://htmx.org/essays/#on-the-other-hand

[deleted]

Re: Why you should choose HTMX for your next web-based side project (2024)

#70

Post by zero_shift »

ksec wrote: post #63
zero_shift wrote: post #39

Earlier quoted context omitted.

> 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.

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.

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.

Post reply on HN