Next packaged React into full frontend
Lenny Bogdonoff, co-founder and CTO of Milk Video, on the past, present and future of Javascript
Next won because it turned React from a great app library into a practical way to build the whole web front end. React had developer mindshare, but plain React left teams to solve routing, server rendering, static generation, and SEO on their own. Next packaged those jobs into the default workflow, so the same team could use shared React components across the product, marketing site, and blog without stitching together separate stacks.
-
Gatsby helped popularize Jamstack, but it was built around a more opinionated static site workflow, with heavy plugin use and a GraphQL layer aimed at large content sites. Next spread faster because it fit the broader React app workflow instead of forcing teams into a separate content centric architecture.
-
The practical unlock was performance and deployability. Teams could pre render pages for search engines, add server rendering when needed, and keep fast local iteration. That made Next useful for both brochure sites and real applications, while Gatsby was described as slowing down as sites got large.
-
This also explains Vercel’s position. By owning the framework and the hosting path, Vercel could make previews, rollbacks, env vars, analytics, and deployment feel native to React teams. The framework became the acquisition channel, and the hosting product became the monetization layer.
The direction from here is deeper consolidation around frameworks that remove setup work for front end teams. Next is strongest when companies want one React based system for app pages, content pages, and lightweight backend glue. As long as it keeps builds fast and the workflow simple, framework share will keep pulling infrastructure share behind it.