MVC vs LiveView

This seems like a strange question, assuming you mean Model/View/Controller, since the latter is a general pattern for building software and LiveView is a very specific framework for rendering HTML server-side. The default Phoenix code structure already encourages a sort of MVC structure by encouraging you to keep business logic (Model) in contexts, and providing a template system so you can keep your mark up (View) separate from your event handlers (Controller). So really it’s only left to us as Phoenix LiveView users to try and respect the boundaries the framework has already put in place, and not put functions that generate HTML in contexts, or general business logic in specific live views, etc…

If you provide some more specific examples of things you’re confused about, maybe we can give you more specific pointers.

Thanks for the explanation.

I follow “Phoenix LiveView Pro” from The Pragmatic Studio. As far as I know, now I’m using LiveView for all stuff. They mentioned that there is a possibility to use LiveView only when it’s necessary using live_render() (I assume that I should use traditional MVC instead of LiveView and live macros). Which approach is better or when to use them? Please correct me if I’m wrong.

It depends.

I assume when you say MVC you mean something along the lines of the stateless HTTP request-response type of web. Plain old Phoenix gives you that. You click something, send a request to the server and it loads a new page.

LiveView maintains a connection between the server and the client over WebSockets. This allows the server to push events to the client. There are other things that you get with LiveView but this is the core difference.

After years of “JS all the things!” there has been some backlash and now people are starting to realize that the dev resources required to create and maintain complex SPA type software may not always be worth it. So many people are returning to standard server rendered HTML and injecting JS only where they need it for truly dynamic features. live_render makes it easy to do that, but to use LV instead of JS for those features. So as @cmo says there’s no general rule for which is “better,” rather you first have to describe what kind of app you want to build. If you are building a SPA you probably won’t need it because every view will already by a LV.

Based on the original question, with Phoenix, if you are following their patterns, you are already building with models and views. As @cmo mentioned, the C part of MVC is controllers, if you are using LiveViews you will have a live folder rather than a controllers folder. I’m not sure it’s harmful to think of them as being drastically different, the live folder will act as a sort of controller for data from the model and pass it to the view.

This is of course an over simplification but I think in theory it’s a good way to think of things.

As @cmo mentioned using controllers vs LiveView absolutely depends but you are not wedded to either one, you can create a controller for some pages that will have traditional HTTP request-responses and frontend JavaScript and LiveView for dynamic pages where you want to push data to and from the client without a page refresh. Personally, I find working with traditional HTTP request-responses tends to get pretty limited if I’m trying to build an interactive user experience so I tend to stick with LiveView as a default but it’s conditional on what the page is.

My only advice is don’t blend static view and LiveView until you are very comfortable with both of them. Limit your choice first; if the problem space is too vast you can easily get lost exploring.

Thank you guys for all replies.
I’ll try both ways in that case.

This is very helpful, I’ve been battling with how to make the connection between liveview and controllers, makes sense that the “live” folder is the “controllers” folder. If this concept is true, this just unstuck me for a while.

Yeah, it’s a useful analogy for sure, but it’s good to know it’s not a perfect one.

For example, a key difference is that stateless HTTP requests pass through plugs before reaching Controller actions whereas LiveView events sent within stateful connections do not pass through plugs before reaching LiveView callbacks. And this distinction introduces some important security considerations for the LiveView model around authentication and authorization.