Why we ditched Next.js and never looked back

Summary

In this video, the speaker discusses their decision to ditch Next.js despite its initial appeal. After extensive use on platforms like *foron* and *codam*, they found the constant changes in Next.js’s philosophy and performance issues at scale to be problematic. They highlight concerns about vendor lock-in with Vercel and argue that for larger-scale projects, Next.js became bloated and slow. The speaker ultimately opted for a custom React stack to gain more control over their tech stack, suggesting that while Next.js works for small sites, it might not be the best fit for those looking for scalability and flexibility.

Takeaways

• 😀 The speaker discusses their experiences with Next.js and how it was used extensively in their platforms, Foron and Codam.
• 😀 The decision to use Next.js initially was based on the tradeoffs between SSR (Server-Side Rendering) and SPA (Single Page Application) performance, especially for real-time data-heavy apps.
• 😀 The speaker critiques Next.js's shift in philosophy, particularly moving from JAMstack to SSR, then to serverless, and now to micro VMs.
• 😀 The use of SSR for every page load can lead to slower performance, while SSG (Static Site Generation) combined with caching results in faster speed.
• 😀 The speaker disagrees with the current approach of Next.js and its parent company, Vercel, regarding the integration of React App Router and React Server Components (RSC).
• 😀 The recommended architecture for a web app involves decoupling the front end (served at edge locations globally) from the back end (which can be centralized), offering faster speeds and scalability.
• 😀 Vercel's cloud-based platform (Worel) creates vendor lock-in and poses a risk to consumers due to its pricing and tight integration with Next.js, which limits flexibility.
• 😀 The speaker highlights performance issues when hosting Next.js apps at scale, citing slow page rendering and issues with caching and database calls when not using Vercel's platform.
• 😀 Despite issues, the speaker's platform Foron manages to run thousands of websites efficiently with Next.js, Cloudflare, and Vercel without significantly impacting costs.
• 😀 The speaker stresses that Next.js might be suitable for small websites but may not be the best choice for large-scale projects with requirements for high performance, SEO, and full control over the tech stack.
• 😀 While Next.js has some positive engineering aspects, the speaker criticizes its complexity, bloat, and shifts in philosophy, and prefers building software from the ground up for more control and stability.

Q & A

What was the initial reason for choosing Next.js?

Next.js was initially chosen because it was a solid framework for server-side rendering (SSR), which works well for marketing and documentation sites. The team had years of experience with both SSR and single-page applications (SPAs) and saw Next.js as a good fit for their needs.

Why does the speaker think Static Site Generation (SSG) is better than SSR in some cases?

The speaker believes that SSG combined with caching offers better performance than SSR because it avoids the performance penalty of rendering a page on every request. SSG renders pages once and stores them on the edge, resulting in faster load times and reduced server load.

How does the speaker describe the evolution of Next.js's philosophy?

The speaker points out that Next.js's philosophy has shifted several times, from promoting JAMstack and static site generation to advocating for serverless and SSR. Recently, Next.js has shifted towards micro VMs, which the speaker sees as a move to lock users into their ecosystem.

What is the issue with Vercel, according to the speaker?

The speaker is concerned about Vercel's pricing and vendor lock-in. They note that Vercel's pricing can be expensive compared to alternatives like AWS or custom setups, and that relying on Vercel can limit flexibility, especially for larger businesses scaling their sites.

What performance issues did the speaker encounter with Next.js?

The speaker observed that basic page renders took 200-400 milliseconds, while pages with dynamic content could take up to 700 milliseconds or more. They noted that these issues could vary based on setup, but they preferred a setup that used SSG and caching to achieve faster page loads, often under 50 milliseconds.

How does the speaker’s setup differ from the Next.js and Vercel setup?

The speaker's setup uses SSG combined with caching at the edge, which allows for faster page loads. In contrast, Next.js with SSR can be slower due to the overhead of rendering on each request. The speaker's approach avoids relying on Vercel, instead using Cloudflare and other services for better performance.

What does the speaker think about Next.js and Vercel for scalability?

The speaker believes that Next.js and Vercel can be challenging for scaling, particularly if you're not using Vercel’s infrastructure. They emphasize the complexity of SSR and the difficulty of managing server setups on platforms like AWS or EC2 without relying on Vercel's managed service.

Why did the speaker decide to build a custom React stack instead of continuing with Next.js?

After encountering performance issues, integration challenges, and the need for more flexibility, the speaker and their team chose to build a custom React stack. This allowed them to have more control over their tech stack and avoid the complexity and vendor lock-in associated with Next.js and Vercel.

What are the advantages of using a custom stack over Next.js for the speaker’s use case?

The main advantage is control and flexibility. By building from the ground up, the team can optimize performance and scalability to their specific needs, without being tied to the constraints and frequent changes in Next.js and Vercel’s offerings.

Does the speaker think Next.js is completely flawed or unsuitable for all projects?

No, the speaker acknowledges that Next.js can work well for smaller sites and when used with Vercel's infrastructure. However, for larger, more performance-sensitive projects, or those requiring full control over the stack, Next.js might not be the best choice due to its complexity and the potential for vendor lock-in.