6 ms·

> Not really, because any JS/HTML logic that you have needs to be downloaded into memory and compiled and interpreted by each client independently I see my que

• presentation 5y ago
  Yes it’s cheaper but also it’s a worse experience. It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same.
  • nawgz 5y ago
    > It’ll take longer for a user’s crappy android phone to render your page from source than for a beefy cloud server on the edge to do the same. Yes, if you pay more money and integrate into cloud vendor systems, you can get more compute. Besides, the person with a crappy android is irrelevant to monetizing your application anyways, so their user experience is pretty irrelevant surely? I don't really understand the idea to spend money to improve the experience for people unlikely to spend money on your thing. And, again, the "beefy cloud server" experiences load from a shared user pool, so I doubt there's just flawless performance waiting for everyone all the time; if there is, surely you see "loss leader" written all over it.
    • presentation 5y ago
      - depending on use case you don’t need to pay much to get these perf benefits (eg caching snapshots on CDNs) - monetization depends on your business. How about B2B where customers are employees using crappy corporate laptops. Not like the only high value customers are using high end computers. - and besides maybe you have ethics and don’t want to lock out people who don’t have the latest high end gear. - flawless isn’t the point, better is the point
• chrisco255 5y ago
  > Sure, but the first hit would've been a cache hit anyways. Similarly, a serverless function that is "warm" already has all the logic needed to inject the static template into memory. It simply needs to call out to the database, which is physically closer to the server, and always quicker, without the need for an additional HTTP handshake...and then inject the data into the template, before sending it down the wire. > CDN would have the static bundle "at the edge" already for you. The static bundle just saves on download time. The bundle still needs to be loaded into memory on the client to create the Document Object Model that powers every webpage. Depending on how your client-side bundle is structured, it may be 100ms or 1s before it even begins to make the outbound request back to the API to fill in the necessary data to power your BI dashboard or whatever your use case is. And that's if your BI dashboard was structured to be optimal with all requests rolled up into one (additional architectural effort, easier to satisfy on SSR with multiple database hits having less impact to performance). Edge functions like Cloudflare Workers have 0ms cold starts. We're talking tiny fractions of a penny per request. For example, Cloudflare Workers have 100K free requests per day and then its $0.15 / 1 million requests after that. Better user experience, and it might cost you pennies more per month vs. static + round-trip.
  • nawgz 5y ago
    > Similarly, a serverless function that is "warm" already has all the logic needed to inject the static template into memory Sure, I accept this. > It simply needs to call out to the database, which is physically closer to the server, and always quicker, without the need for an additional HTTP handshake I contest all three parts of this. * physically closer How can this be guaranteed? You have no control over the closest Edge function vs Cloud Server to the user. It's just as likely your Edge function is farther away from the Cloud Server than the user is, from my view. Perhaps your cloud provider is offering you routing services you claim are superior, but given the nature of my questioning is anti-vendor-lock-in you'll understand I mostly disregard that. * always quicker How can this be true? The user's machine is quite nicely guaranteed to be somewhat available for the compute here - they issued the request themselves after all. Your machine, on the other hand, has a good chance of cold starting for this request or being hot because a bunch of other requests are being issued to it simultaneously. Given we have async steps in what the SSR is doing, backpressure from sharing resources with other users sounds worse than what we risk with a client machine. * without the need for an additional HTTP handshake Again, your Edge function seems likely to either be cold or busy, so this is only something you can speak about probabilistically > The bundle still needs to be loaded into memory on the client to create the Document Object Model that powers every webpage HTML still needs to render a DOM, not sure you're hitting on the right points of the parsing... Plus if this page is meant to be interactive still, you've not gained anything with the initial SSR phase > Depending on how your client-side bundle is structured, it may be 100ms or 1s to fill in the necessary data It's just not a big deal, and it's laughable you'd make the example a BI dashboard because you rendered something nice for them initially in maybe 0.5s faster on a median request, in exchange for literally enormous complexity. But a BI user is probably going to be in there for a long time, interacting heavily with client-side JS you shipped and they had to parse and render and then also reconcile/hydrate > easier to satisfy on SSR with multiple database hits having less impact to performance). How is this easier to satisfy on SSR? You have minimal advantage on your Edge worker being closer to your database than the user, unless your Edge function is actually just sitting beside your database server. It has to make the same requests and transfer the same data the client would be transferring in order to perform this SSR, there are only savings here if your Cloud provider is offering you big vendor lock-in promotions. > Better user experience, and it might cost you pennies more per month vs. static + round-trip. > Cloudflare loss-leader pricing Unconvincing.