9 ms·

Phoenix Dev Blog – Streams

254 points by losvedir 4y ago

revskill 4y ago
I'm not sure what's exactly problems which liveview tech solves. In real world applications, it's always "polling", because you're not sure when server finished your request. Or liveview is for toy application ? Note: You seems mislead the point here, to build interactive apps, of course you can just use websockets. What's more liveview solve ? I guess liveview = html + websocket.
- Touche 4y ago
  Huh? LiveView is for interactive apps. It's not finished until the user leaves the page. It's not polling.
- Cyph0n 4y ago
  It is not polling - it relies on Websockets.
- realusername 4y ago
  In realworld apps you have a lot of "dynamic" areas which are just "click there, ask the server for the changes and reflect that on the web page", this is where liveview is great. Another case are dynamic elements based on external factors not based on user actions (like for example the message counter on a social network), those are pretty annoying without liveview because you need to build a whole frontend event system just to change a number.
  - revskill 4y ago
    Are you sure Facebook or Twitter is using liveview for their social feed ?
    - nelsonic 4y ago
      Facebook or Twitter using LiveView wasn't implied by the comment. It's just an example use-case.
    - realusername 4y ago
      I'm piking a need that is common even for small websites. I even had to implement a similar concept for a small job board.
- ing33k 4y ago
  check out https://zcashblockexplorer.com/ https://zcashblockexplorer.com/ , it uses LiveView. https://zcashblockexplorer.com/mempool https://zcashblockexplorer.com/mempool
- sb8244 4y ago
  "What problem does React solve? You can just use HTML and jQuery to build websites." To me LiveView is not about interactive apps so much as it is a way to build applications, period. You can build in a way that may bring you more joy, performance, and dev speed than you could otherwise. Interactivity is a side effect, and it's a great one. But I wouldn't recommend LiveView if someone only wanted interactivity. I'd recommend LiveView if someone wants a different way to build than the React+API status quo.
  - revskill 4y ago
    React solves the composition of components, which lacks in HTML technologies. What about liveview ? That's the question. They're different.
    - sb8244 4y ago
      "you just need to write better code to have composition with jQuery" To be clear I don't believe that, but that's analogous to what I hear when I see this. LiveView has composition of components, so there's an immediate answer to your question. You've already answered another piece with built-in soft real-time. In all honesty, if you have looked at LiveView and don't understand what it brings then I'm not sure if you looked sincerely.
      - revskill 4y ago
        I know what it does. Instead of boilerplate to declare channels to handle live websocket, now you can just bind the real data to a DOM html. Isn't it ? Is there any more to bring ? React and similar technologies actually not just scrap your boilerplates, it's real abstraction (forget the DOM API) with state and componentation. It's not like you scrap your jquery boilerplate). I see people mess with DOM Api in their application, which is not the right way, because it's mixing different abstractions together to create a mess.
        sb8244 4y ago
        LiveView is also state and components. + It has a view of the DOM to optimize the data it sends over wire. It's a complete way to build complex apps. I've personally built fairly decent complexity SaaS (18mo of dev) completely on LiveView + some react when it made sense. Saying it's just HTML pushed over WebSocket is like saying React is just virtual DOM with components. There's much more to it when you get into it. Plus it's enjoyable. I had significantly more fun and development speed building on it than the typical React+API approach. That said it's still situational and I don't blindly recommend it to everyone. I think Elixir has one of the best graphql implementations (Absinthe), so I still recommend React+GQL as well.
- jjtheblunt 4y ago
  liveview is similar, in spirit, to how X11 apps had a client side library and a server side library (ultimately Xlib on one end), and were connected by a socket (bidirectional) over which minimal-ish data would fly back and forth to keep the client side displaying what the server wanted, and the server aware of events from the client side. liveview is also using a socket, whose existence springs to life via the "websockets" modernization where the client is a browser. and the traffic bidirectional over the socket again keeps the server side library aware of events, and the browser-side aware of UI alterations to display.
- Existenceblinks 4y ago
  Not all websockets are equal. If you've ever tried PhoenixChannel + PubSub .. you will know why. Also LiveView + Presence built on top of that with all niceties. And if you have more than 1 node, these also work in distributed fashion.
nelsonic 4y ago
Streams in LiveView are a game-changer for long-lived data-heavy apps like news feeds/readers or analytics dashboards that update steadily over time. We've been using LiveView in production for the last couple of years and it keeps getting better. Great post and continued updates from Chris & community. :-)
lucasyvas 4y ago
LiveView is a great pattern, but it's worth noting that it is not universally useful or better. If latency of UI change is more important than the latency of data update itself, doing the UI update on the client will always make more sense and the data can slide in shortly after. There is no silver bullet, and sometimes doing a UI update on the client is still a better UX. I can foresee a future where everyone goes down the LiveView rabbit hole, only to improperly blame it for causing too much UI update latency in some cases. When it all goes well, it's very clean. If you can't make sure the server is evenly loaded amongst all your clients and close to them, it will probably feel quite poor in comparison to some client side update code.
- brightball 4y ago
  That’s definitely true, but in my experience the data update is the 80% use case.
- ch4s3 4y ago
  I think you’re directionally correct, but LiveView has a JS api that can fire off front end events. You can tie in React, Vue, Alpine, or whatever if you want.
- realusername 4y ago
  If the UI change requires no network calls, it's better to use a JS hook or/and Alpine in my opinion.
  - yencabulator 4y ago
    The parent is talking about a scenario where the network action may take longer, and you want the UI to remain responsive. Consider a save button that goes through state transitions dirty->saving->saved.
- POiNTx 4y ago
  On this note I've been developing LiveSvelte these last 2 weeks. It's not finished yet but it's promosing. Takes a way a lot of the UI update issues with LiveView as you can have local state very easily while still maintaining reactivity with LiveView wherever you need it. LiveSvelte: https://github.com/woutdp/live_svelte/ https://github.com/woutdp/live_svelte/
sph 4y ago
On one hand I've been waiting for LiveView to stabilize and get to its 1.0, on the other hand every release is more awesome than the previous one, and I'm speaking as someone that has been using it since its first public release. Thanks Chris and all the contributors for your hard work.
- ch4s3 4y ago
  It’s reasonably stable and when there are bumps, it’s usually easy to deal with them in my experience. We’re all in for most new applications where I work.
- rhgraysonii 4y ago
  I have been a Live View skeptic for years. Recently in 30 days we were able to build an MVP of a complex tool (ingesting ML models, time series + regular databases, complex FE interactions, live notifications, more) that blew the minds of the higher ups and got a ton of buy in building using it from the org as a whole after the success. There were a few bumps, but as a whole, it’s largely been a _delightful_ experience and I found myself pleasantly surprised as a whole. I would have little fear diving in at this point. We are not a small org and it was a big bet that has paid off.
  - deleted 4y ago
    [deleted]
cambaceres 4y ago
I have been developing with React/Node for 7+ years now and I have started to look for something else. Perhaps this would be something to try. I'm specialized in developing web portals/backoffice systems, would this be suitable for this? What limitations are there?
- bongobingo1 4y ago
  RTT is the big limiting factor. It has ways to indicate "things are in flight" but for distant deployments you probably still need to write JS to manage some in-page elements for reasonable feeling UX. This isn't hard, it has support for interop with plain JS or existing libraries and a somewhat limited built in system for basic show/hide/set/remove attributes (somehow lacks a "toggle_class" and "toggle_attribute" function though so you can write those yourself...). You can dispatch any custom JS event from it to cover .. anything you need. If you're exclusively deploying to on-site/one-site/geographically-constrained systems, then you actually skip that issue... You also have to re-think about how write code as Elixir is immutable, though I see that as a bonus. Phoenix (and by extension LiveView) are actually a lot smaller than you might think coming from Rails or the like, mostly leveraging existing tools. Elixir/Erlang/BEAM make building systems incredibly pleasurable. It ships with many tools to make and connect complicated things together, in a reliable way. Depending on what you make you may find it very liberating after working with Node.
  - emerongi 4y ago
    > It has ways to indicate "things are in flight" but for distant deployments you probably still need to write JS to manage some in-page elements for reasonable feeling UX. Most JS UIs behave like this: open a list view, watch a spinner until data is fetched from the server. There is practically no difference between that and showing a spinner first and then the list.
    - bongobingo1 4y ago
      Yes but my point is if you don't do anything in LV, you click the button and it sits there seemingly doing nothing, then patches the DOM with the update. Possibly the default "topbar" will show depending on its timeout configuration. So you need to pay some attention to applying-css/hooking-into-the-tooling (phx-click-loading) to show that a button was indeed clicked and is working on fetching data. Some things such as flipping between tabs can feel quite bad if you click and the tab-button just puts a spinner there or the button just "fades a bit". Its much nicer to replace the content pane with some mock-blocks to show "yes, the tab swapped and its loading data" which is where you need JS to temporarily hide/show some things. And once you start doing that you should really be measuring the avg rtt on the socket because showing the mock-content for 1ms then swapping the real content is also bad, so you need JS again to figure the best UX for that client. Or you simply render all the tabs in one go and again, duck into JS to perform the local show/hide.
lilactown 4y ago
website seems down?
- faraaz98 4y ago
  it does
  - the-alchemist 4y ago
    HTTP ERROR 502 for me
wzy 4y ago
How is the link down given that Fly.io is an cloud/edge hosting service?
- deleted 4y ago
  [deleted]
- emerongi 4y ago
  A plumber's house always has a dripping tap.
- jesperwe 4y ago
  https://status.flyio.net/ https://status.flyio.net/ currently shows a partial outage.
- marcus_cemes 4y ago
  The two are not mutually exclusive, it's probably not an issue with horizontal scaling.
- esistgut 4y ago
  Today they rolled some kind of upgrade and my backend become unreachable for hours, this is not my first problem with them. I assembled a quick docker-compose.yml and moved to Hetzner. Fly is pushing a lot of blog worthy stuff but it is not production ready.
manmal 4y ago
Until the linked post is up again, here‘s another source: https://phoenixframework.org/blog/phoenix-1.7-final-released https://phoenixframework.org/blog/phoenix-1.7-final-released
adamnemecek 4y ago
Streams are a fundamentally underappreciated data structure because they are generally not implemented optimally. Streams correspond to coalgebras and that whole field is like the missing half of programming.
- WJW 4y ago
  If streams are the coalgebras, what do you consider the normal algebras of programming?
  - andrewflnr 4y ago
    Structs. Regular objects. If you haven't heard the term "algebraic data types", searching it will probably give you an idea of how the "algebra" part fits in.
  - adamnemecek 4y ago
    Lists.
endisneigh 4y ago
Anyone have a good example of an app, in production, that's publicly accessible, that uses liveview? I'd like to check out the experience for myself.
- pdgonzalez872 4y ago
  Sure! - Here is a thread on ElixirForum: https://elixirforum.com/t/phoenix-liveview-in-production-examples/35579/15 https://elixirforum.com/t/phoenix-liveview-in-production-exa... - Here is a neat little aggregator: https://liveviewdemos.com/ https://liveviewdemos.com/, and here is the code for it: https://github.com/leandrocp/phoenix_live_view_collection https://github.com/leandrocp/phoenix_live_view_collection
  - bbkane 4y ago
    I had to wait 10s for that list to load :/
    - bongobingo1 4y ago
      Blame api.twitter.com :)
college_physics 4y ago
How imprortant is elixir in all this? Is it merely the frontrunner of a useful new pattern? E.g., do erlang, BEAM or functional programming play a critical role or will other stacks effectively replicate this and how are they doing so far, which would be the next more mature?
- say_it_as_it_is 4y ago
  People will replicate LiveView in other languages but fall short in some areas. Golang might pull it off. Rust might in another 5 years.
- sph 4y ago
  Live View is well integrated with the lightweight process/actor model that is central to Erlang and Elixir, where state and asynchronous events much are easier to code and troubleshoot than other languages. So while you can replicate Live View everywhere, it's never going to be as convenient or expressive as the real thing. On the project I am working on I have a Live View dashboard that's getting updated in real time from distributed async events coming from any server in the cluster with less than a dozen lines of code, and using nothing more fancy than standard Phoenix libraries (Phoenix.PubSub) and BEAM primitives (pg2, nodes, mailboxes, etc.). Porting Live View to Go, Python, Rust, Javascript is the easy part. You'll still miss the BEAM dearly.
  - deleted 4y ago
    [deleted]
  - PYTHONDJANGO 4y ago
    I would like to study that code - wold you like to put that code on github or can you link to any similar example? Thank you very much!
- nickjj 4y ago
  I've been using Hotwire[0] for a while now (Turbo + Stimulus) which works with any back-end, it's been great. It builds on everything you already know and doesn't require rewriting your app. Everything is treated as progressive enhancements. It's not the same exact model and I wouldn't classify it as a replication of LiveView, it's more of an extension of the Turbolinks model from 2016 with a decent story for adding in frontend JS where needed. I think it's comparable from a bottom line point of view of it being a solution that lets you send snippets of HTML over the wire (literally the tagline of Hotwire) to very quickly build nice feeling web apps with minimal to no Javascript. Instead of going all-in with state and Websockets like LiveView, Hotwire sticks to a stateless HTTP model and sprinkles in Websockets only when necessary such as when broadcasting an event to any connected clients. I've used it in Flask before and it took a few minutes to get going. For the broadcasting bits server side, it works with Rails out of the box since this toolset was extracted from Hey and Basecamp. Other frameworks have their own ports tho. [0]: https://hotwired.dev/ https://hotwired.dev/
eptgrant 4y ago
Maybe a little off topic, but for a .NET dev, what benefits does LiveView offer over Blazor Server Side?

254 points by losvedir 4y ago

I'm not sure what's exactly problems which liveview tech solves. In real world applications, it's always "polling", because you're not sure when server finished your request. Or liveview is for toy application ? Note: You seems mislead the point here, to build interactive apps, of course you can just use websockets. What's more liveview solve ? I guess liveview = html + websocket.

Touche 4y ago
Huh? LiveView is for interactive apps. It's not finished until the user leaves the page. It's not polling.
Cyph0n 4y ago
It is not polling - it relies on Websockets.
realusername 4y ago
In realworld apps you have a lot of "dynamic" areas which are just "click there, ask the server for the changes and reflect that on the web page", this is where liveview is great. Another case are dynamic elements based on external factors not based on user actions (like for example the message counter on a social network), those are pretty annoying without liveview because you need to build a whole frontend event system just to change a number.
- revskill 4y ago
  Are you sure Facebook or Twitter is using liveview for their social feed ?
  - nelsonic 4y ago
    Facebook or Twitter using LiveView wasn't implied by the comment. It's just an example use-case.
  - realusername 4y ago
    I'm piking a need that is common even for small websites. I even had to implement a similar concept for a small job board.
ing33k 4y ago
check out https://zcashblockexplorer.com/ https://zcashblockexplorer.com/ , it uses LiveView. https://zcashblockexplorer.com/mempool https://zcashblockexplorer.com/mempool
sb8244 4y ago
"What problem does React solve? You can just use HTML and jQuery to build websites." To me LiveView is not about interactive apps so much as it is a way to build applications, period. You can build in a way that may bring you more joy, performance, and dev speed than you could otherwise. Interactivity is a side effect, and it's a great one. But I wouldn't recommend LiveView if someone only wanted interactivity. I'd recommend LiveView if someone wants a different way to build than the React+API status quo.
- revskill 4y ago
  React solves the composition of components, which lacks in HTML technologies. What about liveview ? That's the question. They're different.
  - sb8244 4y ago
    "you just need to write better code to have composition with jQuery" To be clear I don't believe that, but that's analogous to what I hear when I see this. LiveView has composition of components, so there's an immediate answer to your question. You've already answered another piece with built-in soft real-time. In all honesty, if you have looked at LiveView and don't understand what it brings then I'm not sure if you looked sincerely.
    - revskill 4y ago
      I know what it does. Instead of boilerplate to declare channels to handle live websocket, now you can just bind the real data to a DOM html. Isn't it ? Is there any more to bring ? React and similar technologies actually not just scrap your boilerplates, it's real abstraction (forget the DOM API) with state and componentation. It's not like you scrap your jquery boilerplate). I see people mess with DOM Api in their application, which is not the right way, because it's mixing different abstractions together to create a mess.
      - sb8244 4y ago
        LiveView is also state and components. + It has a view of the DOM to optimize the data it sends over wire. It's a complete way to build complex apps. I've personally built fairly decent complexity SaaS (18mo of dev) completely on LiveView + some react when it made sense. Saying it's just HTML pushed over WebSocket is like saying React is just virtual DOM with components. There's much more to it when you get into it. Plus it's enjoyable. I had significantly more fun and development speed building on it than the typical React+API approach. That said it's still situational and I don't blindly recommend it to everyone. I think Elixir has one of the best graphql implementations (Absinthe), so I still recommend React+GQL as well.
jjtheblunt 4y ago
liveview is similar, in spirit, to how X11 apps had a client side library and a server side library (ultimately Xlib on one end), and were connected by a socket (bidirectional) over which minimal-ish data would fly back and forth to keep the client side displaying what the server wanted, and the server aware of events from the client side. liveview is also using a socket, whose existence springs to life via the "websockets" modernization where the client is a browser. and the traffic bidirectional over the socket again keeps the server side library aware of events, and the browser-side aware of UI alterations to display.
Existenceblinks 4y ago
Not all websockets are equal. If you've ever tried PhoenixChannel + PubSub .. you will know why. Also LiveView + Presence built on top of that with all niceties. And if you have more than 1 node, these also work in distributed fashion.

nelsonic 4y ago

Streams in LiveView are a game-changer for long-lived data-heavy apps like news feeds/readers or analytics dashboards that update steadily over time. We've been using LiveView in production for the last couple of years and it keeps getting better. Great post and continued updates from Chris & community. :-)

lucasyvas 4y ago

LiveView is a great pattern, but it's worth noting that it is not universally useful or better. If latency of UI change is more important than the latency of data update itself, doing the UI update on the client will always make more sense and the data can slide in shortly after. There is no silver bullet, and sometimes doing a UI update on the client is still a better UX. I can foresee a future where everyone goes down the LiveView rabbit hole, only to improperly blame it for causing too much UI update latency in some cases. When it all goes well, it's very clean. If you can't make sure the server is evenly loaded amongst all your clients and close to them, it will probably feel quite poor in comparison to some client side update code.

brightball 4y ago
That’s definitely true, but in my experience the data update is the 80% use case.
ch4s3 4y ago
I think you’re directionally correct, but LiveView has a JS api that can fire off front end events. You can tie in React, Vue, Alpine, or whatever if you want.
realusername 4y ago
If the UI change requires no network calls, it's better to use a JS hook or/and Alpine in my opinion.
- yencabulator 4y ago
  The parent is talking about a scenario where the network action may take longer, and you want the UI to remain responsive. Consider a save button that goes through state transitions dirty->saving->saved.
POiNTx 4y ago
On this note I've been developing LiveSvelte these last 2 weeks. It's not finished yet but it's promosing. Takes a way a lot of the UI update issues with LiveView as you can have local state very easily while still maintaining reactivity with LiveView wherever you need it. LiveSvelte: https://github.com/woutdp/live_svelte/ https://github.com/woutdp/live_svelte/

sph 4y ago

On one hand I've been waiting for LiveView to stabilize and get to its 1.0, on the other hand every release is more awesome than the previous one, and I'm speaking as someone that has been using it since its first public release. Thanks Chris and all the contributors for your hard work.

ch4s3 4y ago
It’s reasonably stable and when there are bumps, it’s usually easy to deal with them in my experience. We’re all in for most new applications where I work.
rhgraysonii 4y ago
I have been a Live View skeptic for years. Recently in 30 days we were able to build an MVP of a complex tool (ingesting ML models, time series + regular databases, complex FE interactions, live notifications, more) that blew the minds of the higher ups and got a ton of buy in building using it from the org as a whole after the success. There were a few bumps, but as a whole, it’s largely been a _delightful_ experience and I found myself pleasantly surprised as a whole. I would have little fear diving in at this point. We are not a small org and it was a big bet that has paid off.
- deleted 4y ago
  [deleted]

cambaceres 4y ago

I have been developing with React/Node for 7+ years now and I have started to look for something else. Perhaps this would be something to try. I'm specialized in developing web portals/backoffice systems, would this be suitable for this? What limitations are there?

bongobingo1 4y ago
RTT is the big limiting factor. It has ways to indicate "things are in flight" but for distant deployments you probably still need to write JS to manage some in-page elements for reasonable feeling UX. This isn't hard, it has support for interop with plain JS or existing libraries and a somewhat limited built in system for basic show/hide/set/remove attributes (somehow lacks a "toggle_class" and "toggle_attribute" function though so you can write those yourself...). You can dispatch any custom JS event from it to cover .. anything you need. If you're exclusively deploying to on-site/one-site/geographically-constrained systems, then you actually skip that issue... You also have to re-think about how write code as Elixir is immutable, though I see that as a bonus. Phoenix (and by extension LiveView) are actually a lot smaller than you might think coming from Rails or the like, mostly leveraging existing tools. Elixir/Erlang/BEAM make building systems incredibly pleasurable. It ships with many tools to make and connect complicated things together, in a reliable way. Depending on what you make you may find it very liberating after working with Node.
- emerongi 4y ago
  > It has ways to indicate "things are in flight" but for distant deployments you probably still need to write JS to manage some in-page elements for reasonable feeling UX. Most JS UIs behave like this: open a list view, watch a spinner until data is fetched from the server. There is practically no difference between that and showing a spinner first and then the list.
  - bongobingo1 4y ago
    Yes but my point is if you don't do anything in LV, you click the button and it sits there seemingly doing nothing, then patches the DOM with the update. Possibly the default "topbar" will show depending on its timeout configuration. So you need to pay some attention to applying-css/hooking-into-the-tooling (phx-click-loading) to show that a button was indeed clicked and is working on fetching data. Some things such as flipping between tabs can feel quite bad if you click and the tab-button just puts a spinner there or the button just "fades a bit". Its much nicer to replace the content pane with some mock-blocks to show "yes, the tab swapped and its loading data" which is where you need JS to temporarily hide/show some things. And once you start doing that you should really be measuring the avg rtt on the socket because showing the mock-content for 1ms then swapping the real content is also bad, so you need JS again to figure the best UX for that client. Or you simply render all the tabs in one go and again, duck into JS to perform the local show/hide.

lilactown 4y ago

website seems down?

faraaz98 4y ago
it does
- the-alchemist 4y ago
  HTTP ERROR 502 for me

wzy 4y ago

How is the link down given that Fly.io is an cloud/edge hosting service?

deleted 4y ago
[deleted]
emerongi 4y ago
A plumber's house always has a dripping tap.
jesperwe 4y ago
https://status.flyio.net/ https://status.flyio.net/ currently shows a partial outage.
marcus_cemes 4y ago
The two are not mutually exclusive, it's probably not an issue with horizontal scaling.
esistgut 4y ago
Today they rolled some kind of upgrade and my backend become unreachable for hours, this is not my first problem with them. I assembled a quick docker-compose.yml and moved to Hetzner. Fly is pushing a lot of blog worthy stuff but it is not production ready.

manmal 4y ago

Until the linked post is up again, here‘s another source: https://phoenixframework.org/blog/phoenix-1.7-final-released https://phoenixframework.org/blog/phoenix-1.7-final-released

adamnemecek 4y ago

Streams are a fundamentally underappreciated data structure because they are generally not implemented optimally. Streams correspond to coalgebras and that whole field is like the missing half of programming.

WJW 4y ago
If streams are the coalgebras, what do you consider the normal algebras of programming?
- andrewflnr 4y ago
  Structs. Regular objects. If you haven't heard the term "algebraic data types", searching it will probably give you an idea of how the "algebra" part fits in.
- adamnemecek 4y ago
  Lists.

endisneigh 4y ago

Anyone have a good example of an app, in production, that's publicly accessible, that uses liveview? I'd like to check out the experience for myself.

pdgonzalez872 4y ago
Sure! - Here is a thread on ElixirForum: https://elixirforum.com/t/phoenix-liveview-in-production-examples/35579/15 https://elixirforum.com/t/phoenix-liveview-in-production-exa... - Here is a neat little aggregator: https://liveviewdemos.com/ https://liveviewdemos.com/, and here is the code for it: https://github.com/leandrocp/phoenix_live_view_collection https://github.com/leandrocp/phoenix_live_view_collection
- bbkane 4y ago
  I had to wait 10s for that list to load :/
  - bongobingo1 4y ago
    Blame api.twitter.com :)

college_physics 4y ago

How imprortant is elixir in all this? Is it merely the frontrunner of a useful new pattern? E.g., do erlang, BEAM or functional programming play a critical role or will other stacks effectively replicate this and how are they doing so far, which would be the next more mature?

say_it_as_it_is 4y ago
People will replicate LiveView in other languages but fall short in some areas. Golang might pull it off. Rust might in another 5 years.
sph 4y ago
Live View is well integrated with the lightweight process/actor model that is central to Erlang and Elixir, where state and asynchronous events much are easier to code and troubleshoot than other languages. So while you can replicate Live View everywhere, it's never going to be as convenient or expressive as the real thing. On the project I am working on I have a Live View dashboard that's getting updated in real time from distributed async events coming from any server in the cluster with less than a dozen lines of code, and using nothing more fancy than standard Phoenix libraries (Phoenix.PubSub) and BEAM primitives (pg2, nodes, mailboxes, etc.). Porting Live View to Go, Python, Rust, Javascript is the easy part. You'll still miss the BEAM dearly.
- deleted 4y ago
  [deleted]
- PYTHONDJANGO 4y ago
  I would like to study that code - wold you like to put that code on github or can you link to any similar example? Thank you very much!
nickjj 4y ago
I've been using Hotwire[0] for a while now (Turbo + Stimulus) which works with any back-end, it's been great. It builds on everything you already know and doesn't require rewriting your app. Everything is treated as progressive enhancements. It's not the same exact model and I wouldn't classify it as a replication of LiveView, it's more of an extension of the Turbolinks model from 2016 with a decent story for adding in frontend JS where needed. I think it's comparable from a bottom line point of view of it being a solution that lets you send snippets of HTML over the wire (literally the tagline of Hotwire) to very quickly build nice feeling web apps with minimal to no Javascript. Instead of going all-in with state and Websockets like LiveView, Hotwire sticks to a stateless HTTP model and sprinkles in Websockets only when necessary such as when broadcasting an event to any connected clients. I've used it in Flask before and it took a few minutes to get going. For the broadcasting bits server side, it works with Rails out of the box since this toolset was extracted from Hey and Basecamp. Other frameworks have their own ports tho. [0]: https://hotwired.dev/ https://hotwired.dev/

eptgrant 4y ago

Maybe a little off topic, but for a .NET dev, what benefits does LiveView offer over Blazor Server Side?