5 ms·

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

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.

epolanski 2mo ago
> 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. That's how interactivity has always worked. Server-side render everything + ship interactivity via js on top of it. I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application. This is a very narrow and specific problem: navigating from page to page not causing full page reloads. But the web has changed since SPAs were needed in major ways: 1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js. 2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web. In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client. There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears. But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem. They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows. What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.
- ko27 2mo ago
  > the average device and connection is insanely faster than 10-15 years ago Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.
  - bbg2401 2mo ago
    I’m not sure I follow. SPA’s tend to require more network round trips, sometimes significantly more based on the architecture.
    - Izkata 2mo ago
      But a lot of the time they can happen in the background where the user doesn't see them, or on a part of the page the user isn't currently interacting with, preventing it from being a stop-the-world interruption.
    - ko27 2mo ago
      It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.
      - inigyou 2mo ago
        An SPA still requires roundtrips, just not to load the DOM root. Most of them do more than one roundtrip per navigation, making them worse than MPA. They also break loading screens.
        Exoristos 2mo ago
        They don't have to be that way.
Pxtl 2mo ago
> Forum websites mostly deliver non-interactive content I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things. Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them. Is that the kind of thing you'd be giving up as you move to a platform like HTMX?
- toddmorey 2mo ago
  Nope, HTMX could power endless scroll features if you want them
  - egeozcan 2mo ago
    Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it. If you want basic interactivity, HTMX is fine. If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/ ) And yes there are also some scenarios that you want to control the whole routing and rendering stuff, then go for Solid, React, Angular, Vue, whatever. There is no golden rule to all of this but finding out what makes sense is a fun exercise.
    - snorremd 2mo ago
      I don't necessarily disagree that there comes a point at which you are working more against HTMX than with it. I think rather than measuring that contention point between HTMX and SPA/MPA in terms of interactivity I'd measure it in the amount of client side state and logic needed. If you need a bunch of client side state and logic, for example a digital audio workstation, then a SPA would definitely be the appropriate pattern. 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.
moritzwarhier 2mo ago
Agreed very much. I'd extend this to "web apps that revolve around forms, views, filters and pagination" when it comes to "Ajax" stuff (yes, I'm old). The part of htmx that's relevant to these topics being discussed here, I once wrote an inferior clone of, some years ago. It was "isomorphic", tailored to our PHP-based CMS, and could handle filters, search forms, and pagination. Suitable for forums definitely, and current PHP-based forum software vendors that are still on the market follow the same paradigm.
ktosobcy 2mo ago
To paraphrase: "I think HTMX is a great fit for <majority of websites on the internet> save for a few that want to be an _APP_"… :)

epolanski 2mo ago

> 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. That's how interactivity has always worked. Server-side render everything + ship interactivity via js on top of it. I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application. This is a very narrow and specific problem: navigating from page to page not causing full page reloads. But the web has changed since SPAs were needed in major ways: 1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js. 2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web. In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client. There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears. But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem. They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows. What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.

ko27 2mo ago
> the average device and connection is insanely faster than 10-15 years ago Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.
- bbg2401 2mo ago
  I’m not sure I follow. SPA’s tend to require more network round trips, sometimes significantly more based on the architecture.
  - Izkata 2mo ago
    But a lot of the time they can happen in the background where the user doesn't see them, or on a part of the page the user isn't currently interacting with, preventing it from being a stop-the-world interruption.
  - ko27 2mo ago
    It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.
    - inigyou 2mo ago
      An SPA still requires roundtrips, just not to load the DOM root. Most of them do more than one roundtrip per navigation, making them worse than MPA. They also break loading screens.
      - Exoristos 2mo ago
        They don't have to be that way.

Pxtl 2mo ago

> Forum websites mostly deliver non-interactive content I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things. Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them. Is that the kind of thing you'd be giving up as you move to a platform like HTMX?

toddmorey 2mo ago
Nope, HTMX could power endless scroll features if you want them
- egeozcan 2mo ago
  Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it. If you want basic interactivity, HTMX is fine. If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/ ) And yes there are also some scenarios that you want to control the whole routing and rendering stuff, then go for Solid, React, Angular, Vue, whatever. There is no golden rule to all of this but finding out what makes sense is a fun exercise.
  - snorremd 2mo ago
    I don't necessarily disagree that there comes a point at which you are working more against HTMX than with it. I think rather than measuring that contention point between HTMX and SPA/MPA in terms of interactivity I'd measure it in the amount of client side state and logic needed. If you need a bunch of client side state and logic, for example a digital audio workstation, then a SPA would definitely be the appropriate pattern. 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.

moritzwarhier 2mo ago

Agreed very much. I'd extend this to "web apps that revolve around forms, views, filters and pagination" when it comes to "Ajax" stuff (yes, I'm old). The part of htmx that's relevant to these topics being discussed here, I once wrote an inferior clone of, some years ago. It was "isomorphic", tailored to our PHP-based CMS, and could handle filters, search forms, and pagination. Suitable for forums definitely, and current PHP-based forum software vendors that are still on the market follow the same paradigm.

ktosobcy 2mo ago

To paraphrase: "I think HTMX is a great fit for <majority of websites on the internet> save for a few that want to be an _APP_"… :)