[googledocsftw]

1. Lots of dead ends. Fetch cache limit for example. Cant replicate prod page caching behaviour in dev. Etc. Many issues with 100 thumbs get abandoned.

2. NodeJS. Not everyone likes it.

3. It is slow. Yes it is! Try to get good web metrics with Next I dare you!

4. Premature release of App Router. Will they do something like that again.

[doctorpangloss]

I appreciate that you’re getting to the crux of the matter instead of downvoting.

In our experience elevating the web metrics in Next.js takes the same expertise as doing it in any other framework. Our experience with Vertx and Microsoft’s dotnet web frameworks have been good, but Next.js got us to a fast, featureful, performant website sooner and with more flexibility around requirements. I won’t pass judgement on rust frameworks I haven’t used, but it’s just to say that in an honest accounting, a naked backend framework is less than half the product when you’re talking about web applications actually worth making with original ideas. Unless you work at Google.

[googledocsftw]

Ok I will bite. How did you manage to get scripts to defer?

[doctorpangloss]

Code that we need later is `async import`-ed.

But for SEO, shouldn't Google be given a 100% pre-rendered, essentially static page? Next.Js plus our CloudFront seems to just support this.

[nopeYouAreWrong]

why are you fealung with cache at all in a wrb context? that's what CDNs are for.

[googledocsftw]

React, like Haskell creates new problems you need sophisticated solutions for.

CDN is for content. Useless for say a Google search type problem. So I call an API endpoint for data in my component. But what if I get rendered 600 times? Well luckily I have memoized the call! As long as it was under 2Mb that is.