> We could probably add some SSG functionality very easily, but it’s just not that compelling when you can run your app at the edge for pennies. I mean seriousl

> We could probably add some SSG functionality very easily, but it’s just not that compelling when you can run your app at the edge for pennies. I mean seriously. You sacrifice so much flexibility when you prerender everything. But when you’re running your app at the edge on CF workers you can have SSG speed without sacrificing the flexibility of SSR. Kinda true, except that with no focus on cache hit rate and no discussion of (for example) pre-warming HTTP caches, this is mostly unrealized for a large class of websites. When you’re running on a CDN with a large number of nodes (like Cloudflare), with a lot of dynamic pages that change frequently, and a geographically broad visitor base, you’re likely to have a bad cache hit rate in production. And the trouble is you won’t really notice it for your demo tweets, because you’re gonna get mostly cache hits from your own CDN node. There have been demo tweets from Remix (and other similar frameworks too, I suspect) that boast about their 50ms response times and attribute that to computing at the edge, but really they’re just setting a generous max-age and getting a 50ms cache hit from the traditional CDN (not edge compute) node. One such demo I saw on Twitter had a much more bog-standard React SSR response time of more like 350ms when you get a cache miss. At that point you’re not getting anything from Remix related to “edge compute” other than maybe the slightly reduced network latency from server to client (but that’s unlikely to matter much when it’s 300ms to do the React SSR render).