Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

But interactivity in largely content-driven sites doesn't necessarily preclude HTMX. You can do a bunch of fancy interactive stuff with HTMX and some minimal JS. Drag and drop sort is a tiny drop-in JS snippet. Skeleton loaders and spinners are supported out of the box in HTMX as is infinite scroll as others pointed out.

I'm not saying Next.js, Solid Start, Remix, Nuxt or some other hybrid server and client rendered model doesn't work for forum software. Or that even client only rendering can be a valid approach if you accept the trade-offs (no curl-ability). People should use whatever they feel productive building with.

But if your backend is already a non-JavaScript server rendered framework like Django then HTMX makes a ton of sense to add some interactivity.

Your prior claim was that they only solve one problem, not about a definition. They solve several problems:

- less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen)

- the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers

- you can write tests for your frontend, e.g. you can unit test components' behaviour and style in isolation

- the frontend can also work, or at least respond usefully to the user, when the network or the backend are not working

According to what you said, CSS also solves the problem of making an SPA because you could "switch pages" by changing CSS class names on `body`. But if someone asked what CSS is you're not gonna answer "you use CSS to make an SPA", even though _technically_ you can use it to make an SPA.

Which makes it even more ironic that in the 10 years since React was announced in 2013 and when I quit Facebook, they never managed to fix the original state synchronization bug that they demonstrated in the original React announcement for more than a few months at a time at best.

I'm sure technically it wasn't a singular bug over the years and the causes were complex, but React did fuck all in relation to the unread message counter being correct.

SSE is perfect for chat/notifications and is a lot simpler than syncing. The server pushes updates to the client doesn't require a sync. SSE is also more performant since it can keep the connection open. The example below is on a $10 vps last I heard.

https://data-star.dev/examples/dbmon

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

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.

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.

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!

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.

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.