The Title Says Full-Stack, but We All Know Who This Is Really About
Front-end developers have a long tradition of underestimating the scope of their own job. That’s not surprising, because the job itself keeps changing underneath them — and lately it’s changing in a very particular direction. Work that used to clearly belong to back-end developers is quietly migrating into the front-end’s territory.
That’s not an opinion. Look at any job board and you’ll see postings for front-end developers that include responsibilities that, a decade ago, no one would have put anywhere near that title. This isn’t just semantics. Job descriptions are personal — they define what people are hired to do and, by extension, what they’re paid to do.
So what actually is a front-end developer?
At the core, it’s someone whose work deals directly with the browser, devices, and users. That’s the defining trait.
It’s not that back-end developers don’t care about users — it’s that the responsibility is delegated. Front-end developers are the ones who live in the browser. They have DevTools open, they test across versions and platforms, and they care about how things ultimately look and work for the people using assistive technology.
Underneath all of that sits a simple stack: HTML, CSS, and JavaScript. That’s what browsers actually speak, and everything else — build tools, frameworks, preprocessors — is just a means to the end of shipping those three languages to the browser.
Not every front-end developer knows all three equally well, and that’s fine. There are plenty of successful front-end developers who barely touch JavaScript, just as there are plenty who write almost nothing else.
That split is real enough that some companies, like Google, officially recognize it with separate job titles and career ladders — and those ladders pay the same.
The Stack Has Moved
Around 2015, JavaScript started expanding aggressively as a language, and with that expansion came a shift. Responsibilities that used to be back-end concerns — things like site architecture, routing, data fetching, and state — started showing up in front-end job descriptions.
Three areas stand out as the clearest examples.
Component-Driven Everything
Server-side-rendered projects never really embraced components the way JavaScript frameworks do. Sure, there were templates and includes, but those were a pale comparison to real component-driven development. And while JavaScript frameworks disagree on plenty of things, they all agree on components.
Take a look at CodePen, a React-powered site. Even a tiny SVG icon is a component — called <SVGIcon /> — because that abstraction is useful. Pair that icon with a number, and you have another component. Group those into a row, and that row is a component. The whole item becomes a component. The grid of items becomes a component. The tabs, the forms, the sidebar, the entire page — components all the way down.
Once the whole page is a component, the URL itself becomes a component. And when all URLs are components, you’re controlling the entire site — which means you’ve become its architect.
That’s a lot of additional responsibility on top of work that never went away. It’s no wonder front-end developers are starting to feel considerably more full-stack.
Interestingly, this isn’t just a developer phenomenon. Designers have been working this way for a while too — symbols in Figma, Sketch, and Adobe XD share the same spiritual DNA as components.
Data, State, and Mutations
State management used to be a back-end concern. Now it’s at the core of most JavaScript frameworks, and it comes with a new obligation: filling that state with data.
GraphQL is a meaningful answer here. With a strong GraphQL endpoint and tools like Apollo Client, a front-end developer can get their hands on any data they need to build a UI — no back-end developer in the loop.
But getting data is only half the job. Managing the asynchronous nature of components means deciding between skeletons, spinners, delayed rendering, and error states. And when the UI needs to change data, mutations are on the front-end developer’s plate too.
mport gql from "graphql-tag";
import { Mutation } from "react-apollo";
const ADD_TODO = gql`
mutation AddTodo($type: String!) {
addTodo(type: $type) {
id
type
}
}
`;
const AddTodo = () => {
let input;
return (
<Mutation mutation={ADD_TODO}>
{(addTodo, { data }) => (
<div>
<form
onSubmit={e => {
e.preventDefault();
addTodo({ variables: { type: input.value } });
input.value = "";
}}
>
<input
ref={node => {
input = node;
}}
/>
<button type="submit">Add Todo</button>
</form>
</div>
)}
</Mutation>
);
};None of that work used to be front-end’s job, and all of it was almost certainly in the back-end’s realm before.
Colocated Styling
Styling has always been front-end territory, but in a component-driven world, it makes sense to colocate styles with the components they style. CSS Modules let styles be scoped to a specific component, while global styles and Sass abstractions still have their place for things that genuinely need to be global.
.root {
display: grid;
}The result is folders that contain everything — logic, templates, queries, mutations, and styles — all together. That convenience has side effects worth noting: JavaScript bundles can code-split naturally, unused styles leave when their components leave, and naming things is drastically less stressful when the scope is file-level, not global.
An Ever-Growing Pile of Responsibilities
Front-end developers already have a full plate: pulling the design apart, turning it into a system, making sure it’s accessible, worrying about performance, testing across browsers and devices, and sweating every detail of the UX.
On top of that pile, front-end developers are now expected to handle component abstractions, site-level architecture, routing, data fetching, API communication, mutations, and state management.
Not every front-end developer needs to be great at every one of these things. But these are all tasks that now fall within the realm of front-end development, and that’s what makes the term so much wider than it used to be.
If you’ve been in this industry for a while and feel like your job title no longer describes what you actually do all day, you’re not wrong. The job itself has grown, and it keeps growing.
The Stack Keeps Sliding Toward the Front End
It used to be easy to draw a line between back-end and front-end work. The classic LAMP stack — Linux, Apache, MySQL, and PHP — still runs a huge portion of the web, particularly CMS-driven sites. But if you were a front-end developer in that world, you were far away from most of the technology named in the stack itself.
By the time MEAN arrived (MongoDB, Express, Angular, Node), the operating system had dropped out of the conversation entirely. More notably, a front-end framework like Angular was now part of the core stack. The tools that mattered were moving closer to the front-end developer's territory.
Serverless pushed things even further. You don't care what server your code runs on anymore; you just write server-side functions and consume APIs. For a front-end developer, that kind of work is reachable with existing JavaScript skills.
Shawn Wang has called the combination of Design Systems, TypeScript, Apollo GraphQL, and React a STAR app — and it's essentially all front-end technology. The center of gravity for building websites has drifted steadily toward the front-end side of the spectrum.
Serverless Is Expanding What Front-End Developers Can Do
Serverless tech, and much of the JAMstack movement — JavaScript, APIs, and Markup — fits into this shift nicely. Some have joked that SHAMstack would be even more accurate: a static site generator, a headless CMS, and a markup language, all working together.
A conference listing site is a perfect example of this approach. Each conference is a Markdown file with front matter holding metadata like dates and location. Instead of a database, flat files are enough, and a static site generator like Eleventy processes them with Nunjucks templates. The data needs are simple enough that plain files are not a compromise.
---
title: JAMstack_conf_ldn
url: 'https://jamstackconf.com/london/'
cocUrl: 'https://jamstackconf.com/london/code-of-conduct'
date: 2019-07-09T08:00:00.000Z
endDate: 2019-07-10T16:00:00.000Z
location: 'London, England'
byline: 'Learn how to design, develop, and deploy fast, modern web projects that run without web servers.'
---
Following the inaugural [JAMstack_conf in San Francisco](https://2018.jamstackconf.com/) in 2018, we're now also bringing an edition to London where we'll have talks about how to design, develop, and deploy fast, modern web projects that run without web servers.The entire site lives in a public GitHub repo, which carries real advantages beyond just version control. There are no credentials to configure; pulling down the repo and running one command spins up the whole project. Being a public repo also opens the site's content, design, and functionality to outside contributions, which has proven highly valuable.
The site could stay on GitHub Pages, but Netlify offers meaningful upgrades with minimal effort:
- Deploy previews: Every pull request gets a live URL showing exactly what the merged site would look like.
- Analytics: Accurate visitor numbers can be turned on without much work.
- Image processing: Images can be manipulated programmatically.
Netlify CMS adds an even bigger benefit: a UI for editing content directly on the site. Once set up, it requires no manual Git work. Netlify Identity makes the authentication side much simpler. And none of this even requires Netlify specifically; the CMS is portable.
Email Is Still a Back-End Problem — But Now It's Manageable
Send a registration reminder or a conference info email and it's a genuine back-end task. Email sending can't happen with client-side code alone. APIs can send email, but the API keys involved need to be kept secret. Using a service like SparkPost provides both an API and a Node library, leaving you with just a handful of lines of JavaScript to write. That's code a front-end developer can comfortably handle.
Running the Back End Without Owning It
Cloud functions — like AWS Lambda, Azure Functions, or Google Cloud Functions — handle the server side. Netlify Functions wraps AWS Lambda such that dropping functions in a /functions/ folder and hitting a relative URL is all it takes. No server provisioning, no configuration beyond the code itself.
Looking at the full modern spectrum, the operating system is no longer a concern for most builds. Data doesn't need to be touched through a database layer either; headless CMSes work through APIs, and storage tools like FaunaDB or Firestore are designed around API or client-side access. Front-end developers can reach across all of it.
The Stretch Is Real — But So Are the Gaps
Being full-stack now also includes basics like version control, writing tests, handling build steps, designing, understanding performance and accessibility, and standing up a deploy pipeline. It's a huge surface.
The reality is that a true unicorn is as common as the mythical animal. And back-end developers aren't becoming obsolete, they're more important than ever, because web development is now complex enough to need deep specialists everywhere.
Even while writing full-stacky code, the edges show. One estimate found dozens of issues in the CodePen repo that demand genuine back-end expertise. That kind of knowledge is outside the typical front-end skillset entirely. Nobody's profile ends up as a full, polished horse or dragon.
“Fullstack” developer. pic.twitter.com/yfymQmJJgq
— Brian Holt (@holtbt) March 24, 2018
The Practical Line
The tech shifting toward side projects and smaller teams is genuinely valuable. It lets more people build a product from start to finish on their own. The whole industry benefits when that barrier drops: more things get made, and more developers get the experience of an end-to-end project.
Still, having broad reach doesn't erase the need for fundamentals across an entire team. Doing right by users is everybody's responsibility. That means caring about UX, performance, security, and accessibility even when someone else has their hands on the code. Web tech now allows more people to build more of the whole picture — but a complete product shouldn't be judged only by how far one developer can reach.
