That's my problem with this approach, I wonder what the penalty is (performance and complexity wise) for going that route. What is it using for websockets btw, Action Cable?
And that is a problem because by default Action Cable isn't scalable. You cant get it work by 100 - 200 connection and response time are very slow at 50ms+ and a lot higher at 95th percentile. AnyCable helps a lot but this is another pieces of complexity added to the system.
Not a problem for Elixir and BEAM when they are sort of built for these type of workload.
Although I am waiting for all the Fibre, Async and Ractor addition to Ruby 3 and see how they add fit in.
What is the added complexity? I honestly never used all this stuff.
The idea of chattily streaming UI changes over the network doesn't work out for mobile web, where networks are frequently unreliable if not totally inaccessible.
Or you are referring to Web Apps that work offline?
Many native mobile apps have these properties, and if mobile web apps want to compete they will have to as well.
In practice, that means generally minimizing network traffic, being smart about caching data, and providing soft failure modes.
Neither Liveview nor StimulusReflex are well suited to this problem space.
It’s a similar approach to Elixir’s Liveview and provides reactive, diff’d partial updates streamed over a websocket.
This seems a very “now” approach to building webapps.
1. https://docs.stimulusreflex.com/