Front-end vs. back-end is obsolete now

In the beginning, there was just the web

When I first started web development (last century, genuinely) nobody used the terms “front-end” or “back-end.” We built web pages: HTML for structure, CSS for style, a little JavaScript for interactivity. You uploaded the files to a server with an FTP client. The server handed the files to visitors. That was the whole job.

The distinction between roles didn’t exist because there wasn’t much to distinguish.

Server-side changed how we thought about the work

PHP and ASP changed that. Suddenly pages could respond to user input, pull from databases, build themselves dynamically on each request. You could include a single navigation file across a hundred pages instead of editing each one individually. (If you remember SHTML, you know exactly how bad the alternative was.)

That’s when roles started separating: the people who built interfaces and the people who handled data and logic. Front-end was the artsy side. Back-end was the techy side. The line between them was real and relatively clean.

JavaScript frameworks formalized it

AngularJS, then React, Angular, Vue, Svelte: these frameworks gave front-end development structure and discipline. Before them, JavaScript was often an afterthought, bolted onto pages for small interactions. After them, front-end became an engineering discipline with patterns, best practices, and its own career track. TypeScript came later and added the type system that made large-scale front-end codebases manageable.

Meanwhile, back-end had its own evolution: Java, Ruby on Rails, Django, Spring. Two reasonably distinct worlds, different tooling, different cultures, different hiring criteria.

Node.js started collapsing the categories

Node.js was the inflection point. Once JavaScript could run server-side, the same developer writing React components could write the Express API those components called. The same language, the same runtime, often the same person.

NPM bridged the ecosystems further. Build tools converged: Grunt and Gulp gave way to Webpack, then Vite, then Bun. Front-end and back-end were sharing not just language but toolchain. The line became a gradient.

Cloud and CI/CD finished the job

Infrastructure-as-code meant developers started managing their own deployments. Docker containers, Kubernetes clusters, Terraform configs: none of this lived exclusively in an “ops” silo anymore. A React developer deploying to Vercel is, whether they think of it this way or not, managing infrastructure. A back-end developer writing GitHub Actions pipelines is doing DevOps.

Serverless pushed this further. AWS Lambda, Cloudflare Workers, Vercel Edge Functions: you write a function, you deploy it, it scales automatically, you pay per invocation. There’s no “infrastructure team” to hand it off to. There’s no waiting for a back-end API if you can write the API yourself and deploy it alongside the front-end in the same repository.

What this actually means for how teams work

The label “front-end developer” or “back-end developer” increasingly describes a preference and a depth of expertise, not a hard boundary.

Most developers I hire today have worked across both sides. They have a stronger side, the one they reach for first, the one where they’re faster. But they can operate across the stack, which changes how teams organize and how work gets done.

I’m less interested in whether someone identifies as front-end or back-end than in whether they understand how the pieces connect. Can they trace a bug from a network request through the API handler to the database query? Can they talk about why a UI decision affects API design? Can they think about performance end-to-end rather than optimizing in isolation?

That’s what I mean when I say the distinction is obsolete: not that specialization is bad, but that rigid siloing misrepresents the job. The developers who thrive in this environment are curious about the whole system, even when they’re expert in one part of it. The label is the least interesting thing about them.