This is a very interesting topic and a question that all responsible engineers should ask themselves when deciding whether to go with LV. For sure I did ask it to myself many times. It’s even more important considering that LV is a highly promoted feature in Phoenix 1.5+, backed by a homepage redesign.

If the answer is “just return static HTML” then by itself it sounds like LV won’t scale well for these cases which is also not something we should state lightly. For sure, I wouldn’t treat this question as silly one and I wouldn’t underestimate the paradigm shift for many “oldschool web dev” that come with websockets and LV statefulness.

For the “viral blog” case there may be many scenarios when LV would still be applicable & profitable even for displaying static blog entries. This includes:

• rendering entire website via LV e.g. to reduce HTTP connection times
• rendering typical blog entry interactions e.g. like button with live counter
• rendering website-wide interactions e.g. notification or search popover in navbar

From my perspective it would be great to know up front if LV scales well (and how well) out of the box, what options are there for optimizing it (like caching) and if there are cases where it obviously won’t work due to scalability limitations. I guess what we really need is a comprehensive benchmark similar to the one about reaching 2 milion connections with single Phoenix instance. I’m not an expert at doing such benchmarks (esp. concerning websockets) but even without one we could just calculate the minimal memory footprint of a single active connection without extra assigns and use that to calculate the best case scenario “users per GB of RAM”. From then on it’d be all about understanding the cost of each assign and keeping that under control with temporary assigns etc - esp. in LVs that contribute to high-traffic pages.

In the end, we may always approach to LV as to “MVP supercharger” - a solution that allows to create dynamic websites at unprecedented pace but that always ends up converted to client-side/SPA code when the scale grows. But perhaps it doesn’t have to? With regular Phoenix, there’s a great chance that (depending of a case of course) you’ll hit DB scalability issues 10 times before you outgrow the webserver (like discussed e.g. here Scaling LiveView for low latency in multiple regions), but is that still the case with LV?

Yes, people have been creating all kinds of examples to see how far they could push it. There’s only one way to see where things break down and that’s to use it in anger. I consider that a good thing.

Personally I don’t agree with general statements like “never use it for user interaction”. Always and never are words I try to avoid. It’s all about context. Maybe you have an admin ui or very low latency connection where the trade-off is worth it and it’s good enough. Is saying that something is right or wrong without knowing the context any better than someone blindly following the hype?

All we can do is try to educate people so they can make an informed decision.

There are a few things I would pay particular attention to when thinking about using LiveView:

Do we need offline support?

Most likely the answer is no but if it’s yes then you can’t use LiveView.

What infrastructure is the application going to be running on in production?

How does it handle websockets?
Are there memory restrictions?
Are you running clustered or single instances?
…

Yes, LiveView will have limitations but the architectural limitations are just as important.

How will we deal with latency?

This one is extremely important and easy to forget if you only develop locally or with a high speed connection. Simple dynamic interactions like opening a dialog can suddenly become really jarring because of the latency involved. Alpinejs can help in that specific case but that means you might not be able to solve everything with LiveView alone if you want to have a great user experience.

How will we handle connection failures / application updates etc?

Because the state is on the server, how are you going to persist this state and load it back? The application might be updated, the server might crash. Anything can happen. What do you do then with forms that people are filling in at that exact time or things like that. This is of course not a LiveView specific problem but since it’s different from how most web applications work these days it’s wise to pay attention to it from the start.

Scaling LiveView would actually be the least of my worries. You should be doing load/performance tests specific to your application anyway. Hardly anyone is going from 100 users to 1.000.000 users overnight. And if you didn’t expect that load in the first place then most likely the rest of your architecture will fail before Elixir/Phoenix/LiveView does.

You mentioned high-traffic online newspapers and blogs. If the content is basically static I would do as much as possible with static html and just use a CDN to host it. Any framework would be overkill in that scenario. Maybe you want a personalized newsfeed. In that case the most likely bottleneck will be retreiving all the personal content on the backend so you just have to test it.

I don’t know what caching you’re worried about exactly. LiveView is for dynamic pages. This means you normally want to fetch the latest state once you mount again. That’s no different from Vue/React apps and such. If you want to avoid database calls you should use a caching layer in the backend itself.

What your system can handle will depend on the specific application and the complete infrastructure. That’s why I would say that LiveView itself must be dependable when you use it. It shouldn’t break suddenly. If you should use it depends on the situation.