I'm a bit skeptical of Rails performance with the method the author details here, given that Ruby is much, much slower than Elixir.
I'm curious if even Elixir folks deploy Live Views in consumer-facing apps. But I can totally see it being used for admin interfaces or internal applications, for sure.
The method used in the blog post is making an ajax request to the server and then displaying the results in a div. For comparison, GitHub is running Rails and when you type into its search box it's making an ajax request to the server and displaying the results in a div.
Just wanted to bring that up here because this is different than what Live View does or what using Turbo Streams would do to broadcast changes over a websocket connection if you were using Rails.
I don't know of anyone running a large scale app using Live View as a primary focus but I did chat with someone on my podcast about how they used Phoenix and Live View to build https://textdb.dev. That episode is at https://runninginproduction.com/podcast/68-textdb-is-a-simpl.... TextDB trended here on HN a few months ago at https://news.ycombinator.com/item?id=23948234. It handled the HN front page load without issues, but it's also not doing a ton.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
In this case, the main advantage is that scaling is stateless, so your application servers just have to be able to deal with more traffic. There is nothing more to it.
As for Phoenix LiveView, it has both advantage and disadvantage of being stateful (something as using Action Cable). You now have to be scaling web sockets, but you save on authenticating the request (the request is lighter).
Even if LiveView is stateful, it's done on the platform which is optimized exactly for this purpose.
In both approaches, you also have to take into account that server latency might be a deal breaker for you.
Overall I'm a fan of what they're trying to do with Hey.com, but this particular use case feels like a big UX miss to me.