5 ms·

Phoenix live view (anything on BEAM really) maps each ws to a BEAM process so scaling to 10000+ connections is both cheap and built-in

nickjj 6y ago
But LV is still in its infancy and there are very real implications of using websockets that are unrelated to open connections. Just the other day someone posted on the Elixir forums about live_redirect causing 2 network round trip connections[0]. Basically there was double the latency to transition between pages due to this "bug". I air quoted "bug" because it's working as intended, it's just not optimal. The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket". I'm not sure what the state of the issue is but it currently stands as closed. I've pinged 80ms to servers where LV was being used and the delay was extremely noticeable (before I even knew about this double network round trip issue). It feels much worse than a Turbo Drive / Turbolinks driven site (which uses HTTP instead of websockets like LV does). In some cases LV feels slower than a regular site even with the DOM having to re-parse all of your assets. The only time LV feels like a net win to me is when you're on a local connection with 1ms of latency. I wanted to use LV a lot, but backed out because I kept running into bugs and missing features. Plus after feeling a LV site on a non-local connection I can't say that I would want to impose that experience on users. Especially folks who happen to connect from let's say Europe to the US, or even further away. The web is a global place. [0]: https://elixirforum.com/t/shortcomings-in-liveview-are-there-any-i-should-look-out-for/31831/47 https://elixirforum.com/t/shortcomings-in-liveview-are-there... [1]: https://github.com/phoenixframework/phoenix_live_view/issues/1334 https://github.com/phoenixframework/phoenix_live_view/issues...
- benzible 6y ago
  When did you last use it? Javascript hook support wasn't there early on. The state of the art is the "PETAL StacK" [1] which uses client-side JS for interactions that don't require a roundtrip [1] https://thinkingelixir.com/petal-stack-in-elixir/ https://thinkingelixir.com/petal-stack-in-elixir/
  - nickjj 6y ago
    > When did you last use it? I gave it a fair shake a few times. Once when it first came out, then again a year later and then again 6 months ago. Lack of hooks wasn't a concern I had at the time. It was more around core behavior of the library and critical features that were missing. Some of those features have been added after I posted about them but all that did was destroy any confidence I had in using LV because these are things that would have been encountered on day 1 of deploying a single LV app to production. We're talking huge things, like how to invalidate and update assets in the <head> of your page in a user friendly way. It left an impression on me that LV isn't really being used much in real world apps by the team developing it. I could be wrong of course but that's the impression it left. Plus it feels like it's taking a really long time for certain features to make their way into the library. For example file uploads took something like 18 months to go from being talked about publicly to getting an alpha release and now it feels like it's on the burden of the community to test this in production without really knowing much about the feature. That and the docs still leave a lot to be desired (especially around the time I read them) and the story for the last ~18 months is that since LV is a pre 1.0 release the docs aren't really written up yet since stuff is changing all the time. I know docs take a long time to write (I've written literally over a million words of blog posts / course notes / documentation) but docs and practical examples are also the most important thing IMO to nudge folks into using something. Personally I don't want to have to read minimal docs, API specs and dive into the source code that I can't read very well because there's a lot of macros to see how something works just to use it effectively. Especially if I'm on the front lines of having to pioneer the tech, which means I'll probably be under pressure to report and fix bugs that I don't know how to fix. I don't know. All of this experience with LV and Elixir / Phoenix really made me understand that this tech stack is not for me. Especially not when Hotwire Turbo exists and works with any back-end language and it also has proof of it being used in a mission critical massive SAAS application (https://hey.com https://hey.com). That leaves me super confident that it'll work for me (and it has been), even outside of Rails. Maybe in 5+ years I'll try Elixir again (hopefully Stripe and other payment providers have Elixir clients by then!), because the core Elixir eco-system in general has a bunch of nice things. It just doesn't feel optimized yet for building applications (IMO). At least not compared to most other web frameworks. Also, while I don't use Laravel I also have major respect for Caleb Porzio. He created Laravel's version of Live View (LiveWire)[0] by himself. It mainly uses HTTP and he also has a ton of docs / videos on implementing practical application features with it. He shipped 2 major versions and everything about its API and docs just oozes creating something made for developers to develop applications. It's funny how a slightly different position on something can make something explode in popularity. I haven't even written a single line of Laravel and have no intention on switching to it, but his presentation and execution of an open source library is something I admire. [0]: https://laravel-livewire.com/ https://laravel-livewire.com/
- josevalim 6y ago
  > The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket" Please Nick, you can literally check your links to see this is inaccurate. I mentioned a solution after the issue was closed - and not before as you describe. And I figured out the solution *with Chris*, as I clearly mention in my comment. And then later on: > dive into the source code that I can't read very well because there's a lot of macros There are like 8 macros... > since LV is a pre 1.0 release the docs aren't really written up yet since stuff is changing all the time Seriously? No one has ever said this is the case. Just go to the [official docs](https://hexdocs.pm/phoenix_live_view https://hexdocs.pm/phoenix_live_view). All public functions are properly documented, there are introductory guides, etc. Sure, we don't have official screencasts but that's something we rely on the community to step in: Pragmatic Studio has a fantastic course on LiveView (which I was involved as a sounding board), there is Grox.io, etc. And it hasn't stopped either, a new book was literally announced today. There are other inaccuracies in the comments below but honestly I don't have the energy to go down this rabbit hole again.
  - nickjj 6y ago
    > There are like 8 macros... I should have used quote / unquote instead of the word macro. When I looked into the code I started with the engine and renderer. Between both modules they had dozens of quote / unquote usages which to me was hard to follow. Not because it's written poorly or anything like that, but it's not exactly easy to trace that code to learn how something works in more detail. > I mentioned a solution after the issue was closed - and not before as you describe. Yes, after it's been closed. But look at it from what end users of your library see from that chain of events: 1. User asks question on forums and presents a case where something very bad happens (2x network round trips) 2. User posts issue on GitHub 3. Creator of LV says it's a known trade off and quickly closes the issue 4. You and the creator of LV talk offline and figure out a potential work around Re-opening the issue after #4 would have done a lot of good because it shows at a glance that it's a current issue, it's being addressed and open for discussion. With the issue being and staying closed this gives off a message that you're not actively working on fixing the bug and aren't open to any form of discussion or assistance around fixing it. Maybe that wasn't your intention but that's the message you're sending to some people. > Seriously? That's the answer I've always received in the past when asking questions about the state of the docs on Slack and IRC over the years. The current docs usually give you a partial understanding of how something works. It's usually enough to get a basic idea of how something might work but not enough to get the ball rolling to implement a solution in your own application. I don't think I'm the only one who feels this way either because I've seen a lot of repeated questions on IRC and the forums, especially around LV components.

nickjj 6y ago

But LV is still in its infancy and there are very real implications of using websockets that are unrelated to open connections. Just the other day someone posted on the Elixir forums about live_redirect causing 2 network round trip connections[0]. Basically there was double the latency to transition between pages due to this "bug". I air quoted "bug" because it's working as intended, it's just not optimal. The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket". I'm not sure what the state of the issue is but it currently stands as closed. I've pinged 80ms to servers where LV was being used and the delay was extremely noticeable (before I even knew about this double network round trip issue). It feels much worse than a Turbo Drive / Turbolinks driven site (which uses HTTP instead of websockets like LV does). In some cases LV feels slower than a regular site even with the DOM having to re-parse all of your assets. The only time LV feels like a net win to me is when you're on a local connection with 1ms of latency. I wanted to use LV a lot, but backed out because I kept running into bugs and missing features. Plus after feeling a LV site on a non-local connection I can't say that I would want to impose that experience on users. Especially folks who happen to connect from let's say Europe to the US, or even further away. The web is a global place. [0]: https://elixirforum.com/t/shortcomings-in-liveview-are-there-any-i-should-look-out-for/31831/47 https://elixirforum.com/t/shortcomings-in-liveview-are-there... [1]: https://github.com/phoenixframework/phoenix_live_view/issues/1334 https://github.com/phoenixframework/phoenix_live_view/issues...

benzible 6y ago
When did you last use it? Javascript hook support wasn't there early on. The state of the art is the "PETAL StacK" [1] which uses client-side JS for interactions that don't require a roundtrip [1] https://thinkingelixir.com/petal-stack-in-elixir/ https://thinkingelixir.com/petal-stack-in-elixir/
- nickjj 6y ago
  > When did you last use it? I gave it a fair shake a few times. Once when it first came out, then again a year later and then again 6 months ago. Lack of hooks wasn't a concern I had at the time. It was more around core behavior of the library and critical features that were missing. Some of those features have been added after I posted about them but all that did was destroy any confidence I had in using LV because these are things that would have been encountered on day 1 of deploying a single LV app to production. We're talking huge things, like how to invalidate and update assets in the <head> of your page in a user friendly way. It left an impression on me that LV isn't really being used much in real world apps by the team developing it. I could be wrong of course but that's the impression it left. Plus it feels like it's taking a really long time for certain features to make their way into the library. For example file uploads took something like 18 months to go from being talked about publicly to getting an alpha release and now it feels like it's on the burden of the community to test this in production without really knowing much about the feature. That and the docs still leave a lot to be desired (especially around the time I read them) and the story for the last ~18 months is that since LV is a pre 1.0 release the docs aren't really written up yet since stuff is changing all the time. I know docs take a long time to write (I've written literally over a million words of blog posts / course notes / documentation) but docs and practical examples are also the most important thing IMO to nudge folks into using something. Personally I don't want to have to read minimal docs, API specs and dive into the source code that I can't read very well because there's a lot of macros to see how something works just to use it effectively. Especially if I'm on the front lines of having to pioneer the tech, which means I'll probably be under pressure to report and fix bugs that I don't know how to fix. I don't know. All of this experience with LV and Elixir / Phoenix really made me understand that this tech stack is not for me. Especially not when Hotwire Turbo exists and works with any back-end language and it also has proof of it being used in a mission critical massive SAAS application (https://hey.com https://hey.com). That leaves me super confident that it'll work for me (and it has been), even outside of Rails. Maybe in 5+ years I'll try Elixir again (hopefully Stripe and other payment providers have Elixir clients by then!), because the core Elixir eco-system in general has a bunch of nice things. It just doesn't feel optimized yet for building applications (IMO). At least not compared to most other web frameworks. Also, while I don't use Laravel I also have major respect for Caleb Porzio. He created Laravel's version of Live View (LiveWire)[0] by himself. It mainly uses HTTP and he also has a ton of docs / videos on implementing practical application features with it. He shipped 2 major versions and everything about its API and docs just oozes creating something made for developers to develop applications. It's funny how a slightly different position on something can make something explode in popularity. I haven't even written a single line of Laravel and have no intention on switching to it, but his presentation and execution of an open source library is something I admire. [0]: https://laravel-livewire.com/ https://laravel-livewire.com/
josevalim 6y ago
> The creator of Elixir mentioned it was doable to fix the issue but when an issue was open on GitHub[1] it was shot down with a "this is a known tradeoff, you'll need the 2nd route trip for the websocket" Please Nick, you can literally check your links to see this is inaccurate. I mentioned a solution after the issue was closed - and not before as you describe. And I figured out the solution *with Chris*, as I clearly mention in my comment. And then later on: > dive into the source code that I can't read very well because there's a lot of macros There are like 8 macros... > since LV is a pre 1.0 release the docs aren't really written up yet since stuff is changing all the time Seriously? No one has ever said this is the case. Just go to the [official docs](https://hexdocs.pm/phoenix_live_view https://hexdocs.pm/phoenix_live_view). All public functions are properly documented, there are introductory guides, etc. Sure, we don't have official screencasts but that's something we rely on the community to step in: Pragmatic Studio has a fantastic course on LiveView (which I was involved as a sounding board), there is Grox.io, etc. And it hasn't stopped either, a new book was literally announced today. There are other inaccuracies in the comments below but honestly I don't have the energy to go down this rabbit hole again.
- nickjj 6y ago
  > There are like 8 macros... I should have used quote / unquote instead of the word macro. When I looked into the code I started with the engine and renderer. Between both modules they had dozens of quote / unquote usages which to me was hard to follow. Not because it's written poorly or anything like that, but it's not exactly easy to trace that code to learn how something works in more detail. > I mentioned a solution after the issue was closed - and not before as you describe. Yes, after it's been closed. But look at it from what end users of your library see from that chain of events: 1. User asks question on forums and presents a case where something very bad happens (2x network round trips) 2. User posts issue on GitHub 3. Creator of LV says it's a known trade off and quickly closes the issue 4. You and the creator of LV talk offline and figure out a potential work around Re-opening the issue after #4 would have done a lot of good because it shows at a glance that it's a current issue, it's being addressed and open for discussion. With the issue being and staying closed this gives off a message that you're not actively working on fixing the bug and aren't open to any form of discussion or assistance around fixing it. Maybe that wasn't your intention but that's the message you're sending to some people. > Seriously? That's the answer I've always received in the past when asking questions about the state of the docs on Slack and IRC over the years. The current docs usually give you a partial understanding of how something works. It's usually enough to get a basic idea of how something might work but not enough to get the ball rolling to implement a solution in your own application. I don't think I'm the only one who feels this way either because I've seen a lot of repeated questions on IRC and the forums, especially around LV components.