[swe_dima]

My concern with NextJS is that they aim to do work that's good for Vercel and not for developers. That's why we see such a push for faster build times while severally restricting flexibility of the framework, so they can save money on VMs running user's builds.

[geewee]

This seems sorta weird to me. Do you as a developer not enjoy having faster builds? I sure do.

[CharlieDigital]

The problem is that particular type of slippery slope mindset.

What if some next big change doesn't align with the best interest of the community?

You can see some future parallel to Microsoft and the `dotnet watch` debacle[0] where the dotnet team introduced a feature to allow hot reload then some executive neutered it except for Visual Studio because "it wasn't stable yet".

No one will know the true reasons why it was pulled (and then re-released after community outcry), but it left a sour taste in the community. And in the case of Microsoft, I think they have even smaller incentives to pull this kind of stuff (VS is a very tiny, tiny portion of their revenue compared to Azure and Office) whereas Vercel is much more tightly bound to Next.js so it seems inevitable that there will be a point in time when Vercel's interests comes to loggerheads with the community's best interest.

It may seem far-fetched right now, but all you need to do is look at the HTML source for Target.com and Walmart.com and see how a corporation has created tremendous leverage under the guise of OSS. The obvious outcome is to use that leverage at some point in the future to extract capital. The fact that they built something novel instead of embracing an already really good community solution (Vite) smacks of creating leverage in the same way that Apple has been empowered by their walled garden platform ownership.

I trust Evan You far, far more than I do Vercel to make decisions in the interest of the community.

[0] https://dotnetcoretutorials.com/2021/10/23/the-hot-reload-de...

[bryanrasmussen]

depends, if like say one build is 3 seconds and the other build is 1 second, I prefer the 1 second, but if it turns out that the 3 second build is more easily debuggable and understandable then I would gladly sacrifice 2 seconds.

If one build is .75 of a second and the other build is 1.5 seconds I probably wouldn't consider the .75 of a second a significant improvement because I would probably not gain anything from the slight improvement.

I'm sure you can construct lots of other examples whereby one my prefer a less faster build over a faster build or just feel that it was not actually important either way.

[adoxyz]

Can you give examples of times NextJS was changed to solely benefit Vercel?

NextJS is an open-source framework under the MIT license, so if Vercel ever did anything to compromise NextJS, it could just be forked, but to my knowledge and experience with NextJS, they've provided and continue to provide an awesome framework/ecosystem around React.

[therusskiy]

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?