4 ms·

I think very highly of elixir and Jose. After 3 months of using .NET Blazor in production, I can say that LiveView and Blazor have some trade offs that people d

by elamje 7y ago

I think very highly of elixir and Jose. After 3 months of using .NET Blazor in production, I can say that LiveView and Blazor have some trade offs that people don’t talk about. For those that don’t know what they are, they basically keep a websocket connection open between the client and server to allow the client to call Elixir and C# functions instead of javascript frameworks that call some rest api endpoint. You can write HTML click listeners that are in the server language rather than js. It’s powerful, but there is a latency trade off since most UI events end up being handled by the server, the client might notice this latency in the UI. Blazor specifically has issues with connectivity, which means your client is completely locked out of the UI until a manual refresh. It’s true that this is certainly a paradigm shift, and maybe just a stepping stone to web assembly web apps written in a server language. I haven’t used LiveView, but I can imagine it’s better than .NET at scaling since it runs on BEAM rather than the CLR, which means it’s likely the better choice if you will need to maintain a lot of client connections in your app.

abrookewood 7y ago
A lot of these trade-offs are clearly explained in a Stack Overflow Blog post [0]. The issue of latency is highlighted as a key issue, as is increased server load and no offline support. I would assume these also apply to LiveView. Still, the both sound appealing in that you can do everything in a single language. https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-about-blazor/ https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-...
elcritch 7y ago
Haven’t tried Blazor, but LiveView’s haven’t had too noticeable of a lag for me even doing basic UI stuff on a server. I wonder if .NET has a higher latency response times on average? Elixir/BEAM seem to consistently provide < 10 ms response times. Given a 30-60ms ping, that’s still provide a round trip of < 120 ms. Barely noticeable for many cases. Still for people with bad internet latencies either tech stack would be frustrating... I’d guess that most any web service for less than, say, 10k total users LV would be fine. Given a user base that size or smaller, the productivity tradeoffs outweigh most user inconvenience. As in, I can make a SaaS/SPA to serve a small market significantly quicker than using a bifurcated server/js-frontend. Especially if the SPA requires or benefits from live streaming updates (graphs, dashboards, stats apps, etc). No contest in my opinion, except for maybe a Clojure stack (?).
fahrradflucht 7y ago
What I don't understand with these technologies, is how you do continuous deployment without breaking all running client sessions evertime.
- dnsbty 7y ago
  With Erlang releases (compiled code with the Erlang runtime included) you can do hot code swapping to change the code while it’s still running. And iirc I believe LiveView will have all the state necessary client-side to be able to reconstruct the session when reconnecting the socket. I’m not near my development machine to make sure on that one though.
  - out_of_protocol 7y ago
    As far as i know it doesn't work this way (session restoration) as of now. Something could be done but requires a lot of effort
  - te_chris 7y ago
    We store our sessions in Redis and don't do hot code swapping but deploys do still mostly just work and live channels normally reconnect without any noticeable downtime. We run everything on GKE so a deploy is just rolling container swaps. Liveview is built on top of channels, so worth reading up about them: https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html
- machiaweliczny 7y ago
  I was just storing session state in Redis
- josevalim 7y ago
  LiveView does two things in particular: 1. It includes live navigation, which updates the URL as you interact with the app. For example, if you try the live scaffold generator in Phoenix v1.5.0-rc.0, you will see that once you click the "New Post" modal, the URL changes to "/posts/new". So if users reconnect by any reason (poor connection, new deployment, etc), they will go back to the same page with the same modal. 2. For forms, we automatically submit the current form state on reconnections, allowing the server and client to sync up. For complex applications, think a chat app or a game, then you have to persist messages, the game state, and what not on the server. But that would be necessary regardless if you are using LiveView or not.
conradfr 7y ago
I made a stupid game as LiveView POC [1] which I posted the other day and tested it on different conditions and can comment a bit on the latency. On a LAN you really don't feel it 99% of the time. However in the game I have a countdown that I initially updated each seconds with LiveView (probably with send_after/4) and I couldn't make it totally reliable, sometimes the updates would queued up, so in the end I "faked it" in javascript with hooks. Over the internet there is an added latency obviously. I feel it most in the game part because the button has a instant feedback. On the other parts, forms etc, this does not perform worse than a typical SPA. So I guess it would be very dependent on the kind of application you use it for. Nobody said it would replace all SPAs and javascript. Also the official demo runs an animation at 60 or 100fps IIRC, so there's that. Fun anecdote, my devops colleagues tried to ddos my app, they failed and all along people were playing the game without any hiccups. I wonder though how it performs on mobile networks. Aren't some of them terrible for websockets, when changing towers etc? Would the reconnect and session restoring be too much noticeable? [1] Demo On a free Gigalixir instance: https://every-weak-tapaculo.gigalixirapp.com https://every-weak-tapaculo.gigalixirapp.com On a Raspberry4 behind my FTTH: https://nameguess.funkybits.fr https://nameguess.funkybits.fr

by elamje 7y ago

abrookewood 7y ago

A lot of these trade-offs are clearly explained in a Stack Overflow Blog post [0]. The issue of latency is highlighted as a key issue, as is increased server load and no offline support. I would assume these also apply to LiveView. Still, the both sound appealing in that you can do everything in a single language. https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-about-blazor/ https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-...

elcritch 7y ago

Haven’t tried Blazor, but LiveView’s haven’t had too noticeable of a lag for me even doing basic UI stuff on a server. I wonder if .NET has a higher latency response times on average? Elixir/BEAM seem to consistently provide < 10 ms response times. Given a 30-60ms ping, that’s still provide a round trip of < 120 ms. Barely noticeable for many cases. Still for people with bad internet latencies either tech stack would be frustrating... I’d guess that most any web service for less than, say, 10k total users LV would be fine. Given a user base that size or smaller, the productivity tradeoffs outweigh most user inconvenience. As in, I can make a SaaS/SPA to serve a small market significantly quicker than using a bifurcated server/js-frontend. Especially if the SPA requires or benefits from live streaming updates (graphs, dashboards, stats apps, etc). No contest in my opinion, except for maybe a Clojure stack (?).

fahrradflucht 7y ago

What I don't understand with these technologies, is how you do continuous deployment without breaking all running client sessions evertime.

dnsbty 7y ago
With Erlang releases (compiled code with the Erlang runtime included) you can do hot code swapping to change the code while it’s still running. And iirc I believe LiveView will have all the state necessary client-side to be able to reconstruct the session when reconnecting the socket. I’m not near my development machine to make sure on that one though.
- out_of_protocol 7y ago
  As far as i know it doesn't work this way (session restoration) as of now. Something could be done but requires a lot of effort
- te_chris 7y ago
  We store our sessions in Redis and don't do hot code swapping but deploys do still mostly just work and live channels normally reconnect without any noticeable downtime. We run everything on GKE so a deploy is just rolling container swaps. Liveview is built on top of channels, so worth reading up about them: https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html
machiaweliczny 7y ago
I was just storing session state in Redis
josevalim 7y ago
LiveView does two things in particular: 1. It includes live navigation, which updates the URL as you interact with the app. For example, if you try the live scaffold generator in Phoenix v1.5.0-rc.0, you will see that once you click the "New Post" modal, the URL changes to "/posts/new". So if users reconnect by any reason (poor connection, new deployment, etc), they will go back to the same page with the same modal. 2. For forms, we automatically submit the current form state on reconnections, allowing the server and client to sync up. For complex applications, think a chat app or a game, then you have to persist messages, the game state, and what not on the server. But that would be necessary regardless if you are using LiveView or not.

conradfr 7y ago

I made a stupid game as LiveView POC [1] which I posted the other day and tested it on different conditions and can comment a bit on the latency. On a LAN you really don't feel it 99% of the time. However in the game I have a countdown that I initially updated each seconds with LiveView (probably with send_after/4) and I couldn't make it totally reliable, sometimes the updates would queued up, so in the end I "faked it" in javascript with hooks. Over the internet there is an added latency obviously. I feel it most in the game part because the button has a instant feedback. On the other parts, forms etc, this does not perform worse than a typical SPA. So I guess it would be very dependent on the kind of application you use it for. Nobody said it would replace all SPAs and javascript. Also the official demo runs an animation at 60 or 100fps IIRC, so there's that. Fun anecdote, my devops colleagues tried to ddos my app, they failed and all along people were playing the game without any hiccups. I wonder though how it performs on mobile networks. Aren't some of them terrible for websockets, when changing towers etc? Would the reconnect and session restoring be too much noticeable? [1] Demo On a free Gigalixir instance: https://every-weak-tapaculo.gigalixirapp.com https://every-weak-tapaculo.gigalixirapp.com On a Raspberry4 behind my FTTH: https://nameguess.funkybits.fr https://nameguess.funkybits.fr