I've found that SSR is generally quite slow. If you're using it, you'd want a CDN or some other caching layer in front of your server so you don't need to render each page server-side.
* SEO capabilities * Faster response for first page load
And for both of those, a CDN is useful, if not essential - you're missing out on a lot of performance boost if you don't.
Other reasons to have SSR include things such as unfurling, where a CDN isn't essential, but still nice to have.
Also, you can achieve this behaviour on CDNs from a full SSR response with just using stale-while-revalidate in the Cache-Control header.
while this is certainly the easiest path, you don't HAVE to put all your ui states on the server. its trivially easy to plugin alpinejs for small ui state stuff that is all client side.
Another huge benefit, the js escape hatch lets you create a bidirectional bridge between your custom js and your user's liveview instance.
It's definitely doable, and I know the PETAL stack (Phoenix Elixir Tailwind Alpine) is super popular, but it's nice (and perhaps less error prone) to have all of your UI logic handled by a single framework. This consolidation of UI code under a single framework was one of the killer features of SPAs initially. Prior to that lots of sites were built with a server side templating framework with jquery sprinkled in for client side UI updates.
I think there is room for a framework similar to Phoenix LiveView but also allows compiling certain interactivity to the client. Next.js and Remix are kind-of fulfilling this but they have downsides.
In the BEAM ecosystem, I think there is room for [Gleam](https://gleam.run) to be used to compile to both Javascript and the BEAM.
There was actually a developer working on a subset of Elixir that compiles to JS called Elixirscript[1], but development seems to have stalled. Another functional statically typed compile-to-js language which targets the BEAM vm is Purescript through the Purerl project [2].
If you're going to compile to JS though, there's an argument to be made that you might not want to target the BEAM at all. You could potentially run your entire backend on something like Cloudflare Workers, which has over 200 points of presence around the world, so latency is about as low as possible. The other CDNs have their own competing worker runtimes as well (e.g. Cloudfront functions, Netlify functions, etc.). These edge worker runtimes also have the benefit of not charging for each individual region in which you operate. You can also run any language which compiles to WASM like Rust, Assemblyscript, or Grain [3] on these edge runtimes. The only missing piece for me is a distributed database, but it looks like Cloudflare at least is working on that [4].
[1] https://github.com/elixirscript/elixirscript
[2] https://github.com/purerl/purerl
Disadvantage: the individual components are not as nicely packaged up with markup/css/logic in a single file and must be hooked up to the global socket explicitly.
Don't get me wrong, it's pretty good and just the fact that you're pushing these stats reflects quite well on my (external) impression of Phoenix: most don't even bother to try and just resort to "hardware is cheap".
It's just that this should be the default. Reminds me of this tweet from @SwiftOnSecurity:
> Once you understand your computer has 16 cores running at 3GHz and yet doesn't boot up in .2 nanoseconds you understand everything they have taken from you.
Yea, it’s easy to right simple fast software when you only target English, and don’t have to care about Unicode, i18n, security, or any of a billion other things modern systems offer
Either way, I stand by my bet. They're irrelevant compared to the cost of the prevailing mentality of DX over anything else. Combined with the industry leaders having machines with 128 GB of RAM on 10 Gbps connections, this mentality guarantees software gets slower way more than hardware gets faster
Clearly this is doing a lot more work than serving static content, but .... dozens per second? Even per-core, that's a shockingly low number.