I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS.
With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions.
The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
I basically use HTMX for all my Web Apps, including PWA(s) that run as ~near native apps on iOS/Android. It's great! I aso pair this with DaisyUI+TailwindCSS. YOu really can't go wrong, there is something quite pleasant about writing your web apps in ordinary HTML with partials and the extensions that HTMX adds to the browser for SPA-like interactivity.
Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.
That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.
I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).
Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.
In principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can.
However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it.
Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.
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.
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.
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
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.
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.
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, the reconciliation loop and shadow-dom does away with pushing complex state management to user application and handles at 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.
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.
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.
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.
> 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.
With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions.
The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.
However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.
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.
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
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.
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, the reconciliation loop and shadow-dom does away with pushing complex state management to user application and handles at 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.
The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.
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.
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.
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.