This is the first post in a new series I am writing as I work my way through the modern web stack — Next.js, Vercel, Supabase, Drizzle, edge functions, the whole vocabulary explosion. The series is aimed at WordPress developers who, like me, have built things on the web for years and feel quietly behind the curve. The goal is broad literacy, not deep mastery. By the end you should be able to read any modern stack list and know what each piece is doing.
Each post comes with an audio companion (10-15 minutes, generated via NotebookLM) for gym or commute listening. Press play below if that suits you better than reading.
The Hook
A few months ago I was on a call with a potential client. Smart guy, technical co-founder. Halfway through, he said something like: “We were going to use Next.js with server components on Vercel, edge functions for the auth middleware, Drizzle on Supabase, deploy via GitHub Actions with preview branches per PR, Tailwind for styling, and Sentry for observability.”
I have been building things on the web professionally since 2007. WordPress, PHP, custom plugins, hosting, SEO, the works. And in that one sentence I genuinely did not know what half of those words meant.
I was not stupid. I was not behind because I had been lazy. The web had quietly grown a second nervous system while I was busy doing actual work, and almost nobody had given me an explanation that started where I actually was. So I decided to write the explanation I wish I had been handed three years ago.
The Core Concept
The single most useful thing I can tell you up front is that modern web development is not a bigger version of WordPress. It is a different paradigm with different physics. Trying to map it one-to-one onto what you already know is the trap that keeps WP veterans confused longer than they should be.
The shift can be stated in one sentence:
WordPress is a system for rendering pages. The modern stack is a system for building applications. Everything else follows from that.
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, the session cookie. The browser is mostly a passive viewer of 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 doing a full page reload. Logic lives on both the client and the server. The line between them is something you draw on purpose, not something the framework decides for you.
This sounds abstract, so make it concrete. Imagine a page that shows a list of products and lets the user filter them by price. In WordPress, the user clicks a filter, the browser sends a fresh request, PHP runs again, a new HTML page comes back. In a modern app, the user clicks a filter, JavaScript updates the visible list locally, maybe makes a small API call to fetch new data, and nothing else on the page changes. The address bar might not even change. To the user it feels instant. To the developer it requires an entirely different mental model of where state lives and who is responsible for what.
Out of that one shift falls almost everything that confuses you about modern stack vocabulary.
JavaScript everywhere. If the browser is doing real work, you need a real programming language running in it. JavaScript stopped being “that thing for form validation” and became the native language of the platform. TypeScript layered types on top because once your codebase is doing real work, types stop being optional.
Frameworks that own the whole pipeline. WordPress decides how PHP runs. In modern web 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. That alone is why modern stack feels so weird at first.
Servers that are not servers. Because frameworks now run code on demand, hosts started shipping a runtime instead of a server. Vercel is not a place where you SSH in and tail -f error_log. It is a system that 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. This is what people mean by “serverless” and it is one of the bigger mind-shifts in this course.
Databases as services, not files on disk. Shared MySQL on Kinsta is a database next to your application. Supabase, Neon, PlanetScale are databases your application reaches over the network. They handle pooling, scaling, replication. You never see the server.
Deploy by git push. WordPress is FTP, or at best git pull on the server. Modern stack is: you push to a branch, a CI pipeline builds your code, runs your tests, and deploys the result somewhere. Often you get a preview URL per pull request before anything reaches production. Once you have used this it is genuinely hard to go back.
If a WP veteran reads that list and thinks “this all sounds like more work for the same outcome,” that is a fair instinct. The honest answer is: for a brochure site, it probably is. For an actual application, where users do real work and state persists across sessions and multiple 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 course is about helping you draw it.
The WordPress Analogue
Mental model: modern web frameworks are to applications what WordPress is to publishing.
WordPress optimised for one specific job, getting content published on the web, and it built every convention around that job: 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 is why Next.js does not have a built-in concept of a “post” or a “category”. It does not know what your app is. You bring the domain, the framework brings the runtime.
The Landscape
The modern web stack is not one thing. It is a few clusters of choices that mostly compose. The rough map looks like this:
| Layer | What it does | Examples you will 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 is 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 choice from each row. Most apps use about ten of these tools at once. The rest of this series works through each row in turn, so by the end you can read any modern stack list and know what each piece is doing.
What This Changes for WordPress People
If you do client work, three things become possible once you understand modern stack.
The first is honest scoping. You stop nodding along when a client says “we want to do this in Next.js” and you start pushing back when WordPress is the right answer (which is often, especially for content-heavy sites). You also stop reflexively reaching for WP when an actual application is the right call. That clarity is valuable to clients, and you can charge more for it.
The second is that AI dev tools become useful. You cannot direct an AI agent to “build me a Next.js app with Supabase auth” if you do not know what either of those things is. The agent will produce code, you will not be able to evaluate it, and the project will rot in production. Modern stack literacy is the prerequisite for using AI as a serious tool, not a novelty. Most of the productivity stories you read about AI dev tools quietly assume the developer can read what the AI produces.
The third is that you stop being intimidated by job posts, agency briefs, and acquisition conversations. A lot of what makes modern stack feel scary is just unfamiliar vocabulary. Once you can hold the map in your head, the actual coding is not harder than what you already do. In some ways it is easier, because the tooling is genuinely better than what we had in 2010.
Watch Out
A few things to brace for as you work through this series.
Modern stack hype is loud, and a lot of it does not survive contact with 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. None of them are completely true. Be skeptical of any take that says you must be using technology X or you are obsolete.
The pace of change is exhausting if you let it be. React Server Components shipped, then changed twice. Remix was the future, then it merged into React Router. Next.js released the App Router, deprecated the Pages Router, and quietly kept supporting it because real codebases do not migrate on demand. The trick is not to chase every release. Pick a stack that works, ship things with it, revisit your choices once a year.
WordPress is not dead. A lot of modern stack content carries an implicit “WordPress is the past” framing. It is not. 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, WordPress is still the right answer. The point of this course is not to replace your WordPress brain but to add a second one alongside it.
You will get one thing wrong about modern stack at every step. That is fine. After almost two decades writing code I am still learning bits of this stack myself, which is part of why I am writing the course as I learn. A later post in this series is literally just “how do all the pieces fit together,” because that is the bit nobody explains.
Going Deeper
If you want to dig into specific tools after reading this, a few starting points worth your time.
YouTube, gym or commute friendly:
- “The State of JavaScript Frameworks 2025” by Theo (t3.gg, ~30 min). Opinionated overview from someone who lives in this stack daily. Good for getting the landscape feel before diving in.
- “Next.js Conf keynote” (most recent year, Vercel, ~50 min). Watch with skepticism, but it shows you what the framework’s makers think the future looks like.
Official docs worth bookmarking:
- web.dev — Learn the platform: Google’s platform-level intro, useful even if you skim.
- Next.js Learn: by-the-numbers tutorial that anchors most of the modern stack jargon in one place.
- MDN Web Docs: the reference you keep open in another tab forever, not modern-stack-specific but the canonical answer when “what does this JS feature actually do” comes up.
Next post in the series tackles the language layer: modern JavaScript and TypeScript for PHP people. Until then, listen to the audio companion above if you have not already.
Related
Leave a Reply