4 ms·

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 differ

by mikl 7y ago

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.

GiorgioG 7y ago
ASP.NET Core Blazor has the same ability, for those stuck in a corporate environment.
- math 7y ago
  even those who aren't..
- sl1ck731 7y ago
  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.
  - GiorgioG 7y ago
    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.)
  - elamje 7y ago
    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.
theonething 7y ago
Yes! If I could use things like LiveView or TurboLinks exclusively, I wouldn't miss React and friends at all.
- pzmarzly 7y ago
  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.
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 (?).
hamandcheese 7y ago
LiveDashboard seems to be something different than LiveView
- abrookewood 7y ago
  It's a metrics dashboard for Phoenix applications that uses LiveView to display the data.
erichocean 7y ago
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! Link to the event: https://dunksandjordans.wordpress.com/2015/02/13/nike-pop-up-shop-for-all-star-weekend/ https://dunksandjordans.wordpress.com/2015/02/13/nike-pop-up...
aabbcc1241 7y ago
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.

by mikl 7y ago

GiorgioG 7y ago

ASP.NET Core Blazor has the same ability, for those stuck in a corporate environment.

math 7y ago
even those who aren't..
sl1ck731 7y ago
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.
- GiorgioG 7y ago
  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.)
- elamje 7y ago
  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.

theonething 7y ago

Yes! If I could use things like LiveView or TurboLinks exclusively, I wouldn't miss React and friends at all.

pzmarzly 7y ago
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.

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 (?).

hamandcheese 7y ago

LiveDashboard seems to be something different than LiveView

abrookewood 7y ago
It's a metrics dashboard for Phoenix applications that uses LiveView to display the data.

erichocean 7y ago

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! Link to the event: https://dunksandjordans.wordpress.com/2015/02/13/nike-pop-up-shop-for-all-star-weekend/ https://dunksandjordans.wordpress.com/2015/02/13/nike-pop-up...

aabbcc1241 7y ago

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.