|
|
|
|
|
by therusskiy
1323 days ago
|
|
Try deploying NextJS yourself over multiple instances, you are soon going to learn that cache NextJS provides isn't shared across them via something like Redis (I think it's mostly shared on Vercel, but I don't know how they do it). Aside performance, this has consequences because of their stale-while-revalidate technique for static pages in incremental regeneration. If cache becomes obsolete on 1 instance and it's revalidate on the next request, it's not revalidated on other instances, so users accessing them are going to see stale data until that instance itself does revalidation. Having even a percentage of pages showing stale data can be painful for certain scenarios. NextJS users been asking for more flexiable caching for some time. I think it's a pretty good example. As for forking it, how many companies have enough resources and are willing to go that distance? |
|
As for the forking it comment, that's exactly the point. Vercel is investing heavily into NextJS, spending millions of dollars on hiring full time developers to work solely on it, and they give NextJS away for free. So having the best Next experience on the platform that they own and control and can fine tune makes sense to me. Nobody is forcing you to use NextJS or any other library.