Please, let me know if this kind of discussion already took place in another topic
.
Hi all, how do you consider if is better to build an app around SPA paradigm instead of use Server Side Rendering technologies.
I was thinking much about it and my first impressions is that familiarity with the stack has more weight than some objective criteria, given that a lot of apps can be developed with one or other approach, as we see with several apps in the wild.
Take for instance an app that I use everyday, Kanbanize. It is built around some server side rendering tech and it is awesome, but I know that some will tell that the UX is subpar, the same can be applied to Basecamp and Hey.
It’s get worse when you read the Twitter message from Chris, when they show that LiveView can exchange messages between frontend and backend more efficiently than a hand made SPA:
So what do you think about it, how do you decide when thinking about start a new project with limited resources, as a indie hacker’s project for instance.
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.
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.
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.
LiveView is simply an impossible pick when you need your application to be offline capable.
And it’s also possibly not a good fit, when you have a heterogeneous backend infrastructure. For example we have legacy services that are not really portable to Elixir. So we just keep them running and use their API from the client. This would be much more challenging using LiveView.
That being said, I think LiveView is nearly unbeatable when it comes to simplicity and iteration speed. The only thing that currently keeps me from using it for new projects is maturity: authentication and session management are not yet fully standardized/understood (for example), using large frontend libraries (like e. g. ProseMirror) is not really ergonomic and stuff like that. But I’m pretty sure that solving these issues is only a matter of time.
ProseMirror maintains it’s own internal state and rendering of that state. This is great, but in LiveView you now need some way of sending this state to the server. And since this internal state is relatively complex, you would probably not want to serialize the whole data model on every keyDown event and send it over the websocket.
That is not to say it is impossible, it is just not ergonomic and obvious in that you have to think about setting up a hook, think about when to send data to the server and think about reloading situations in which you may loose data.
In a single page application you typically have a local application state to begin with, so you have to deal with these problems from the start. That’s why you have established, well understood patterns on how to deal with these situations in SPAs. On the other hand: this extra layer makes everything much more complex and this is precisely why LiveView will typically be faster to develop with.
In summary: Depending on your situation, you cannot escape maintaining application state purely in the frontend. In these scenarios LiveView might, or might not, be a good pick for you and your team.
Our main focus is react at the moment, but ideally it will be a relatively thin wrapper around Phoenix Sockets + channels…
Here is a look at an early react hook API:
This is still limited to serializable values, but is a more ergonomic API for accessing server side state from frontend JS than what is required with the current version of live_view.
join us in the livedata slack channel if you’re interested in helping out!
The goal of this effort is a live_view(ssr) ↔ SPA middle ground… that lets elixir devs keep more state on the server, but still benefit from all the effort poured into the react/angular/vue(name your framework here) front end UI libraries.
Thanks @mmmrrr, this is very helpful context for me!
I really like Liveview and am currently working on pulling together / understanding the various puzzle pieces needed to make it a natural “go to”. I feel like I’m at the cusp of tremendous productivity/speed once it’s all in place. My core list includes the following at the moment:
Auth (as you also mentioned) & permissions (my focus will be on the built in auth generator, and maybe a library like canada).
More clarity around preserving a good user experience with rolling server restarts / server outages. I think most of the pieces are there, but I need to develop a better understanding for how to use them exactly.
A set of js helpers for latency-sensitive things like menu/modal open/close, tab switching, transitions, etc, like Alpine.js (but without the unsafe-eval concern currently in Alpine). I’m building this myself at the moment due to the mentioned security concern, certainly a good learning experience, but it is also slowing me down a bit. If Alpine addresses their issue, I would probably switch to that.
Thanks also to all the other posters in this thread, I have found this an exceedingly helpful discussion, and it has broadened my mind to think more openly about potentially having React (and its large ecosystem) in my toolset additionally (till now I was exclusively focused on Liveview).
Also, very helpful thoughts about APIs and mobile to be considered also, and the tradeoffs of not starting with an API. Interestingly, I’m finding that making tradeoffs is starting to become a core competency of a maturing software developer
Btw, for the Auth item that you’re looking to explore, Bruce Tate has a good video on using phx.gen.auth with LiveView, https://youtu.be/YlDO07P3oL0, around the 34 minute mark he specifically discusses how to go about using the tokens with liveview.
Early stage barriers to success on the web are typically time-based. You need to rapidly find the right solution that will draw customers/eyeballs. You need to be able to put features up quickly and iterate as rapidly as possible to find what will draw people in to your web application. You don’t want to spend inordinate time creating experiments that might fail while exploring your options.
To that end, LiveView will get you up and running as quickly as possible while allowing you to experiment to find what works for your business model.
Later, if you have a successful site that needs to scale, you might consider migrating to an SPA. But to give your ideas the best chance they have of finding footing in a marketplace, I don’t see how you could do better than to start with LiveView.
Interesting thread @marciol and some great replies too!
I am currently evaluating rebuilding Devtalk in Phoenix (including the forum) and the thought of using LiveView is very appealing - who wants the added complexity of a SPA, right? Your comment here got me a little worried though:
I tracked down what seems to be the source of such remarks (posted in a spin-off thread on DT here) since I was curious why people were being critical in the way that you mentioned. And I don’t necessarily think it’s because of the tech - rather more design choices made in those apps which is leading to people feeling this way.
For instance in HEY they have inconsistant layouts which make things feel a little jarring (such as when going from the email listing page to viewing an email - the header changes). Tbh, I don’t know whether they had a tight deadline (or just forgot that those with a trial account sees those changes more starkly) but it doesn’t feel as polished as what I would normally expect from DHH, so maybe it will evolve over time?
Either way I just wanted to say I’m not convinced it’s because of the tech, so I wouldn’t let those comments put you off - maybe build a prototype and see how you can make it feel? If you’re not a frontend dev, maybe use something like Tailwind too?
