As a long-time Next.js user, I'm deeply disappointed by the way Vercel (the company, fka Zeit) has so tightly coupled vercel (the platform / hosting service, fka 'Now') with Next.js (the framework). I absolutely loved Zeit (the company, before it was rebranded Vercel), with its amazing DX-first ecosystem. But now, to the detriment of it all, only those specific patterns of Next.js usage that align perfectly with the vercel hosting platform's opinionated approach are treated as first-class citizens. Vercel the company makes its money from vercel the hosting platform, and it employs all the Next.js maintainers. As a result, simple economic incentives have shaped the framework, making it much more rigid and limited than it'd otherwise be.
Examples include:
- proper support for "12-Factor App"-style immutable build artifacts, deployable to multiple envs (eg DEV, QA, STAGE, PERF, UAT, PROD). The way .env files are handled makes this incredibly cumbersome. Vercel only supports (local development) + (preview deploys) + (production), so for anything outside that tri-fold paradigm you're on your own.
- removal of support for custom servers
- reliance on unofficial 3rd-party serverless framework to support deployment to Lambda@Edge, and problematic or missing documentation for any non-Vercel serverless deploy target
I still think Next.js per se is pretty great*, but in my direct experience working with consulting clients to leverage it in their non-Vercel, multi-environment infrastructure, the pain points are significant and caused largely by the coupling I described.
If you embrace vercel as the hosting platform, with its specific conventions and limitations, and can accept severe vendor lock-in, then sure, it's going to be a pretty smooth ride.
*For my part, when it comes to picking a React-based framework that provides SSR / BFF, Remix.run is looking better and better all the time.
As a long-time Next.js user, I'm deeply disappointed by the way Vercel (the company, fka Zeit) has so tightly coupled vercel (the platform / hosting service, fka 'Now') with Next.js (the framework). I absolutely loved Zeit (the company, before it was rebranded Vercel), with its amazing DX-first ecosystem. But now, to the detriment of it all, only those specific patterns of Next.js usage that align perfectly with the vercel hosting platform's opinionated approach are treated as first-class citizens. Vercel the company makes its money from vercel the hosting platform, and it employs all the Next.js maintainers. As a result, simple economic incentives have shaped the framework, making it much more rigid and limited than it'd otherwise be.
Examples include:
- proper support for "12-Factor App"-style immutable build artifacts, deployable to multiple envs (eg DEV, QA, STAGE, PERF, UAT, PROD). The way .env files are handled makes this incredibly cumbersome. Vercel only supports (local development) + (preview deploys) + (production), so for anything outside that tri-fold paradigm you're on your own.
- removal of support for custom servers
- reliance on unofficial 3rd-party serverless framework to support deployment to Lambda@Edge, and problematic or missing documentation for any non-Vercel serverless deploy target
I still think Next.js per se is pretty great*, but in my direct experience working with consulting clients to leverage it in their non-Vercel, multi-environment infrastructure, the pain points are significant and caused largely by the coupling I described.
If you embrace vercel as the hosting platform, with its specific conventions and limitations, and can accept severe vendor lock-in, then sure, it's going to be a pretty smooth ride.
*For my part, when it comes to picking a React-based framework that provides SSR / BFF, Remix.run is looking better and better all the time.
reply