Theo Browne: Next.js is a backend framework

S'up, nerds. Theo here. Heard we were talking about Next.js. (screen whooshing) So for those who don't know me, I'm a software dev. I used to be mostly backend doing video infrastructure stuff at Twitch, moved over to frontend, built a lot of React.js, Next.js, TypeScript and GraphQL type applications. I found myself moving all over the stack.

Leaned really heavily into frontend for a few years but then Next.js just grabbed me and forced me back into full stack. The main reason that Next was able to do that is the controversial title that I'm here to talk about. Next.js is a backend framework. What? Isn't Next that React thing for building websites and web apps? Yeah, it is, and a lot of what makes Next what it is is its qualities as a backend framework. First, we need to understand backend and frontend. The way I choose to break it down is thinking of backend as the servers and computers we own

as developers, corporations and providers of a service, whereas frontend are the client devices and the codes that run on our user's device. The frontend is whatever interface the user is using to communicate to and from your servers and the servers are the things that provide the code for that interface and the data that is loaded within it? Backends do a lot. They do everything from sending emails to handling requests, returning data, HTML and anything or nothing else.

They process events, they process non-events, they read data from databases, they write data to databases, and so much more. Really, like hard to do much of anything without a backend nowadays, which his why it's a good thing that most of what we have here is doable within Next.js without too much effort. Let's think about things as a spectrum where on one side, we have our database or whatever the source of truth for our data is. And on the other side, we have a user that we are trying to render content for and interface with.

We can break up a lot of things on this spectrum where we have whatever's accessing the database, whatever's processing the request and shaping the data. Whatever's authorizing the request when it's made. Whatever is sending the HTML to the user and whatever the contents of that HTML are, as well as whatever runs updates on the client. I just said React here. Don't read too much into it. If we look at technologies like Create React App, they only take over once the HTML has hit. Usually with a project using Create React App or another single-app framework, there is an empty HTML page

with just a script tag. The script tag loads, fetches the right JavaScript, runs, and then fills the page with content based on whatever that JavaScript data or whatever that JavaScript chooses to render and whatever data that JavaScript fetches. On the other side, we have solutions like PHP, which care about everything up to when the HTML is sent. There're great ways to generate HTML but once you want the contents of that page to update, they kind of shrug and say that's up to you with solutions like jQuery to be built on top.

There are new solutions nowadays like Astro that take the same goal of PHP, which is turn data into HTML as effectively as possible while bringing in modern dev tools from the JavaScript ecosystem. There's obviously also tools like Ruby on Rails that were a little more cohesive, focused on how you interface with the database directly and how the shape of that works, as well as the models for creating views from those things. None of these solutions consider what happens after the page renders. Astro, at the very least, has ways built in

to include stuff like Preact, React, Solid, Svelte or whatever other clients-side JavaScript frameworks you choose to run. But Astro's goal ultimately is to generate HTML for ya. This is where Next.js gets so interesting though because what makes Next.js different from Create React App is that it kind of covers the whole spectrum. (tape whirring) Wouldn't be a proper conference talk if it wasn't out of date by the time I hit End Recording.