7 ms·

I believe both are used for customer facing applications. However, I am not sure about b2c at scale. You could argue that Hey.com is b2c. In this case, the mai

I believe both are used for customer facing applications. However, I am not sure about b2c at scale. You could argue that Hey.com is b2c. 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.

Sodman 6y ago
Some anecdata as a hey.com user myself: It feels like they've optimized a lot for initial load of the main homepage (The "Imbox"). Obviously this is super important for an e-mail app... but once you start trying to load anything older than the most recent ~20 e-mails (Eg scrolling "The Feed"), then the load times can be horrifically slow (>10s, followed by a janky pop-in of HTML suddenly loaded). I'm not sure if this is caused by this technology in particular or if there's some kind of cache miss happening here, but coming from and comparing to gmail - which hey's makers like to dump on regularly - the performance is miserable. Sure, the number of transferred bytes is small and there's not a lot of JS to load - both of which I'm a big fan of, but the actual load time that I feel as a user is pretty bad for these AJAX calls. 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.