alt Hacker News> Vanilla js with fetch, getElementById, innerText, is 99% of what people need for these types of simple sites.
But it's not only for simple sites. Don't underestimate the power of, say, a SSE stream using brotli compression: this can stream a shitload of data for serious apps (like real-time financial data).
Resource usage on the client-side is also close to nil with a SSE stream and minimal JavaScript and on the server-side it hardly changes anything: that data was going to be sent to the front-end one way or another anyway.
And if you take something like DOM morphing and, say, Datastar: it's not conceptually that different from React. The DOM reconciliation doesn't happen at the same place and not in exactly the same manner, but it's not entirely dissimilar IMO.
It's not just htmx: there's are different projects and, interestingly IMO, developers from many different languages who are now beginning to tackle this problem of Javascript (way too) heavy frameworks.
I think it's a bit early to say this is a niche.
In my (small) experience, SSE is a bit finicky: 1) Firefox kills a webpage's SSE connection when you close and open the laptop lid, making you write code to reconnect, unlike other browsers; 2) there's no way to see the HTTP status code if something went wrong; 3) proxies can still mess things up sometimes: https://dev.to/miketalbot/server-sent-events-are-still-not-p...
If you have a constant stream of data, SSE does make sense. But if your goal is to have events arriving infrequently or a irregular times, then good old long polling will work in strictly more cases, at the cost of maybe 2x more resources.