[slimeboty]

thanks nickjj

"a stateless web app serving 100k requests on a tiny server and putting a CDN / caching layer in front of it"

That's a great question. For "live" stuff, it seems to me that Pheonix brings so much joy and simplicity, I'd happy pay for memory and hopefully scale in a sustainable way. This is all theoretical until we get a successful app, but it's good to see the future paths :)

[nickjj]

It's very useful but I also think (and this is strongly a personal opinion) that too much live components break the core ethos of the web.

For example, personally I don't want everything changing on my screen in real-time, I want to consume content on my own terms. When I want the content to refresh I will reload the page. Otherwise it creates too much distractions with the screen bouncing around and content changing under your feet that's out of your control.

I think you can tastefully update areas of a page where it provides very high value but that's IMO the exception not the norm. Of course if you want to build another Discord or a live chat (or something like LiveBeats) then sure that's great.

This idea of using WebSockets for everything (even transitioning pages) amplifies the issue even more, but I think it's ideal for things like notifications and what LiveBeats does for keeping the audio player in sync across clients. That's why I really like Hotwire as an alternative to Live View, it uses stateless HTTP for everything and you can still do partial page updates for the person who rendered the page. Then you can optionally opt-into using WebSockets when broadcasting events to more than the person who rendered the page. It's also back-end agnostic. You get the best of both worlds, being able to use HTTP for just about everything and then sprinkle in WebSockets for the real-time broadcasted events. This lets you continue using a tiny server + CDN without worrying about memory being hold onto for each process and you can opt into event broadcast functionality as needed.