Unifying App and Site with Next
Lenny Bogdonoff, co-founder and CTO of Milk Video, on the past, present and future of Javascript
Choosing Next reveals that the real win was not static site generation by itself, it was turning marketing pages and product surfaces into one React codebase. That lets a team reuse the same buttons, forms, layouts, and data fetching patterns across the main app and public pages, which cuts duplicate work, keeps the UI consistent, and lets front end engineers ship without rebuilding the same pieces in a separate website stack.
-
Next won over tools like Gatsby for teams building real apps because the component model stays close to plain React. A developer can keep writing normal app components, then choose per page whether it should be static or server rendered, instead of adopting a more specialized content site workflow.
-
This matters most when the product is already complex. Once a company has built a design system for its app, reusing those pieces on the website means the homepage, docs, onboarding flows, and logged in product can share styling and behavior, instead of drifting apart as separate codebases.
-
The broader shift was from pure static sites toward hybrid apps. Teams liked Jamstack for fast deploys and less server work, but heavier products often needed personalization and dynamic data. Next gained ground by keeping the fast front end workflow while adding server capabilities when static pages were not enough.
This points toward a web stack where the company site, app shell, and light backend logic increasingly live in the same framework. As more teams optimize for fewer handoffs and faster iteration, the winning tools will be the ones that let product code move easily between static pages, dynamic pages, and edge delivered experiences.