5 ms·

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 rende

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.

TylerE 4y ago
What about stuff like Phoenix LiveView, which can push dozens of updates per second per client to hundreds of clients simultaneously?
- doliveira 4y ago
  I actually find it sad that this passes as "impressive" these days
  - TylerE 4y ago
    I mean, this is on a single core, not a cluster.
    - switchbak 4y ago
      According to Wikipedia: "The term C10k was coined in 1999", and we've been discussing the C10M problems for years now. 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.
      - TylerE 4y ago
        Did you miss the hundreds of clients bit? So we're talking several thousand responses per second per core. I think that's fairly impressive, and VERY different from an FTP server connection that isn't really doing much most of the time.
    - doliveira 4y ago
      Even then, the heavy lifting of pushing the dozens of updates is mostly in the kernel, isn't it? 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.
      - TylerE 4y ago
        I find that sort of reasoning rather hollow. 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
        doliveira 4y ago
        I don't have objective stats, but I'd bet a substantial part of my income that none of these things even come close to 1% of the resource usage.
        TylerE 4y ago
        Good hashing algorithms can be pretty cpu intensive.
        doliveira 4y ago
        You're talking about the algorithms for TLS? Or hashing as in hashing a lot of things in your application? 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
        4y ago
  - fxtentacle 4y ago
    Agree. Back in he day, people were discussing how to put 10k connections into a single core FTP server.
- anonyfox 4y ago
  Well it’s a completely different technology compared to JS‘ spa/ssr approach, but in most cases (latency is not too bad) vastly superior: perceived and real performance is „instant“, the code amount is smaller, less and more robust libraries involved. 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.
- ksbrooksjr 4y ago
  The obvious downside to Liveview is that all of the UI state resides on the server. Every UI update therefore requires a full roundtrip request to the server, and so reducing latency is of paramount importance. That's why fly.io is so heavily invested in the Phoneix ecosystem, because their service is predicated on the idea of distributing your app globally to reduce latency. A React/Angular/Vue spa on the other hand can make decisions about how to update the UI without contacting the server. In fact, many PWAs these days are actually designed to work completely offline.
  - cultofmetatron 4y ago
    > Every UI update therefore requires a full roundtrip request to the server, 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.
    - ksbrooksjr 4y ago
      Yeah you can definitely pull in Alpine for UI updates that don't require any server side interaction, but then your app's logic is fragmented between different frameworks (Alpine and LiveView). 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.
      - mattste 4y ago
        I agree heavily with this assessment. 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 https://gleam.run) to be used to compile to both Javascript and the BEAM.
jsguy 4y ago
The main reasons (IMHO) to have SSR are: * 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.
steve_taylor 4y ago
Next.js can do ISR (incremental static regeneration), which essentially gives you the same result as a CDN in front of SSR. Having said that, in most cases you should use a CDN.
- dbbk 4y ago
  Eh, in that case you're still sending all requests to one Node server. I think it'd still be preferable to have a CDN so that it can be served from the edge. Also, you can achieve this behaviour on CDNs from a full SSR response with just using stale-while-revalidate in the Cache-Control header.

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.

TylerE 4y ago

What about stuff like Phoenix LiveView, which can push dozens of updates per second per client to hundreds of clients simultaneously?

doliveira 4y ago
I actually find it sad that this passes as "impressive" these days
- TylerE 4y ago
  I mean, this is on a single core, not a cluster.
  - switchbak 4y ago
    According to Wikipedia: "The term C10k was coined in 1999", and we've been discussing the C10M problems for years now. 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.
    - TylerE 4y ago
      Did you miss the hundreds of clients bit? So we're talking several thousand responses per second per core. I think that's fairly impressive, and VERY different from an FTP server connection that isn't really doing much most of the time.
  - doliveira 4y ago
    Even then, the heavy lifting of pushing the dozens of updates is mostly in the kernel, isn't it? 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.
    - TylerE 4y ago
      I find that sort of reasoning rather hollow. 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
      - doliveira 4y ago
        I don't have objective stats, but I'd bet a substantial part of my income that none of these things even come close to 1% of the resource usage.
        TylerE 4y ago
        Good hashing algorithms can be pretty cpu intensive.
        doliveira 4y ago
        You're talking about the algorithms for TLS? Or hashing as in hashing a lot of things in your application? 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
        4y ago
- fxtentacle 4y ago
  Agree. Back in he day, people were discussing how to put 10k connections into a single core FTP server.
anonyfox 4y ago
Well it’s a completely different technology compared to JS‘ spa/ssr approach, but in most cases (latency is not too bad) vastly superior: perceived and real performance is „instant“, the code amount is smaller, less and more robust libraries involved. 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.
ksbrooksjr 4y ago
The obvious downside to Liveview is that all of the UI state resides on the server. Every UI update therefore requires a full roundtrip request to the server, and so reducing latency is of paramount importance. That's why fly.io is so heavily invested in the Phoneix ecosystem, because their service is predicated on the idea of distributing your app globally to reduce latency. A React/Angular/Vue spa on the other hand can make decisions about how to update the UI without contacting the server. In fact, many PWAs these days are actually designed to work completely offline.
- cultofmetatron 4y ago
  > Every UI update therefore requires a full roundtrip request to the server, 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.
  - ksbrooksjr 4y ago
    Yeah you can definitely pull in Alpine for UI updates that don't require any server side interaction, but then your app's logic is fragmented between different frameworks (Alpine and LiveView). 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.
    - mattste 4y ago
      I agree heavily with this assessment. 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 https://gleam.run) to be used to compile to both Javascript and the BEAM.

jsguy 4y ago

The main reasons (IMHO) to have SSR are: * 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.

steve_taylor 4y ago

Next.js can do ISR (incremental static regeneration), which essentially gives you the same result as a CDN in front of SSR. Having said that, in most cases you should use a CDN.

dbbk 4y ago
Eh, in that case you're still sending all requests to one Node server. I think it'd still be preferable to have a CDN so that it can be served from the edge. Also, you can achieve this behaviour on CDNs from a full SSR response with just using stale-while-revalidate in the Cache-Control header.