What is Next.js?

Background: what a web framework actually is

To understand Next.js, you first need to understand the general role that a web framework plays in the life and times of a developer. And to understand a web framework is to understand all of the crazy things going on behind the scenes when you load a web page. So what actually happens when you type mail.google.com into your browser 1 Technical readers will laugh at the fact that this is a common software engineering interview question; it was only a matter of time.?

I’ll save you the hassle of thinking about really low level stuff, like signals traveling through the air and everything. Here’s the basic gist of what’s going on:

1. You type mail.google.com into your browser and hit enter
2. The browser figures out which IP address that mail.google.com URL maps to
3. The browser connects (or tries to connect) to the server with that IP address
4. The browser requests the web page from the server via HTTP
5. The server responds with either the webpage, or a reason it can’t return the web page
6. The browser shows you the webpage, or why it failed

These are the main steps, give or take a few. DNS – the dreaded and feared system that connects the URL with the IP address of your app’s server(s) – is responsible for the first two steps. Where web frameworks fit in are steps 3, 4, and 5 – when the browser requests the web page that you want, and the server sends that webpage back to you.

This all may seem simple on the surface, but is actually very not simple. A developer starting an app from scratch often finds themselves wondering:

• How do I pick which file of code gets returned for different URLs?
• What happens if someone requests a web page that doesn’t exist?
• How do I organize different pages to be under different URL routes? (e.g. `mail.google.com/filters/filter-1`)
• How do I restrict certain pages to users who have signed in?

Your server needs to act like an air traffic controller, deciding which planes land, when, and where. There are constant requests coming in from all different types of planes needing all different types of things, and building all of the programming logic to handle it is a lot of work. This is where a web framework comes in: it gives you a nice, comfortable environment that has the building blocks to do all of these things for you.

Web frameworks are usually programming language specific, meaning that there will be different ones based on which programming language you want to use. A few examples:

• If your backend is in Python, you can use Django or Flask
• If your backend is in Ruby, you can use Rails or Rack
• If your backend is in Java, you can use Spring
• If your backend is in JavaScript, you can use Next.js, Angular, Meteor, so many…

If you use a framework like Next.js, there will be specific, codified ways of doing things; if you buy into their system, you can avoid all of the low level HTTP work and get apps up and running quickly. Each web framework has a different way of answering those questions above – some slightly different, and some very different – and which one a developer chooses is as much about their programming language of choice as it is about which answers they like and don’t like.

Opinionated web frameworks vs. general purpose web frameworks

In the universe of web frameworks, there are types that are more opinionated and less so. If picking a web framework is kind of like joining a club – you get structure and special privileges, so long as you agree to follow the rules – then opinionated web frameworks are clubs that have a lot of rules. Structure isn’t necessarily good or bad. The more you have, the easier it is to make choices and standardize on a good output. But if you don’t like the rules, you’re not going to have a good time.

To make this more concrete we can take a look at two popular Python web frameworks, Django and Flask. Django is an opinionated web framework, and Flask is an un-opinionated web framework. How does that manifest itself?

Django has a lot of rules:

• Files need to go in specific folders, or Django won’t recognize them or where to send them
• You need to create a specific file with a specific name to specify which URLs you want different web pages at
• To create web page templates, you need to follow Django’s specific syntax and file structure

But because those rules are so rigid, you can get a lot of value that you wouldn’t be able to get if you had complete flexibility. Django ships with a built-in admin panel for managing your user data and an ORM to play nice with your database of choice. Plus lots of other nice things like automatic sitemaps, an RSS feed, etc.

Flask, on the other hand, is not opinionated. You need to manually define every URL and what web page it maps to. You need to manually spell out every possible HTTP method that you want a URL to support, and hard code it. The building blocks are, in a sense, lower level – you can do a lot more with them, but it takes a lot longer to get started.

Opinionated isn’t better or worse: some projects, and some developers, are better fits for one particular type of web framework. It really just depends on a million factors.

Next.js is an opinionated web framework for JavaScript, specifically React

This lengthy (sorry) context brings us to Next.js. It’s a web framework like any other, but there are 3 main things you’ll want to know:

1. Next.js is highly opinionated. Like extremely so

Next.js is a textbook opinionated web framework. There are tons and tons of rules: where files need to go, what you need to name functions, etc. But the upshot is that it’s unbelievably easy to get started.

For example, if I want to create a new page for the technically.dev website at technically.dev/sponsorships, I need to create a sponsorships.js file in a folder names pages (or a folder named app in the newer versions). But Next.js takes care of all of the work of actually creating that page and serving it when someone types in that URL.

2. Next.js is specific to React

Most web frameworks are specific to a programming language; Next.js is specific to both a programming language (JavaScript) and another framework, React. If you haven’t heard of React, it’s a framework – some would call it, too, a web framework – for building interactive UIs, like the one you’re reading this in right now.

For better or worse, React is one of the standard tools that developers build frontends with today, and Next.js is all in on it. If you want to use Next.js, you need to use React.

3. Next.js is focused on performance

Unlike a lot of other web frameworks, Next.js focuses a lot of their feature set on helping you make your website faster and more efficient. A few examples:

• You can tell Next.js which pages a given page links to, and it will automatically preload them so if a user clicks a link, that next page (no pun intended) will load fast
• You can tell Next.js if you want something to render on the server or on the client
• Next.js handles caching automatically so your app doesn’t need to run requests every time someone loads a page

The TL;DR on all of this is that there’s a clear path to making your Next.js really fast and performant without needing to build tons of middleware yourself.

Personally, almost all of the projects I’ve built are in Next.js, including the award winning 2 technically.dev website. It’s both easy to get started in and packed to the brim with advanced features.

Vercel vs. Cloudflare tickets on sale

Next.js is in a bit of an odd situation, in that it is owned and maintained by a for-profit company (Vercel) even though it itself is free and open source. This is not the case for any other web frameworks I’m aware of, save for maybe Gatsby. And because Vercel runs Next.js, they’ve been able to build a few very convenient integrations between the two.

Vercel provides a sort of frontend cloud – like AWS, but for your frontend, not just databases or app servers. So when you deploy your Next.js app on Vercel, you get a bunch of nice features like automatic API generation, really fast builds, plus the ability to automatically redeploy your app when your team makes any changes to the GitHub repository that it’s in.

Not everyone is happy about this situation. They feel that Vercel being for-profit is a conflict of interest with the open source existence of Next.js – and this leads to undocumented behaviors, lack of clarity around roadmap and releases, and an overall less vibrant OSS ecosystem around Next. Major security incidents, like this one, tend to reignite this perennial discussion (see, for example, this Netlify blog post).

This all came to a head recently, when thanks to the magical powers of AI agents, Cloudflare was able to “rebuild” Next.js themselves and release it. Their initial posts on X framed this release as a sort of “liberation” from the evil clutches of the Vercel team, which obviously bothered them. Jabs ensued, for example:

Now there’s at least some degree of Vercel <> Cloudflare beef, e.g. this recent spat about forking just-bash. You’ve got to love the internet, folks.