LiveView is such a game changer for Phoenix (and thus Elixir). From being “just another web framework” (albeit a very nice one), LiveView enables a whole different paradigm for web applications. As a developer, it’s like having superpowers. What would have taken days to build with an SPA or similar “fat client” JavaScript can be done in hours with LiveView.
I built a pop-up store for Nike's NBA All Stars event that used this approach about 5 years ago (in Node.js).
Productivity was extremely high, and even better, you could restart clients and since all app state was on the server, they would start up wherever they had left off. I stored the state in LMDB transactionally, so I could also bounce the server any time. Clients would reconnected with their WebSocket while it was being used and no one was the wiser. Did that dozens and dozens of times during the event.
I used Blossom (SproutCore derivative) for the UI and statecharts to make that happen. All actions were sent to the server (written in Node.js, with LMDB as the persistent storage). We also had iOS apps for the back office and customer support reps that worked identically (but in Objective-C).
Entire project took 5 weeks with myself as the only developer, replicated a (beautiful) iPhone app Nike made called SNKRS entirely in Blossom and ran it on these huge 30inch touch screens inside a full screen Chrome instance.
Very fun project, and we sold ~1M in shoes (through Stripe) in four days. Freaking cold though, February in NY!
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.
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.
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?
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 (?).
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.
I didn't realize that killing the LV server process would act just like a reconnect.. But that makes sense! It's been really impressive how well LV reconnects even when a server has been down for a while (I use RPi3's and they loose WiFi or reboot sometimes).
It's good to note that using the live navigation you can pass parameters via the URL. That's my main method for graphing / data view pages.
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.
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.
In Laravel (PHP) world, some people have tried building sites LiveWire + Blade X + alpinejs. LiveWire is LiveView but for PHP and using POST and GET requests only, Blade X is for server side React-like DOM building, alpinejs for JS stuff that doesn’t require data round trip (for example displaying a popup with known contents).
I haven’t seen any large projects built with it yet, though for small ones it sure feels like magic.
Is Blazor still "experimental"? I looked at it a year ago I believe and most people didn't seem to recommend it at that time due to not being optimized.
Sadly Microsoft is still terrible with naming developer products. There are 2 Blazors, the server-side blazor (which works like Phoenix LiveView, and then there's the version of Blazor that will target WebAssembly and run completely client-side.) The WebAssembly 'version' of Blazor is still experimental. Server-side Blazor is production-ready as far as Microsoft is concerned (I believe.)
Using Blazor Server in production right now. Like another commenter said, there is also a client side web assembly target as well. The Server framework is great, but has its issues which I mention elsewhere in the thread.
node.js folk speaking: For people who like the concept of SSR SPA or "thin as just a screen client" but not comfortable to develop in dynamic type dynamic type language (Elixir and Erlang), checkout TS LiveView. It implemented the idea of Phoenix LiveView for Typescript developer.
