"Server rendering is stupid. It's only there to increase bills by cloud providers" Increasingly tired of seeing this sentiment so I'm going to explain why this is a really dumb take. 1. SSR costs are low The cost of turning JSON into HTML is not particularly large. Most SSR
Longposting inspired by @DevinNash
@DevinNash Decided to turn it into an actual article (I should post on my blog more in general) https://t3.gg/blog/post/ssr-is...
@theo I think you might have simplified too much and removed an important nuance. SSR with modern meta frameworks will cost you around 10-20ms of CPU time, while the DB calls will be idle. The two are the same only if your code is deployed on Lambda (or old school Vercel), where you
@theo If your auth and basic db calls are taking more than a few ms… ur doing it wrong.
@theo agree but db queries should be single digit milliseconds at most
@theo 200ms for DB Query is A LOT. Either fix your queries/indices, or move your server closer to the DB.
@theo I agree with the general sentiment but why tf are we normalizing “basic database calls” taking 200ms? Postgres can respond in less than 1ms, especially with basic queries.
@theo Please get started on revalidation
@theo If your database queries take 200ms+ on basic queries you have bigger problems than SSR vs client side
@theo (Not trying to start flame wars, trying to disagree better) Many of these questions seem like they require fullstack JavaScript to truly be better in every way ™️? If my API is in Python and I'm pushed into the backend-for-frontend path of current SSR React, aren't I still
@theo based + why are your db queries so slow
@theo People will lean this in time Beyond a CDN, the only thing that matters is your compute is close to your storage 100ms is the bar for interactions
@theo Do you see folks grasping for ssr for the wrong reasons though? Frequently what I’ve seen is it’s ssg that they really need and use ssr because it’s “easier”.
@theo It is one of the dumber things I see the children on this website say. Tell em
@theo Nuance and a lot of “it depends” on both sides of the argument
@theo Yes. SPA only devs are juniors
@theo Finally, somebody wrote it. Thanks Theo!
@theo So I shouldn't mark pages in Next.js as "use client"?
@theo No blog RSS feed 😰
@theo Good read. I agree. You can make the shell static and anything dynamic can save $ with SSR, as well as better manage and mutate data.
@theo you are doing something very wrong if a basic DB query is taking 200ms…
@theo 20ms is an eternity when we're talking about main-thread-blocking compute on the server side, enough to bring throughput down to double digits (50 vs 10000+ for most JSON API servers since they barely do any main thread compute). And 20ms is a rather optimistic estimate for the
@theo > Render times in modern frameworks like Next.js are measured in milliseconds, rarely breaking 20ms. Hey, did you know 20ms to render a single frame is actually very slow? I guess you're forgiven for the first frame, but is that what we're talking about here?
@theo For SSR you can make *one request* if your backend serving the frontend has all the data. If you need it from multiple services, you have the same overhead happening on a billed by the second resource instead of freely on the users machine. Same problem of throwing a “static
@theo “A basic db query” will not take 200ms. Modern infra platforms where compute is serverless and db is queried via HTTP API to another data center have made people believe that. It’s 2 orders of magnitude off.
@theo Sadly, there is no good distributed database. PlanetScale and Neon are overpriced. D1 still lacks read replica. Not sure how DSQL's pricing.
@theo Why is it taking you 200ms to parse a JWT? Are you using Ruby or something?
@theo It does not save you money. Especially if you’re doing a high traffic project. Sure for small/medium maybe. For large projects that take a lot of data in let’s say getSSRProps you’ll pay a lot more, just for some SEO benefits. Having one “pod” or scaling to 10, is expensive.
@theo I’m sorry but if your DB queries are greater than 10ms your not gonna make it
@theo If you can combine SSR and real-time updates of both HTML fragments and reactor signals you get the best of both worlds. If only there was a framework for doing that as a full SPA replacement, big if true
@theo People are unaware of the power of streaming with SSR and that you can do everything in one request and change the HTML in streaming time to show skeletons and then the content
@theo Then we have this insight from a helpful HN user.
@theo Client side rendering is like having an unlimited number of free distributes computers working for your company. But I do like the simplicity of ssr
@theo 20 ms is like 20 frames a second? For what, displaying a simple UI? No wonder that all browsers run like shit nowadays if you all think it's "low" for rendering UI. This kind of stuff, even for complex UI should not ever take more than 1 ms