5 ms·

Great, now you can't offload your FE to a CDN. But on serious note, htmx is basically a solution in the search of a problem. It is the new hype. Or rather, a

Great, now you can't offload your FE to a CDN. But on serious note, htmx is basically a solution in the search of a problem. It is the new hype. Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap. The fundamental problem is that it is pretending to be a declarative language while entirely imperative.

dajonker 2mo ago
This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach? Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is? The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproject.org/ https://triptychproject.org/ Please read this and reply when you still think it's hype.
- asdfsa32 2mo ago
  I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatches and what not. And the features specified in that project is nice to have, in the same way that it is nice that we have Date Pickers or other advanced input features, but it is never going to replace React-like frameworks. Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
  - monooso 2mo ago
    > Hypermedia is what to web apps what XML is to programming languages. I have no idea what this means. The World Wide Web itself is quite literally hypermedia. The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true. > Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management... You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.
    - asdfsa32 2mo ago
      > You may have stabilised on JSX, "we" have not. Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. So I am not sure what "we" you are talking about.
      - asdfsa32 2mo ago
        This is ignoring the React Native and Flutter prominence on App Stores as well.
      - monooso 2mo ago
        > Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. I have no idea if that's accurate, but let's assume for a moment that it is. - Vue supports JSX, but it is not the default. - Angular does not support JSX. - Svelte, which you neglected to mention, does not support JSX. - Solid does indeed use JSX, as of course does React. So two out of the five main SPA frameworks don't even support JSX, and another doesn't typically use it. As I said, you may have stabilised on JSX, "we" have not.
        asdfsa32 2mo ago
        I listed frameworks that makes majority of the market share that are based on JSX and react-like reconciliation loop. This architecture is also now dominate in the mobile apps space via React Native and Flutter as well. So I am not sure what you're talking about. The industry has largely stabilised on this architecture because it works. So I don't know who this "we" you're talking about or what you're even talking about anymore.
- robertoandred 2mo ago
  The creators of HTMX are combative, dismissive, and short-sighted. Keep them far away from any spec discussions.
xutopia 2mo ago
Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.
- asdfsa32 2mo ago
  How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion. I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half decade as that was the best option at the time, but sooner or later, you get sick of stuffing "little codelets" inside attributes all over the place, which is exactly what htmx does. If you want to understand what htmx is going to look like at scale, look at angular 1.0 projects.
  - wild_egg 2mo ago
    As someone who wrote a lot of angular back in the day, and who writes a lot of htmx in the current day... That comparison makes absolutely no sense. The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.
    - asdfsa32 2mo ago
      It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.
      - wild_egg 2mo ago
        Based on skimming the couple sibling comments, I believe the issue you have had with htmx is precisely that you have somehow conflated it with angular. If you think they're the same, you will use them the same and have the same poor outcomes. In another comment, you mentioned State Management. If this is on your mind then you are using htmx wrong. You should not be managing any client side state with htmx. State is on the server or in your database. Interactions on the client should immediately reflect the updated server state. If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.
bcrosby95 2mo ago
For what it's worth, your last statement is why react always felt off to me.
pelagicAustral 2mo ago
> hot take > 70-day old account > relentless contrarianism steer clear.
bfjvibybd6cuvu6 2mo ago
[flagged]
gulugawa 2mo ago
The overwhelming majority of websites are small projects that don't need complex tools to provide interactivity.For those websites, complexity is more likely to come from planning for complexity that will never exist. Using a tool such as htmx is an effective way for them to solve current challenges while minimizing complexity.

dajonker 2mo ago

This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach? Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is? The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproject.org/ https://triptychproject.org/ Please read this and reply when you still think it's hype.

asdfsa32 2mo ago
I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatches and what not. And the features specified in that project is nice to have, in the same way that it is nice that we have Date Pickers or other advanced input features, but it is never going to replace React-like frameworks. Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
- monooso 2mo ago
  > Hypermedia is what to web apps what XML is to programming languages. I have no idea what this means. The World Wide Web itself is quite literally hypermedia. The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true. > Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management... You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.
  - asdfsa32 2mo ago
    > You may have stabilised on JSX, "we" have not. Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. So I am not sure what "we" you are talking about.
    - asdfsa32 2mo ago
      This is ignoring the React Native and Flutter prominence on App Stores as well.
    - monooso 2mo ago
      > Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. I have no idea if that's accurate, but let's assume for a moment that it is. - Vue supports JSX, but it is not the default. - Angular does not support JSX. - Svelte, which you neglected to mention, does not support JSX. - Solid does indeed use JSX, as of course does React. So two out of the five main SPA frameworks don't even support JSX, and another doesn't typically use it. As I said, you may have stabilised on JSX, "we" have not.
      - asdfsa32 2mo ago
        I listed frameworks that makes majority of the market share that are based on JSX and react-like reconciliation loop. This architecture is also now dominate in the mobile apps space via React Native and Flutter as well. So I am not sure what you're talking about. The industry has largely stabilised on this architecture because it works. So I don't know who this "we" you're talking about or what you're even talking about anymore.
robertoandred 2mo ago
The creators of HTMX are combative, dismissive, and short-sighted. Keep them far away from any spec discussions.

xutopia 2mo ago

Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.

asdfsa32 2mo ago
How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion. I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half decade as that was the best option at the time, but sooner or later, you get sick of stuffing "little codelets" inside attributes all over the place, which is exactly what htmx does. If you want to understand what htmx is going to look like at scale, look at angular 1.0 projects.
- wild_egg 2mo ago
  As someone who wrote a lot of angular back in the day, and who writes a lot of htmx in the current day... That comparison makes absolutely no sense. The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.
  - asdfsa32 2mo ago
    It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.
    - wild_egg 2mo ago
      Based on skimming the couple sibling comments, I believe the issue you have had with htmx is precisely that you have somehow conflated it with angular. If you think they're the same, you will use them the same and have the same poor outcomes. In another comment, you mentioned State Management. If this is on your mind then you are using htmx wrong. You should not be managing any client side state with htmx. State is on the server or in your database. Interactions on the client should immediately reflect the updated server state. If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.

bcrosby95 2mo ago

For what it's worth, your last statement is why react always felt off to me.

pelagicAustral 2mo ago

> hot take > 70-day old account > relentless contrarianism steer clear.

bfjvibybd6cuvu6 2mo ago

[flagged]

gulugawa 2mo ago

The overwhelming majority of websites are small projects that don't need complex tools to provide interactivity.For those websites, complexity is more likely to come from planning for complexity that will never exist. Using a tool such as htmx is an effective way for them to solve current challenges while minimizing complexity.