Next.js exists to solve a problem that plain React cannot: React by itself only renders in the browser, which means a search engine or a slow phone first downloads a blank HTML shell, then a large JavaScript bundle, then finally sees content. This hurts SEO, slows the first paint, and forces every developer to hand-build routing, data fetching, and server rendering from scratch. Next.js is a full-stack React framework that bakes these concerns in. The App Router, introduced in Next.js 13 and now the recommended default, reorganises an application around the filesystem: a folder becomes a route, special files like page.js and layout.js define what renders, and components run on the server by default so the browser receives finished HTML instead of an empty div waiting to be hydrated.
25 minintermediate
Introduction to Next.js and the App Router
Analogy🏏Cricket
🏏 Think of it like cricket: Picture a Test match where, before the openers walk out, the curator has already prepared the pitch, the umpires are positioned, and the scoreboard is live — the players just play. Plain React is like arriving at an empty ground and being told to roll the pitch, set the field, and wire up the scoreboard yourself before a single ball is bowled. Just as the prepared ground lets the batsmen focus on batting rather than groundskeeping, Next.js prepares routing, rendering, and bundling so you focus on features rather than plumbing. Just as the live scoreboard shows runs the instant a shot is played, server rendering hands the browser finished HTML the instant the page loads. And just as every Test follows the same agreed laws so any team can play anywhere, the App Router's file conventions mean any developer can read the folder structure and instantly know the routes. This reveals why Next.js wins on large teams: shared conventions remove the guesswork that custom setups create.
Lesson 1 of 35
0% complete