6 ms·

We are really excited about this release! I also wanted the screencast to be a single take, so I'm happy to answer questions if there are gaps to fill in for th

We are really excited about this release! I also wanted the screencast to be a single take, so I'm happy to answer questions if there are gaps to fill in for things I could have explained more clearly.

rglover 6y ago
Thanks for putting this together, Chris :)
sertyrion 6y ago
Great work! I think the phoenix framework project really recognizes the power of "Defaults". Defaults for dev, user interaction, server, and client. Make useful things quick but also learn how and why they are chosen.
thebigshane 6y ago
First of all, great demo, and great showcase for this technology. I think it did a great job of showing its strengths to traditionally backend developers like me. I also appreciated the twitter analogy. I just couldn't help but think "Wait, Twitter doesn't have 'Update/Edit Post'!" :) I've heard that Blazor in the .net world has similar goals to LiveView, but I haven't gotten into it much. Can anyone confirm?
- zeroc8 6y ago
  Yes, there are two Blazor variants. Serverside Blazor is basically the same thing as Phoenix Live View, client side Blazor is providing some optimized Mono runtime as webassembly.
  - dnautics 6y ago
    From an empty repo, how many minutes do you think it would take one to do what Chris McCord did in Phoenix Live View in Blazor?
    - zeroc8 6y ago
      I have no idea. Probably longer. But it is the same idea. The big gains come from going back to the simpler server side programming model. I'm working on a big Angular application right now for which something like Live View would be the ideal fit. That said, a switch to Elixir would be a very hard sell in my company. Blazor would be easier because it's .NET.
      - dnautics 6y ago
        I also don't know enough about c#, to comment on this being a risk for blazor but having the BEAM's process isolation is absolutely critical to minimizing programmer error from turning into a let's say a DOS attack risk, or possibly worse. I worry that all these other platforms rushing to emulate liveview are missing that extremely critical component of this model. If you aren't certain about what I mean, I suggest watching Sasa juric's "the soul of erlang and Elixir" video where forward progress of the system is unimpeded by a panic or a process that attempts to hog processing via an infinite loop, both are detectable in the running system, and able to be easily identified (down to the malfunctioning function name) in the in-prod system.
Scarbutt 6y ago
You are running this on localhost but won't interactions be slow if a user is 200ms from the server? Re-rendering templates every time on things that require high interaction also seems very expensive and an easy way to slow down your server when you have multiple users correct? or what I'm missing?
- chrismccord 6y ago
  you are correct, you can't escape the laws of physics latency wise, but most web things we are all building, including 100% JavaScript apps require a round trip to the server. For example I can't post tweet without a round trip to twitter. On the LiveView side UX wise, we apply css loading states to the interacted elements, so the user is provided feedback while awaiting an acknowledgement. On the server, our templates are precompiled and do change tracking. So we only execute the elixir code that is necessary to render the parts of the template that changed. The rest of the calls are noops. From the top down, it appears like an extremely heavy approach, but with our change tracking and diffing, it's actually incredibly optimized. Also note the Erlang VM was made to handle multiple users, as we showed in our "The road to 2M connections with Phoenix" blog post a couple years ago. More connected users will mean more memory, but Memory is cheap, and the platform scales well enough that opening a websocket on all pages as a matter of course is completely viable. Hope that helps!
  - chrismccord 6y ago
    I also forgot to mention we provide optimistic UI features with our loading states and annotations. For example, in the screencast, the "Save" button has phx-disable-with="Saving...", which applies on client instantly and stays until an ack is received. You can leverage the loading states as well to toggle entire containers for a happy medium between traditional optimistic and instant user feedback.
- josevalim 6y ago
  LiveView does not re-render the template on every interaction. LiveView actually sends patches over the wire, which is typically smaller than a hand-written JSON response. The screencast linked above has a good example of this, where clicking the "retweet" button sends a minimal payload, since we know the exact position on the page. LiveView also uses a long-running WebSocket connection and that reduces the amount of data sent over the wire compared to regular requests/responses, as you don't need to encode headers, cookies, etc. Finally, if you are worried about latency, you can call "liveView.enableLatencySim(200)" in your browser console, and you will be able to emulate how your application behaves over high latencies.
miki123211 6y ago
Any hope of getting this as a text article, or even a git repo? Blind user here who can't see code embedded in a video, but can read ascii-text with a screen-reader perfectly fine. People who don't enjoy videos for various reasons would probably like a text version too.
- thex10 6y ago
  > People who don't enjoy videos for various reasons would probably like a text version too. Yes this. I went to the video eagerly looking for a repo link and was disappointed not to find one.
- anw 6y ago
  Hi miki123211, I wrote up a transcription for you. It details the code he's talking about, along with the context of what's going on, and why. https://pastebin.com/raw/WxH0uAsf https://pastebin.com/raw/WxH0uAsf If Pastebin doesn't work for you, let me know and I can get it hosted at a different location. My apologies if there are any mistakes in this. I'm not familiar with Phoenix, but found this video very interesting, so wanted to make sure it could be shared.
  - miki123211 6y ago
    Thanks, that works. The raw link is perfect for accessibility, as there's no garbage on the page.
  - praveenperera 6y ago
    Thank you for doing that, good job!
sdwolfz 6y ago
I'm really amazed this sort of functionality can be implemented in such a nice and clean manner. Your presentation is mind blowing! Just out of curiosity (please don't consider this as a feature request, more like a thought exercise), in case you wanted the application to have offline editing functionality, could the framework provide it in a similar manner? having a generic JS handler that manages pushing state when an internet connection is available again and exposing hooks that you can implement to handle data consistency? Of course in this case the data payload passed through sockets would be bigger as you would need some identifiers to make sure for example increments don't get duplicated, and there could potentially be different strategies for solving data conflicts (CRDTs for example). But would it need extra back-end support for this or would it be enough to have engineers manage state through the current handlers?
- chrismccord 6y ago
  "offline support" is strictly on the side of needing to run a lot of code on the client, so this is where we draw a line and say you need a js framework, of which there are number of great options. We have javascript interop via phx-hook, so it could be made to work, but you'd necessarily have to have a lot of js running on the client, and any feature you wanted to work online & offline would not share a code path or need js, thus client side rendering and templating gets involved and suddenly we're writing a SPA. If we're strictly talking allowing the edit of a textual input and syncing on reconnect, it would be straight forward to do with LV and some small js hooks, but the moment you start adding offline UI features you'll need a js library. The funny thing is last I tried to use Google Docs offline, it locked the page in read-only mode, so offline mode even in the SPA space isn't just a given – you're definitely opting in to some necessary complexity.
  - sdwolfz 6y ago
    Sounds fair, thank you for your reply!
mangoman 6y ago
Congrats on the launch! I've been following this for a while and played around with it a bit, I'm excited to get my hands dirty with this. How does reconnection work? lets say someone is using the site, and you do a deployment, rolling the nodes over. Does live view simply reconnect to another node without any interruption from the user's perspective?
- chrismccord 6y ago
  Confirm. LiveView will apply css loading state classes, which are user defined, but we generated css by default in new apps to lock the UI with loading cursor, and show a top loading bar. On reconnect, which happens automatically, we rematch the DOM with any changes, and we also send up any user form input beforehand so client state is lost that was in progress. We already have reports of users pushing bugs to their systems and the UI seemingly being unaffected because the LiveViews automatically recover, wether from a disconnect or a crash on the server.
- deleted 6y ago
  [deleted]
AlchemistCamp 6y ago
How stable do you expect LiveView's API will be going forward? I'm especially invested in this since I've just rolled out an alpha of a project that may incorporate it in the future: https://phoenixigniter.com https://phoenixigniter.com
- chrismccord 6y ago
  As always, I can make no guarantees before 1.0, but we have really focused on refining the programming model and APIs for the last several months, so we're in a good state currently.
  - deleted 6y ago
    [deleted]
andruby 6y ago
Hi Chris. I built a demo with LiveView a year ago and am very happy to see all the improvements. One thing I didn't understand from the video is how the :post_updated callback worked. It prepends the updated post to the list of posts. How come that doesn't lead to the same post being double in the list?
- josevalim 6y ago
  Components IDs are unique. So once you try to render the same component, we know you simply want to update the current one. The same happens on the client. If the server emits the same DOM ID, the client just updates it in place too.
nickjj 6y ago
Hey Chris, do you have any plans in the very near future to update the example LV repo to use all of the goodies in LV 0.12+ and Phoenix 1.5+ and perhaps even add more examples?

rglover 6y ago

Thanks for putting this together, Chris :)

sertyrion 6y ago

Great work! I think the phoenix framework project really recognizes the power of "Defaults". Defaults for dev, user interaction, server, and client. Make useful things quick but also learn how and why they are chosen.

thebigshane 6y ago

First of all, great demo, and great showcase for this technology. I think it did a great job of showing its strengths to traditionally backend developers like me. I also appreciated the twitter analogy. I just couldn't help but think "Wait, Twitter doesn't have 'Update/Edit Post'!" :) I've heard that Blazor in the .net world has similar goals to LiveView, but I haven't gotten into it much. Can anyone confirm?

zeroc8 6y ago
Yes, there are two Blazor variants. Serverside Blazor is basically the same thing as Phoenix Live View, client side Blazor is providing some optimized Mono runtime as webassembly.
- dnautics 6y ago
  From an empty repo, how many minutes do you think it would take one to do what Chris McCord did in Phoenix Live View in Blazor?
  - zeroc8 6y ago
    I have no idea. Probably longer. But it is the same idea. The big gains come from going back to the simpler server side programming model. I'm working on a big Angular application right now for which something like Live View would be the ideal fit. That said, a switch to Elixir would be a very hard sell in my company. Blazor would be easier because it's .NET.
    - dnautics 6y ago
      I also don't know enough about c#, to comment on this being a risk for blazor but having the BEAM's process isolation is absolutely critical to minimizing programmer error from turning into a let's say a DOS attack risk, or possibly worse. I worry that all these other platforms rushing to emulate liveview are missing that extremely critical component of this model. If you aren't certain about what I mean, I suggest watching Sasa juric's "the soul of erlang and Elixir" video where forward progress of the system is unimpeded by a panic or a process that attempts to hog processing via an infinite loop, both are detectable in the running system, and able to be easily identified (down to the malfunctioning function name) in the in-prod system.

Scarbutt 6y ago

You are running this on localhost but won't interactions be slow if a user is 200ms from the server? Re-rendering templates every time on things that require high interaction also seems very expensive and an easy way to slow down your server when you have multiple users correct? or what I'm missing?

chrismccord 6y ago
you are correct, you can't escape the laws of physics latency wise, but most web things we are all building, including 100% JavaScript apps require a round trip to the server. For example I can't post tweet without a round trip to twitter. On the LiveView side UX wise, we apply css loading states to the interacted elements, so the user is provided feedback while awaiting an acknowledgement. On the server, our templates are precompiled and do change tracking. So we only execute the elixir code that is necessary to render the parts of the template that changed. The rest of the calls are noops. From the top down, it appears like an extremely heavy approach, but with our change tracking and diffing, it's actually incredibly optimized. Also note the Erlang VM was made to handle multiple users, as we showed in our "The road to 2M connections with Phoenix" blog post a couple years ago. More connected users will mean more memory, but Memory is cheap, and the platform scales well enough that opening a websocket on all pages as a matter of course is completely viable. Hope that helps!
- chrismccord 6y ago
  I also forgot to mention we provide optimistic UI features with our loading states and annotations. For example, in the screencast, the "Save" button has phx-disable-with="Saving...", which applies on client instantly and stays until an ack is received. You can leverage the loading states as well to toggle entire containers for a happy medium between traditional optimistic and instant user feedback.
josevalim 6y ago
LiveView does not re-render the template on every interaction. LiveView actually sends patches over the wire, which is typically smaller than a hand-written JSON response. The screencast linked above has a good example of this, where clicking the "retweet" button sends a minimal payload, since we know the exact position on the page. LiveView also uses a long-running WebSocket connection and that reduces the amount of data sent over the wire compared to regular requests/responses, as you don't need to encode headers, cookies, etc. Finally, if you are worried about latency, you can call "liveView.enableLatencySim(200)" in your browser console, and you will be able to emulate how your application behaves over high latencies.

miki123211 6y ago

Any hope of getting this as a text article, or even a git repo? Blind user here who can't see code embedded in a video, but can read ascii-text with a screen-reader perfectly fine. People who don't enjoy videos for various reasons would probably like a text version too.

thex10 6y ago
> People who don't enjoy videos for various reasons would probably like a text version too. Yes this. I went to the video eagerly looking for a repo link and was disappointed not to find one.
anw 6y ago
Hi miki123211, I wrote up a transcription for you. It details the code he's talking about, along with the context of what's going on, and why. https://pastebin.com/raw/WxH0uAsf https://pastebin.com/raw/WxH0uAsf If Pastebin doesn't work for you, let me know and I can get it hosted at a different location. My apologies if there are any mistakes in this. I'm not familiar with Phoenix, but found this video very interesting, so wanted to make sure it could be shared.
- miki123211 6y ago
  Thanks, that works. The raw link is perfect for accessibility, as there's no garbage on the page.
- praveenperera 6y ago
  Thank you for doing that, good job!

sdwolfz 6y ago

I'm really amazed this sort of functionality can be implemented in such a nice and clean manner. Your presentation is mind blowing! Just out of curiosity (please don't consider this as a feature request, more like a thought exercise), in case you wanted the application to have offline editing functionality, could the framework provide it in a similar manner? having a generic JS handler that manages pushing state when an internet connection is available again and exposing hooks that you can implement to handle data consistency? Of course in this case the data payload passed through sockets would be bigger as you would need some identifiers to make sure for example increments don't get duplicated, and there could potentially be different strategies for solving data conflicts (CRDTs for example). But would it need extra back-end support for this or would it be enough to have engineers manage state through the current handlers?

chrismccord 6y ago
"offline support" is strictly on the side of needing to run a lot of code on the client, so this is where we draw a line and say you need a js framework, of which there are number of great options. We have javascript interop via phx-hook, so it could be made to work, but you'd necessarily have to have a lot of js running on the client, and any feature you wanted to work online & offline would not share a code path or need js, thus client side rendering and templating gets involved and suddenly we're writing a SPA. If we're strictly talking allowing the edit of a textual input and syncing on reconnect, it would be straight forward to do with LV and some small js hooks, but the moment you start adding offline UI features you'll need a js library. The funny thing is last I tried to use Google Docs offline, it locked the page in read-only mode, so offline mode even in the SPA space isn't just a given – you're definitely opting in to some necessary complexity.
- sdwolfz 6y ago
  Sounds fair, thank you for your reply!

mangoman 6y ago

Congrats on the launch! I've been following this for a while and played around with it a bit, I'm excited to get my hands dirty with this. How does reconnection work? lets say someone is using the site, and you do a deployment, rolling the nodes over. Does live view simply reconnect to another node without any interruption from the user's perspective?

chrismccord 6y ago
Confirm. LiveView will apply css loading state classes, which are user defined, but we generated css by default in new apps to lock the UI with loading cursor, and show a top loading bar. On reconnect, which happens automatically, we rematch the DOM with any changes, and we also send up any user form input beforehand so client state is lost that was in progress. We already have reports of users pushing bugs to their systems and the UI seemingly being unaffected because the LiveViews automatically recover, wether from a disconnect or a crash on the server.
deleted 6y ago
[deleted]

AlchemistCamp 6y ago

How stable do you expect LiveView's API will be going forward? I'm especially invested in this since I've just rolled out an alpha of a project that may incorporate it in the future: https://phoenixigniter.com https://phoenixigniter.com

chrismccord 6y ago
As always, I can make no guarantees before 1.0, but we have really focused on refining the programming model and APIs for the last several months, so we're in a good state currently.
- deleted 6y ago
  [deleted]

andruby 6y ago

Hi Chris. I built a demo with LiveView a year ago and am very happy to see all the improvements. One thing I didn't understand from the video is how the :post_updated callback worked. It prepends the updated post to the list of posts. How come that doesn't lead to the same post being double in the list?

josevalim 6y ago
Components IDs are unique. So once you try to render the same component, we know you simply want to update the current one. The same happens on the client. If the server emits the same DOM ID, the client just updates it in place too.

nickjj 6y ago

Hey Chris, do you have any plans in the very near future to update the example LV repo to use all of the goodies in LV 0.12+ and Phoenix 1.5+ and perhaps even add more examples?