Although both are “HTML over the wire”, LiveView is stateful and Hotwire (as well as React Server Components) are stateless.

This is an important distinction and there is a lot we could discuss under this subject but in a nutshell, stateful allows you to decrease latency because each request/event is immediately handled by the connected socket. On stateless, each request has to parse HTTP headers, do authentication, authorization, load data from the DB, etc.

LiveView builds on top of stateful connections to provide a more complete dev experience. Live form validation? Check. Dashboards? Check. File upload? Check. Drag and drop? Coming soon. This is also why people can build games with LiveView, even though it is not its purpose. The downside of stateful though is higher footprint cost on the server but that’s not fundamentally problematic in Elixir because connections are generally very cheap.

Back on the latency side of things, LiveView also does a lot to reduce the payload sent over the wire. When you update a page/frame/component, we only sent what changed. If you add new instances of a component and the component is already on the page, we send only the dynamic bits. React Server Components seem to do the same but I believe Hotwire does not.

We will have to wait for a bit to see how these differences will translate to programming models in the long term and how some ideas will cross-pollinate. You can always reproduce stateless with a stateful model though by discarding all state after every event.

Yeah, Strada was the part I was most curious about. My guess is the offline mode is managed by the frame-specific caches kept on the client (and not Strada). I expect Strada to rather allow you to replace some specific components/frames by native components (that would go alongside the webview). But I am guessing.

EDIT Feb/2024: since this message is still references from other places, I should add one important clarification. LiveView and Hotwire ultimately are two different programming models: LiveView is declarative, Hotwire is imperative. What this means is that, in LiveView, you don’t say “when someone clicks this, update this frame or render a stream to update this ID”. In LiveView, you simply change your LiveView state and LiveView re-renders the page. The declarative model requires less from the developer and it comes with the major benefit that, by letting LiveView be the one that does the rendering and patching, it can understand your code and apply a lot of optimizations.

Per the link above, Safari supports x-webkit-deflate-frame. If you search for x-webkit-deflate-frame on Cowboy repository, you will see it explicitly checks for this header, alongside permessage-deflate.

Compression happens within the VM by calling zlib:gzip/1, which is a C binding to zlib, the lib used by most systems and apparently Nginx too. I actually like that compression is handled in Elixir because the data is compressed from beginning to end.

Yes. Set compress: true option for your websocket configuration in the endpoint and you are good to go.

Note that LiveView will also do the static/dynamic and content tracking even on live_redirect. So data inside comprehensions or components is sent only once. So you are getting both LV optimizations and gzip.