Regarding the mixing of htmx with SPA-frameworks, my approach would be to have htmx own the main page and control the flow, such that the SPA bits are no longer SPA but isolated pockets of JavaScript and client state. An example could be embedding an interactive map on one page.
1 Like
Didibus,
In my experience, the more complex the application, the less likely SPAs like React are a good fit.
This framing is wrong:
For example, I once wrote an in-browser video editor. The complexity of the state was all client side. And it was very complex: it needed to recognize objects in the video, add animations and effects, stitch in different audio sources, undo/redo etc.
Is React a good fit for editing and rendering videos and video effects at a high frame rate? I doubt many people would argue it would be, even aside from its performance overhead. It’s a bad fit precisely because of the complexity of the UI requirements and the amount of state involved.
Truly sophisticated requirements for UIs are just as likely to rule out a React-style SPA frameworks as to recommend it.
Even where something like React may be useful, it’s usually much better to take an incremental approach, where you opt into complexity only where you need it in your application.
And this is assuming that UI complexity is the main form of complexity in your application. Much of the time, I see developers talk themselves into thinking they have a “complex UI” (really just forms and text) when the main complexity is in the business domain – where SPAs tend to be particularly problematic.
4 Likes
@thomascothran that’s a good design philosophy ‘to take an incremental approach, where you opt into complexity only where you need it in your application.’
Did you write the video editor in ClojureScript? Have you found ways to tame the complexity of an in-browser video editor? We wrote two of them, but they are both way too (accidentally) complex.