[baskind]

Nice solution!

In my app, I use reusable Stimulus controllers alongside LiveView, and it works seamlessly as well.

On a general note, while it's a pleasure to build with LiveView, the more I use it in real-life scenarios, the more I realize the benefits of stateless HTTP frameworks like Hotwire, which feel more performant and resilient to reconnections, and avoid the need to place more servers close to users for stability.

[MatthiasPortzel]

When Stimulus/Turbo was first announced, I was really hoping it would help with the problems that the author describes.

Unfortunately, Stimulus doesn’t actually provide an elegant way to keep state on the client. “A stimulus application’s state lives as attributes in the DOM.” This means that it’s not better than vanilla JS or jQuery.

Edit: I haven’t used Stimulus for a real project; it’s possible their values and change callbacks are a better experience than I originally imagined.

[sph]

Yeah I use Stimulus and Live View together as well. It is the right level of complexity, while I feel Svelte deals with a lot of stuff which is not even an issue when paired with LV. All you need is vanilla JS or a thin layer on top of it, not an entire framework. You will not have to write a lot of JS after all.

My production app has no more than 200 lines of JS, and I could probably get rid of a couple Stimulus controllers. Live View is that good. I also made a very hacky Stimulus-Live View hook adapter, so my Stimulus controller can send events directly to the LV process.

EDIT: Live View does not require you to run geo-distributed servers at all, unless you have bought into the fly.io kool aid a little too much. And it deals with disconnections beautifully. I didn't even have to do anything to support zero-downtime updates. The client loses connection to the WebSocket and reconnects to the new version, restores the state, all that out of the box automatically. What more do you need?

[baskind]

I have the same view of an app implemented with Rails+Turbo and a duplicate in Elixir+LiveView.

Performance is comparable when I am close to the server (elixir is slightly faster), but when on another continent any content changes/navigation over websockets suddenly feel very laggy, while navigation over HTTP in the supposedly slower Ruby+Rails is actually consistently fast.

I’ve only recently discovered this as I went travelling to another continent, so will do more perf testing.

But the nature of the always-connected websockets hasn’t been a pleasurable one for me: for instance, a LiveView process crashes and you lose all the data in a big form, unless you write glue code for it to restore. And the experience of seeing the topbar getting stuck in the loading state the second your internet connection is spotty or if you are offline just gives me anxiety as a user.