5 ms·

How Phoenix LiveView Works

thibaut_barrere 5y ago
The previous episode is worth checking out at https://www.poeticoding.com/first-contact-with-phoenix-liveview/ https://www.poeticoding.com/first-contact-with-phoenix-livev...
- sfusato 5y ago
  The site is rich with resources on Elixir & Phoenix & LiveView. If you want an introduction to LiveView, I would say this is a very good starting point.
- Bayart 5y ago
  Thanks. I wanted to get into Phoenix, I'll go back a bit in the playlist.
atonse 5y ago
This is excellent, thank you for writing this. I’ve wanted to play with LiveView but haven’t had the time. But wanted to know exactly what’s happening (especially on “first paint”, others have written about the morphdom stuff) I really don’t see any reason why we can’t embed LiveView widgets into existing SPAs as a method of transition. Looking at this lifecycle it seems entirely possible. Also it would make an amazing framework for embedding widgets on third party sites. I know people say it has to be served from a fully rendered Phoenix page but I don’t see that limitation in any of the code. Excited to play around with it.
- thibaut_barrere 5y ago
  To clarify, I'm just the poster, not the author :-) I happen to have a very good time using LiveView in a number of scenarios, and found the article good enough to be shared.
mikl 5y ago
Great explanation. LiveView is such a life changer for building fast and interactive interfaces without having to build a separate client-side application.
bluewalt 5y ago
Maybe I'm missing something here (tell me), but after being initially amazed by the architectural concepts, I tried demos of a similar tool (https://docs.stimulusreflex.com/ https://docs.stimulusreflex.com/) and was eventually disappointed by the result. Why? Because the resulting UX is not comparable with a SPA at all. With a SPA, you instantly get a visual response when you click something (even if this response is a spinner) while with this kind of tool, there is a small bu weird delay (because of websockets) that makes the whole experience laggy, and pretty weird to me, especially after being used to SPAs. I totally understand that the balance between the tasks to achieve and the end result is very good, but this techno does not look like a replacement of SPAs to me.
- nlitened 5y ago
  I tried the demos (e.g. https://expo.stimulusreflex.com/demos/todo https://expo.stimulusreflex.com/demos/todo), and indeed they feel laggy. On the other hand, I think it is a failure of the UI, but not of the whole LiveView concept. UI elements could get an automatic visual indication of being "in progress" on the client side after being clicked, and I believe the feeling of lagginess should go away.
  - tluyben2 5y ago
    While I agree with that, I do not understand why this is quite so laggy. As we have different people here try and they all say it's laggy, irrespective of location (we are probably not all sitting in Portugal) and internet quality (maybe we all have slow internet though), there seems to be something wrong. But yes, add a spinner to indicate server communication and suddenly it'll look quite normal. SPA's that don't do that, with my connection, I often see the item appear but then get a server communication timeout after that which is, well, equal or worse to this.
    - jkmcf 5y ago
      It's a demo server? Go try Hey.com. Their email approach doesn't work for me, but the native app uses stimulus and it feels (felt? it's been a year) snappy.
alberth 5y ago
Is there any concerns to how LiveView will scale compared to just using “vanilla” Elixir/Phoenix?
- chrismccord 5y ago
  It will scale just as well as any other stateful application built with Phoenix, such as one using Phoenix Channels, which we've shown can scale to millions of simultaneous connections. LiveView allows you to mark which data you want to hold in memory, and which are only required for rendering and can be discarded for only storing what you need. That said, memory is going to be higher than a non-stateful application, with all the usual caveats of more HTTP overhead, server interaction overhead, DB pressure, and such so the increase in memory comes as savings in other areas. tldr; since we are built on top of the Phoenix channel primitive, it will have the same scaling characteristics. https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://www.phoenixframework.org/blog/the-road-to-2-million-...
Kaze404 5y ago
I really enjoy working with Phoenix and Elixir in general, but LiveView never clicked for me. I decided to give it a try on a relatively small project, and while it blew me away that it was easy and fast to build things, I find that the code I ended up writing is so messy and tangled that I don't really have the motivation to touch it anymore. This isn't necessarily an issue with LiveView in particular, but it's the only experience I've had with it.
- dnautics 5y ago
  no you're right, it takes an incredible amount of discipline to make pure LiveView code organized. I suspect Part of it is due to the "GenServers are dog's breakfast" problem that Dave Thomas complained about. I've settled on some patterns myself (https://www.youtube.com/watch?v=HA4h0cajgaA https://www.youtube.com/watch?v=HA4h0cajgaA), but I'm still not 100% on them. I wonder if frameworks like Surface ameliorate this problem.
  - auraham 5y ago
    Dave Thomas' post and talk about this. He 1) criticizes the overuse of GenServers, 2) the boilerplate code and large directory structures created by tools like mix and 3) gives a few ideas to deal with these issues. Amazing talk. https://pragdave.me/blog/2018/06/02/project-structure.html https://pragdave.me/blog/2018/06/02/project-structure.html
    - dnautics 5y ago
      Here is the talk, queued up: https://www.youtube.com/watch?v=6U7cLUygMeI&t=730s https://www.youtube.com/watch?v=6U7cLUygMeI&t=730s Yeah, I don't agree with everything he says -- I don't think boilerplate is necessarily bad. Especially in Elixir where It's hard to explain but usually it's easy to find the meat of what you care about -- your eye (or search cursor) just lands on it. And I also think specifically the solutions he proposes are not that great. Having a common language and not inventing too many more DSLs has value, even if it sucks a bit. But a lot of that shit needed to be brought up.
  - deleted 5y ago
victor106 5y ago
Phoenix is great and Liveview looks great. How is it different from reactive web views? Link below https://youtu.be/ewpJ9EUAz5s https://youtu.be/ewpJ9EUAz5s
yagudaev 5y ago
I’ve tried .Net Blazor, Stimulus Reflex and Phoenix Livewire. Blazor is by far the closest as it allows you to run Native client-side code and server-side code. The conceptual model didn’t work for me. Using client-side frameworks with json over the wire is a simple model. Ideally the server decides where things are rendered. These are important tech innovations, however the missing piece is still WASM. Being able to write the full-stack in one language. A step further WASM enables is interoperability between languages. Being able to call a Python ML lib client-side from your JS/Ruby/C# would be a game changer. Sadly, WASM for ruby and Python is not quite there yet.

The previous episode is worth checking out at https://www.poeticoding.com/first-contact-with-phoenix-liveview/ https://www.poeticoding.com/first-contact-with-phoenix-livev...

sfusato 5y ago
The site is rich with resources on Elixir & Phoenix & LiveView. If you want an introduction to LiveView, I would say this is a very good starting point.
Bayart 5y ago
Thanks. I wanted to get into Phoenix, I'll go back a bit in the playlist.

atonse 5y ago

This is excellent, thank you for writing this. I’ve wanted to play with LiveView but haven’t had the time. But wanted to know exactly what’s happening (especially on “first paint”, others have written about the morphdom stuff) I really don’t see any reason why we can’t embed LiveView widgets into existing SPAs as a method of transition. Looking at this lifecycle it seems entirely possible. Also it would make an amazing framework for embedding widgets on third party sites. I know people say it has to be served from a fully rendered Phoenix page but I don’t see that limitation in any of the code. Excited to play around with it.

thibaut_barrere 5y ago
To clarify, I'm just the poster, not the author :-) I happen to have a very good time using LiveView in a number of scenarios, and found the article good enough to be shared.

mikl 5y ago

Great explanation. LiveView is such a life changer for building fast and interactive interfaces without having to build a separate client-side application.

bluewalt 5y ago

Maybe I'm missing something here (tell me), but after being initially amazed by the architectural concepts, I tried demos of a similar tool (https://docs.stimulusreflex.com/ https://docs.stimulusreflex.com/) and was eventually disappointed by the result. Why? Because the resulting UX is not comparable with a SPA at all. With a SPA, you instantly get a visual response when you click something (even if this response is a spinner) while with this kind of tool, there is a small bu weird delay (because of websockets) that makes the whole experience laggy, and pretty weird to me, especially after being used to SPAs. I totally understand that the balance between the tasks to achieve and the end result is very good, but this techno does not look like a replacement of SPAs to me.

nlitened 5y ago
I tried the demos (e.g. https://expo.stimulusreflex.com/demos/todo https://expo.stimulusreflex.com/demos/todo), and indeed they feel laggy. On the other hand, I think it is a failure of the UI, but not of the whole LiveView concept. UI elements could get an automatic visual indication of being "in progress" on the client side after being clicked, and I believe the feeling of lagginess should go away.
- tluyben2 5y ago
  While I agree with that, I do not understand why this is quite so laggy. As we have different people here try and they all say it's laggy, irrespective of location (we are probably not all sitting in Portugal) and internet quality (maybe we all have slow internet though), there seems to be something wrong. But yes, add a spinner to indicate server communication and suddenly it'll look quite normal. SPA's that don't do that, with my connection, I often see the item appear but then get a server communication timeout after that which is, well, equal or worse to this.
  - jkmcf 5y ago
    It's a demo server? Go try Hey.com. Their email approach doesn't work for me, but the native app uses stimulus and it feels (felt? it's been a year) snappy.

alberth 5y ago

Is there any concerns to how LiveView will scale compared to just using “vanilla” Elixir/Phoenix?

chrismccord 5y ago
It will scale just as well as any other stateful application built with Phoenix, such as one using Phoenix Channels, which we've shown can scale to millions of simultaneous connections. LiveView allows you to mark which data you want to hold in memory, and which are only required for rendering and can be discarded for only storing what you need. That said, memory is going to be higher than a non-stateful application, with all the usual caveats of more HTTP overhead, server interaction overhead, DB pressure, and such so the increase in memory comes as savings in other areas. tldr; since we are built on top of the Phoenix channel primitive, it will have the same scaling characteristics. https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://www.phoenixframework.org/blog/the-road-to-2-million-...

Kaze404 5y ago

I really enjoy working with Phoenix and Elixir in general, but LiveView never clicked for me. I decided to give it a try on a relatively small project, and while it blew me away that it was easy and fast to build things, I find that the code I ended up writing is so messy and tangled that I don't really have the motivation to touch it anymore. This isn't necessarily an issue with LiveView in particular, but it's the only experience I've had with it.

dnautics 5y ago
no you're right, it takes an incredible amount of discipline to make pure LiveView code organized. I suspect Part of it is due to the "GenServers are dog's breakfast" problem that Dave Thomas complained about. I've settled on some patterns myself (https://www.youtube.com/watch?v=HA4h0cajgaA https://www.youtube.com/watch?v=HA4h0cajgaA), but I'm still not 100% on them. I wonder if frameworks like Surface ameliorate this problem.
- auraham 5y ago
  Dave Thomas' post and talk about this. He 1) criticizes the overuse of GenServers, 2) the boilerplate code and large directory structures created by tools like mix and 3) gives a few ideas to deal with these issues. Amazing talk. https://pragdave.me/blog/2018/06/02/project-structure.html https://pragdave.me/blog/2018/06/02/project-structure.html
  - dnautics 5y ago
    Here is the talk, queued up: https://www.youtube.com/watch?v=6U7cLUygMeI&t=730s https://www.youtube.com/watch?v=6U7cLUygMeI&t=730s Yeah, I don't agree with everything he says -- I don't think boilerplate is necessarily bad. Especially in Elixir where It's hard to explain but usually it's easy to find the meat of what you care about -- your eye (or search cursor) just lands on it. And I also think specifically the solutions he proposes are not that great. Having a common language and not inventing too many more DSLs has value, even if it sucks a bit. But a lot of that shit needed to be brought up.
- deleted 5y ago

victor106 5y ago

Phoenix is great and Liveview looks great. How is it different from reactive web views? Link below https://youtu.be/ewpJ9EUAz5s https://youtu.be/ewpJ9EUAz5s

yagudaev 5y ago

I’ve tried .Net Blazor, Stimulus Reflex and Phoenix Livewire. Blazor is by far the closest as it allows you to run Native client-side code and server-side code. The conceptual model didn’t work for me. Using client-side frameworks with json over the wire is a simple model. Ideally the server decides where things are rendered. These are important tech innovations, however the missing piece is still WASM. Being able to write the full-stack in one language. A step further WASM enables is interoperability between languages. Being able to call a Python ML lib client-side from your JS/Ruby/C# would be a game changer. Sadly, WASM for ruby and Python is not quite there yet.