Right, good call on that. I had glanced at something like 9 hours ago thinking there was only 1 endpoint in the Rails example I looked at and now looking back I see there’s multiple ones like you described.
I’ll leave my original comment there so the discussion makes sense.
That’s not quite what I am referring to. I am rather referring to the same frame being instantiated multiple times. For example, take each message in a chat app. In an actual app each message has a lot of markup around it. How do make sure you send only the actual message and not all of the markup multiple times? This is what a SPA would give you - which is the standard LV is typically being held at - and also what LV and React Server Components give.
Or building on your tweets example. On Twitter UI, you almost never load tweets one by one. You either: load a page with a bunch of tweets or you click the “Show latest 10 tweets” banner. In both cases, you’d send the markup of each tweet multiple times with Hotwire.
And HTTP caching is not something that will help you here either. That’s because:
The request either has a bunch of tweets (the whole page or the next 10 tweets) - a combination unlikely to repeat over a request again
You will cache each individual tweet. But if you are caching it with HTTP, then it means you need to do an individual request to load each tweet and if clicking “Show latest 10 tweets” translates into 10 HTTP requests, that’s going to be way too expensive.
EDIT: to take yet another example: live form validation. You won’t benefit from HTTP caching at all as you receive feedback - so if you don’t want to send the whole form over and over again as the user types in or blurs an input, sending only the dynamic parts is essential. And I think that will generally hold for anything interactive/realtime.
With all the HTTP headers and auth per request, it probably will not make much difference anyway. I’d say just send the markup. I agree that in the applications you cited, like chat, twitter or live form validation LV is the better choice. For applications that is not so real time, such as Hey.com, basecamp, or this forum, it could make a lot of sense.
From what I gathered, your frame would be the list of messages and they would be listed out as if it were an HTML response from the server without anything extra going on. If you had 5 messages that would mean having 5 messages each with their own HTML tags associated to them.
It’s not as sophisticated as merging in dynamic content into the static parts of a template like LV does. But we’re also dealing with a day 1 release. Who knows what will happen later.
I’m not too concerned about identical HTML being duplicated because gzip is remarkably efficient to the point where you almost can’t believe how well it can reduce lots of repeated text down into a few characters.
In this twitter example sure, but in a lot of apps I could see cache hits being the norm. Such as a list of lessons in a table of contents, forum threads in a non-super busy forum, the 5 latest blog posts, etc.. Basically what @derek-zhou said.
If you haven’t watched it already, the last ~3 minutes of DHH’s demo video gives a glimpse at how these patterns are applied to Hey. It looked like lots of opportunities for cache hits and it shows when they situationally bring in websockets (Turbo Streams) to offer soft real-time broadcasted updates.
That’s precisely my point. I didn’t bother about HTTP caching rendered content on any Phoenix app I wrote because:
They all felt fast naturally
Rails default HTTP caching - the one used in the video - is the digest of the HTTP response. This means you still do all work on the server, the database, and in rendering a response. So if a response is slow to render in the first place, the cache won’t really help you, as the only part it skips is the sending of the data
Compression, turbolinks, live links, and others reduce the content size anyway
Small bits of interactivity that we add, such as flash messages, makes HTTP caching generally difficult
You can implement more efficient HTTP caching by writing custom code but given points 1, 3 and 4, I would rather put the development effort elsewhere. If I have to cache, I would do it within the app as it provides more granularity.
On the other hand, live form validation is something I would have used on every app that I have built in my entire life - and without content diffing it isn’t really practical. So to me, when it comes to practice, we are talking about a feature with marginal benefits vs a must have.
EDIT: of course, HTTP caching is still great for static assets and places where you can compute digests upfront (without doing the work).
You are right. I did some tests to see how efficient it is and gzip pretty much removes all of the duplicated content. So when you are sending the same content multiple times in the same payload - it covers it. This is great to know because the dead render in LV does not remove duplicated content and I was wondering how to address it. But apparently I don’t have to worry about it at all.
There is still one case left: when you are streaming messages one by one, such as in chat, you would be sending the same markup every time there is a new message. As they are distinct payloads, gzip won’t help. And there is no HTTP caching here either unless you load each individual message with a separate request.
So to sum up my thoughts so far:
I can be convinced that 4 is a nice to have - although it is a requirement if you want to compete with SPAs - but 1 and 3 are must haves. I am not giving up on my hard earned live form validations and general interactivity. 
On a related note can you even gzip websocket transmissions? I don’t think it’s supported yet by browsers, and I can’t find any docs on nginx’s site about it
Just asking because if you use LV for everything to benefit from page transitions like turbolinks then aren’t you technically sending a very large amount of HTML over a websocket connection that won’t be gzipped?
Use case:
You have a list of blog posts and everything within the main page content results in having 80kb of HTML.
You click a specific blog post and transition to a blog show page with 100kb of HTML to show the blog post itself.
You do that navigation with live_redirect to benefit from keeping the <head> along with some of the nav bar and maybe footer around in the DOM so only the main page content changes.
I know diff tracking is great for things like validation where only a tiny bit of text changes, in which case gzip isn’t super important but for nearly full page transitions you’re dealing with tens, or possibly even hundreds of kb of HTML that can’t be gzipped.
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.
Using liveview for a blog is probably not so smart. On the other hand, liveview and turbo can work side by side:
All on the same page. That will be sweet.
Does that mean both gzipping and unzipping happens in Elixir code instead of nginx or another reverse proxy? Is it implemented in a way that supports all LV supported browsers? It looks like there’s been a bunch of different headers that various browsers expect. With HTTP this is something that nginx would usually handle.
As recent as 2020, it looks like maybe Safari doesn’t support the official spec based on comments in https://stackoverflow.com/a/45561784.
That opens a can of worms of needing to drag in both JS libs and have them play nice together. The trade off there are increasing your bundle size and also increasing the complexity. I’ve also seen Chris and others say to LV all the things (in the context of creating an app where it makes sense, like not needing offline support, etc.).