This is the first post in a series on the modern web stack, written as I work through it myself: Next.js, Vercel, Supabase, Drizzle, edge functions, the whole vocabulary explosion. It’s for WordPress people who’ve built on the web for years and still hit stack terms they can’t confidently define. The goal is literacy rather than mastery. By the end you should be able to read any modern stack list and know what each piece does.
Each post has a 10-15 minute audio companion, generated with NotebookLM, for the gym or the commute.
A few months ago I was on a call with a potential client, a technical co-founder who clearly knew his stack. Partway through, he ran through how he wanted to build the product: Next.js on Vercel, server components, auth handled in edge middleware, Drizzle talking to Supabase, deploys through GitHub Actions with a preview branch per pull request, Tailwind for styling, Sentry watching production.
I’ve been building on the web professionally since 2007: WordPress, PHP, custom plugins, hosting, SEO. As he talked, I realized I couldn’t have defined half the words he was using.
That’s a strange feeling after seventeen years. I hadn’t been lazy and I hadn’t stopped learning. The web had grown a second layer while I shipped real work with tools I already trusted, and no one had explained that layer starting from where I stood. So I’m writing the explanation I wish I’d been handed three years ago.
The most useful thing to know up front is that modern web development is a different paradigm with different physics from WordPress. Mapping it one-to-one onto what you already know keeps WP veterans confused longer than they need to be.
The shift fits in one sentence:
WordPress is a system for rendering pages. The modern stack is a system for building applications. Everything else follows from that.
Why the Shift Happened
It wasn’t inevitable, and two things drove it. What we ask the web to do changed: we went from publishing documents (blogs, brochures, news) to running software (dashboards, collaborative tools, anything that updates live), and a system built to render a page from a database is the wrong shape for an application that has to hold state and react. The browser also grew up, with fast JavaScript engines and APIs like History and fetch turning it from a document viewer into a place to run a real application.
Once Gmail and Google Maps proved a web app could feel instant, full-page reloads felt dated and expectations pulled the industry toward the application model. Faster phones and laptops helped, but the change in what we were building did most of the work.
Pages Versus Components
When you build a WordPress site, the unit of work is a page. A user requests a URL, WordPress looks up which template to use, runs the PHP, queries the database, and sends back HTML. Every page request is its own little world. State lives in the database, the user and the session cookie, and the browser mostly views whatever HTML the server hands it.
When you build a modern app the unit of work is a component. The application loads once into the browser, holds state in memory, fetches data over the network as needed, and updates parts of the screen without a full reload. Logic lives on both the client and the server, and you draw the line between them on purpose instead of letting the framework decide.
Take a page that shows a list of products and lets the user filter by price. In WordPress, the user clicks a filter, the browser sends a fresh request, PHP runs again, and a new HTML page comes back. In a modern app, the user clicks a filter, JavaScript updates the visible list locally, maybe a small API call fetches new data, and nothing else on the page changes. The address bar might not even move. To the user it feels instant. To the developer it takes a different mental model of where state lives and who’s responsible for what.
Almost everything that confuses you about modern stack vocabulary falls out of that one shift.
JavaScript everywhere
If the browser is doing real work, you need a real programming language running in it. JavaScript stopped being the thing for form validation and became the native language of the platform. TypeScript layered types on top, because once a codebase does real work, types stop being optional. The next post covers both from a PHP developer’s angle.
Frameworks that own the whole pipeline
WordPress decides how PHP runs. In the modern stack you pick a framework (React, Vue, Svelte) that decides how JavaScript runs in the browser. Then you pick a meta-framework (Next.js, Nuxt, SvelteKit) that decides how the same code can also run on the server when you need it to. The same component file might render on a server in Frankfurt or on your visitor’s phone in Lima, which is why the stack feels so strange at first.
Servers that aren’t servers
Because frameworks now run code on demand, hosts started shipping a runtime instead of a server. Vercel isn’t a place where you SSH in and tail -f error_log. It takes your code, decides where to run it (sometimes in a Frankfurt datacenter, sometimes at a CDN edge in Lagos), and bills you per execution. That’s what people mean by serverless, and it’s one of the bigger mind-shifts in this series. Serverless and edge gets its own post.
Databases as services
Shared MySQL on managed WordPress hosting is a database sitting next to your application. Supabase, Neon and PlanetScale are databases your application reaches over the network, and they handle pooling, scaling and replication. You never see the server. The series covers life beyond shared MySQL in detail.
Deploy by git push
WordPress deployment is FTP, or at best git pull on the server. In the modern stack you push to a branch, a CI pipeline builds your code, runs your tests and deploys the result somewhere. You often get a preview URL per pull request before anything reaches production. Once you’ve used that, it’s hard to go back.
If a WP veteran reads that list and thinks it sounds like more work for the same outcome, that instinct is right for a brochure site. For an application, where users do real work, state persists across sessions, several people interact in real time, and SEO and interactivity both matter, the modern stack earns its complexity. Knowing where that line falls is the real skill, and most of this series is about helping you draw it.
The WordPress Analogue
Mental model: modern web frameworks are to applications what WordPress is to publishing.
WordPress was built for one job, getting content published on the web, and every convention follows from it: the loop, post types, themes, a database schema you can describe in your sleep. Modern web frameworks made the opposite bet. They left the domain wide open and built tooling for arbitrary apps. That’s why Next.js has no built-in concept of a post or a category. It doesn’t know what your app is. You bring the domain and the framework brings the runtime.
The Shape of the Stack
The modern web stack is a few clusters of choices that mostly compose. The rough map looks like this:
| Layer | What it does | Examples you’ll meet |
|---|---|---|
| Frontend framework | Renders UI from components | React, Vue, Svelte, Solid |
| Meta-framework | Adds routing, SSR, file structure | Next.js, Nuxt, SvelteKit, Astro, React Router 7 (formerly Remix) |
| Language | The thing you actually write | TypeScript (default), JavaScript |
| Styling | How CSS gets generated and shipped | Tailwind, CSS Modules, vanilla CSS, shadcn/ui (component primitives) |
| Database | Where your data lives | Supabase Postgres, Neon, PlanetScale, Turso, Cloudflare D1 |
| ORM | How code talks to the database | Drizzle, Prisma, Kysely |
| Auth | Login, sessions, social providers | Auth.js, Clerk, Supabase Auth |
| Hosting | Where the code runs | Vercel, Netlify, Cloudflare Pages, Fly.io, Railway, Render |
| CI/CD | What happens when you push | GitHub Actions, Vercel deploys, GitLab CI |
| Observability | What’s broken in production | Sentry, Logflare, Vercel Analytics, Plausible |
The vocabulary explosion is real, but the structure under it is simple. Every modern stack is a pick from each row, and most apps use about ten of these tools at once. The series works through each row in turn, and how the pieces wire up shows them connected in one request.
What This Changes for WordPress People
If you do client work, three things become possible once you understand the modern stack.
The first is honest scoping. You stop nodding along when a client says they want to build in Next.js, and you push back when WordPress is the right answer, which is often for content-heavy sites. You also stop reaching for WP by reflex when an application is the right call. Clients value that clarity, and you can charge more for it.
The second is that AI dev tools become useful. You can’t direct an AI agent to build a Next.js app with Supabase auth if you don’t know what either of those is. The agent will produce code, you won’t be able to evaluate it, and the project will rot in production. Most of the productivity stories about AI dev tools assume the developer can read what the AI produces.
The third is that job posts, agency briefs and acquisition conversations stop being intimidating. Much of what makes the modern stack feel scary is unfamiliar vocabulary. Once you can hold the map in your head, the coding itself is no harder than what you already do, and in some ways easier, because the tooling is better than what we had in 2010.
What the Hype Gets Wrong
A few things to brace for as you work through the series.
Much of the hype doesn’t survive production
Server components were going to change everything. Edge runtime was going to make every app fast. Serverless was going to kill traditional hosting. Some of these claims are partially true and none are completely true. Be skeptical of any take that says you must use technology X or you’re obsolete.
The pace of change is exhausting
React Server Components shipped, then changed twice. Remix was the future, then merged into React Router. Next.js released the App Router, deprecated the Pages Router, and kept supporting it anyway, because real codebases don’t migrate on demand. Don’t chase every release: pick a stack that works, ship with it, and revisit your choices once a year.
WordPress still has its place
A lot of modern stack content carries an implicit “WordPress is the past” framing. WordPress still runs around 40 percent of the web. For content sites, ecommerce in many markets, and clients who need a CMS their non-technical staff can use, it’s still the right answer. This series adds a second brain next to your WordPress one.
You’ll get something wrong at every step
After almost two decades writing code I’m still learning parts of this stack, which is part of why I’m writing the series as I learn. One later post is simply how all the pieces fit together.
Where to Start Digging
If you want to dig into specific tools after reading this, a few starting points are worth your time.
YouTube, gym or commute friendly
- “The State of JavaScript Frameworks 2025” by Theo (t3.gg, ~30 min). An opinionated overview from someone who lives in this stack daily, good for getting a feel for the landscape before diving in.
- “Next.js Conf keynote” (most recent year, Vercel, ~50 min). Watch with skepticism, but it shows what the framework’s makers think the future looks like.
Official docs worth bookmarking
- web.dev Learn: Google’s platform-level intro, useful even if you skim.
- Next.js Learn: a step-by-step tutorial that anchors most of the modern stack jargon in one place.
- MDN Web Docs: the reference you keep open in another tab forever, and the canonical answer whenever you wonder what a JS feature does.
The next post tackles the language layer: modern JavaScript and TypeScript for PHP people. Until then, play the audio companion above if you haven’t already.
Related
Leave a Reply