mmmrrr

mmmrrr

This is a good point.

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.

4
Post #11
why

why

Hi @mmmrrr, could you help me understand the ergonomics concern a bit better? I haven’t worked with a library like this yet. Thank you!

0
Post #12
mmmrrr

mmmrrr

Sure, I’ll try!

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.

4
Post #13
harmon25

harmon25

This is something a few of us are working on actually…
Checkout @methyl s Todo POC demo: GitHub - surferseo/livedata_todomvc · GitHub

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:
https://github.com/surferseo/livedata_todomvc/blob/master/assets/js/containers/TodoList.js#L22-L26

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.

3
Post #14
why

why

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 :slightly_smiling_face:

1
Post #15
riebeekn

riebeekn

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.

5
Post #16
crusso

crusso

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.

12
Post #18
pedromtavares

pedromtavares

This is exactly what propelled Rails, and I do believe this is what will propel LiveView.

1
Post #19
AstonJ

AstonJ

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?

3
Post #20
cnck1387

cnck1387

Builtwith says Devtalk is built with Rails. Was there a reason Phoenix wasn’t used initially? Not necessarily LV but just Elixir / Phoenix in general.

Could have been a cool opportunity to build a real world app with Phoenix and even open source it. Sort of like what https://dev.to did (another similar site built with Rails).

2
Post #21