Guillermo Rauch — Client rendering, server rendering, pre rendering

Thank you so much for that fantastic introduction and thanks to Tania and Dimitri for having me here. As the founder of Zeit, now Vercel, our mission is to empower the front-end developer to build and deploy powerful applications. It's great to be here at Holy JS because JavaScript is the lingua franca of the internet, enabling the transition to rich, client-side web applications. However, developing with JavaScript involves a lot of complexity: static rendering, server-side rendering, streaming. I want to discuss 'There is No Silver Bullet,' a famous paper by Fred Brooks. It argues there's no single 10x technology or methodology. It distinguishes between essential complexity—inherent to the problem—and accidental complexity, which we add ourselves. In the JS world, we've dealt with significant accidental complexity. Next.js was created in 2016 to address this by removing the need for complex configurations like Webpack or Babel. We used the file system as an API to make projects easier to explore and navigate. While we've reduced accidental complexity like bundling and routing, we still need to solve essential complexities like data fetching and performance. We evolved from a purely server-rendered approach to a hybrid model. Static site generation offers performance and security but struggles with long build times and scale. Server-side rendering (SSR) handles scale and SEO but introduces operational overhead and stability issues. JAMstack offers a middle ground but relies on client-side hydration. To bridge these gaps, we're introducing Incremental Static Regeneration (ISR) in Next.js. This allows pages to be generated at build time and then incrementally updated at runtime as traffic arrives. You get the benefits of static—performance, security, and availability—combined with dynamic data. Essentially, when building, you choose between a fully dynamic shell for interactive dashboards or pre-rendered static pages for critical content like blogs and e-commerce. Static has effectively become the new dynamic.

I'm so excited about that as well, thank you.

That's a good question. Next.js prioritizes convention over configuration. We've been conscious about not offering excessive customization because we believe in the strength of having standard conventions. It keeps the 'map for the territory' consistent across projects, making exploration much easier.

It's entirely up to you. You can compute every page if needed. For many, lazy loading on the client side for subsequent pages is a great approach.

The beauty of our new hooks is that you can make any API call that Node.js can support. For our blog, we use Notion as our 'brain.' We also love solutions like Contentful, Dato CMS, and Prismic. You can even query the Twitter API to generate static versions of tweet storms.

I think JAMstack will become the default for building web applications. What was necessary was to bridge the gap for critical pages where client-side fetching isn't acceptable for business metrics. Technologies like ISR are designed to capture almost 100% of use cases.

Progressive hydration is a great example. If booting up JavaScript takes too long, the experience fails. We're working closely with Google and the React team on progressive hydration and dynamic code loading. Once we have incremental hydration and smarter bundling, React will truly work for all use cases.

Absolutely. I'm excited by the proliferation of new frameworks like Svelte that take radically different optimization approaches. The 'worse is better' philosophy can lead to tremendous performance gains. I think we'll see a rise in visual, GUI-based tools for designing React or Svelte apps, where the developer acts more like a designer, managing suspensions and data loading tolerances.