Especially if you are an indie hacker, I would go with LiveView over a SPA, because it would simply allow for faster iteration on the front end and would likely significantly speed up the time to releasing production ready code. However, those benefits would only really apply if the people working on the project were capable of picking up LiveView, and they probably are. Also, there are very few web apps that cannot be implemented in LiveView, and to the point of an app being ugly it would not be due to it being a SPA or not, but rather one’s ability to write CSS.

LiveView should be the default choice for most new Phoenix projects. Unless you’re doing some very intense UX work that requires constant realtime interactions as a core part of your project, LiveView will suffice. Even if your project needs instant feedback for isolated features, you can still get away with using Hooks. So yeah, for 99% of the cases, LiveView is viable and recommended.

In the example Chris created a basic twitter clone, but that makes me wonder… Is liveview a good choice for something like twitter? or in general a social network?

That makes me wonder exactly what are the use cases that liveview does not fit in

One thing that LiveView would not work in would be something like Google Docs, or just in general desktop-like apps that are just using the browser as a type of extremely portable runtime.

oh that makes sense!

But getting back to the example of twitter for instance, social networks are quite big apps, could it be a good fit then? Taking into account all the interactions that came with it, sure the realtime side of liveview could be amazing but I’m not sure about the UX itself

I don’t see why not. Twitter has a lot of interaction but not really that heavy on the UI/UX like for example a game. Most animation you should use CSS anyway and not dependent on LiveView.

well, many of this kind of conversation divert from a important topics: maintenability, code organization, tooling, etc.

You could have the same benefits of LiveView using WebSockets (even with something more advanced like GraphQL subscriptions) and thats not related of being a SPA or SSR.

With that said, I guess you should first pick SSR vs SPA for a given project, and there’s the pros and cons for each pick, and then, only then, analyze if you should use liveview or not.

Also, there’s a lot of CSS-in-JS nowadays, so you could also “avoid” writing CSS if that’s the reason why you pick LiveView.

For example, you can do it with react in a SPA application, or even in a SSR application with nuxt.js

Twitter has indeed some degree of complexity in the timeline UI. With infinite scrolling, it has to keep potentially hundreds and hundreds of tweets in memory and only show a couple of them to avoid performance issues(similar to what Discourse does, except discord “cloaks” comments and twitter removes them and compensates the height differences). All of this while the user scrolls, and without messing the scroll position when hiding/showing tweets.

This is quite critical for this kind of ui’s performance and I’m not sure how it would be solved purely with LiveView, but definitely doable with hooks.

For me personally, I almost exclusively use Phoenix for APIs only. When I need this realtime updates stuff, I use GraphQL subscriptions.

As a fullstack developer that sometimes hire some frontenders to help building interfaces, it’s way more organized and flexible. With an API built, you dont need to share your business-backend code with frontend code directly. It also gives you a quick way of building mobile apps, external integrations, or even a complete rework of your web interface easily.

Of course one of this frontends can be a phoenix app, integrating with a backend app which is also an API, but I see little value there. At least not without using a JS framework anyway. You can SSR in phoenix with react, for example. But I’d still split the codebase in many scenarios.