[asdfsa32]

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.

[xutopia]

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]

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]

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]

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]

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.

[wredcoll]

> If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework.

Yeah, because clients never need to keep track of state like which block is expanded or which tab is selected or that the previous page was or what the user is currently typing...

[xutopia]

Angular being basically the same HTMX is nonsense and you should know better.

Say you have a huge Google Ads budget burning up on those landing pages. Make one version with React and one with HTMX. Open Lighthouse and see performance difference. First page renders are much slower with React. Page load is slower and this makes a huge difference in mainland USA where people are still on 3G speeds on their budget phones.

"High traffic" might be the simplified view here and it took me a few page memos to explain it to my lead but the gist is that React is slower, takes longer to load and most of what it is used for is easily done with plain HTML and sprinkles of JS as needed. Unless you're streaming sound or video like you do on Facebook pages it's really not the right tool for the job in a majority of cases.

[asdfsa32]

The only nonsense here is ignoring that React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015.

The gist of it continuously seems to be that people who think HTMX Great, know very little about good frontend engineering.

[gulugawa]

One key part of good frontend engineering is picking tools to effectively solve current challenges your product is facing. Thinking about theoretical problems that may not apply to you is a waste of time.

I don't currently use use HTMX. However, that doesn't invalidate the use of htmx by others when it is a better fit for their experience and use cases.

[asdfsa32]

htmx is no more invalid than Visual Basic, and the parallels goes deeper than that.

[JSR_FDED]

If you really think HTMX and Angular 1.0 are equivalent then…actually I don’t even know where to begin.

[officialchicken]

Being a curmudgeon is not good engineering leadership. "Seeing everything" is just old people being wistful, not actually contributing or doing in the now. I deployed (via ftp) my first site before Netscape so I do understand where you're coming. There isn't at present a valid or detailed criticism of why X won't Y based on all of that supposed XP - so why mention it? Educate us - why will it fail? Is it because you never mastered CDN's or the exact opposite? It certainly doesn't lead any credibility the assertion that A will become Z because they look similar or embrace similar ethos.

[asdfsa32]

You need to read things in the context, Chicken.

But I will answer your main questions since your comment seems to be in good faith.

Just like angular 1 choked on complex, high-frequency UIs, HTMX is going to follow the same faith. Github uses a similar approach to HTMX and you will find that even for such a simple system, their notification indicator elements on the same page are often out of sync.

The reasons for this is that State Management is hard, which is why the reconciliation loop of React-like frameworks and shadow-dom does away with pushing complex state management to user application and handles it systematically.

Of course, this doesn't mean htmx is useless, for a specific case of web apps, it is good enough, but the problem is that often times, you start with "specific cases" and your application grows overtime.

So when you consider that and the cost of doing htmx vs React or any react-like framework, picking htmx is only reasonable if it is the only option you're comfortable with and rarely on merit.

[ifwinterco]

Why would react fail for higher traffic pages?

If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version.

Most of the time (existing user using the same browser, no update) there will be precisely zero traffic to your servers to load the React app except for the initial HTML skeleton.

For an app using SSR it's more complicated and I'll admit I don't know how that works at very high load

[xutopia]

I had landing pages using React on a 1.6M/m budget. The loading times on cell phones in mainland USA meant we had people cancelling the loading of pages. When we converted to straight up cached HTML we saw a huge increase in full page loads.

People weren't cancelling the page load and surfing back anymore. You cannot argue that React is extremely heavy and also adds a lot of time between first render. Test a normal HTMX page in Lighthouse and then convert it to React and you'll see how drastic things are.

People use React today out of habit rather than because it's the best tool for the job.

[shooly]

> loading times

What does React have to do with loading times of a page? React does not contribute to that at all other than having to download the JS runtime, which with Preact is 3KB.

> You cannot argue that React is extremely heavy and also adds a lot of time between first render

Yes you can! In no world would React itself add enough render time to make people navigate back, even if running on a computer from the 90s!

[Skinney]

React itself, or Preact for that matter, is just the baseline. You still need the application itself, which in every application I’ve worked on is quite a bit bigger than the framework itself.

So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly.

If you’re in a place with unreliable or plain out bad signal, the difference will be quite noticeable.

[shooly]

> every application I’ve worked on is quite a bit bigger than the framework itself

That's why most client-side routing libraries support lazy loading. You don't have to load the entire application at once, only the parts you need.

> So you need to download the app, maybe have that app perform some fetch requests

That's... completely unrelated to React, though? Parent comment claimed that React is slow and HTMX fast - does HTMX make fetches magically faster or what?

[asdfsa32]

This just shows that despite the 1.6M/m budget, you did not have people who could do react correctly. React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015.

But while first render is of course important, now everything else is more expensive with htmx because you have to generate HTML on the server, on top of your usual fetch pipeline. Yes, for small traffic it makes little difference, but once you have >10k/s requests, things start to cost.

[xutopia]

Yes but why bother with React, Hydrating pages at all if you can do something simpler? What advantages does React provide here?

HTMX tools are simpler while providing straightforward thinking around html fragment caching, whole page caching. React just gives a runaround way of doing everything. I'll remind you React was built so that people could continue watching a streamed video while they navigated on a page. Most pages aren't streaming anything.

[robertoandred]

What advantages does HTMX have? You end up with splintered spaghetti code, multiple languages/idioms, and unpredictable state.

[asdfsa32]

Because "simple" is transient at best and a lie at worst.

But for more details, see the sibling comment:

https://news.ycombinator.com/item?id=49069477

[ifwinterco]

Yes it’s true that for a landing page (relatively simple site, most users are unique) React is not the natural choice.

It can probably be made to work well if written by people who know what they’re doing using SSR, but it’s not what React was originally designed for

[gulugawa]

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.

[bcrosby95]

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

[dajonker]

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/ Please read this and reply when you still think it's hype.

[asdfsa32]

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]

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

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

[monooso]

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

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.

[asdfsa32]

This is ignoring the React Native and Flutter prominence on App Stores as well.

[wredcoll]

I miss vue2.0 =[.

JSX just feels weird.

[jfengel]

> I have no idea what this means. The World Wide Web itself is quite literally hypermedia.

I think he's saying that the Web is hypermedia plus Javascript, rather than just hypermedia. Which means, from the standpoint of the power of hierarchy, that it's Javascript, which also happens to use some hypermedia. Even if you use only a tiny bit of a Turing-complete language, Turing-completeness defines what your system actually can do.

This makes the Web fundamentally awkward, because most of the behavior is defined by the hypermedia part, and users have inconsistent expectations for what happens when you break the illusion.

HTMX works by extending the illusion. JSX works by breaking the illusion earlier rather than later.

[robertoandred]

The creators of HTMX are combative, dismissive, and short-sighted. Keep them far away from any spec discussions.

[pelagicAustral]

> hot take > 70-day old account > relentless contrarianism

steer clear.