Headless is here. Whether you see it scrolling by in your favorite feed or dropping into your full inbox, the term is showing up everywhere.
In fact, we’re even talking about it — you may have seen it from our very own Director of Development, Bob Davidson, as he wrote about how building a site in headless takes more than just a bit of technical knowledge — it takes a full shift in how we think about websites at the base level.
But while Bob touches on some of the unique aspects of working on a headless site for those with a traditional back-end role, I want to take a bit to explain how the very concept of “back-end” and “front-end” shifts with a headless implementation. In other words — what does the idea of being a front-end developer mean in a headless world?
First, to understand the confusion, we really need to understand the meaning of the term "front-end," itself. In the traditional sense, a front-end developer writes code in HTML, CSS, and some JavaScript. Their concerns lie in things like semantic markup, colors, responsive layouts, typography, and accessibility.
More recently, however, due to how headless projects are often handled, the term has come to refer to a different kind of developer. This kind of developer is highly specialized in JavaScript and concerned with things that would traditionally be concerns for a backend developer — things like manipulating data, API integrations, and managing state, routing, caching, and authentication. Despite handling a very different set of responsibilities, they still use front-end technology to accomplish these tasks.
It’s for this reason that “front-end” developers seem to be creeping into the “back-end” space — if the tools fit, the name should follow.
This can obviously be confusing, especially for someone who does not live in this world. To a marketing team whose last web refresh happened in the days before the pandemic, there was a clear separation of duties — “front-end” turned design into workable code, and “back-end” turned desired features into real-life functionality.
The responsibilities and specialized concerns necessary to build a headless site has not changed drastically, except that there’s been a blurring of “who does what.” Where roles were once likely split, now a deeper level of teamwork is needed — from both front- and back-end developers.
At Blend, we've started abstracting the concerns of each role from their respective technologies by using terms like "presentation" and "integration" to refer to developers on one end or the other. It's one attempt we're making to bring clarity to muddy waters when communicating with each other and with clients to make sure we're all talking about the same things throughout the life of a project. While it may not always be necessary to use new terminology, it is important to be aware of the distinction.
Putting more emphasis on specific responsibilities and concerns can go a long way in clarifying what's expected and who’s best suited to do the work. As headless projects become more common, success will depend not just on technical skills, but on how well we define and communicate those roles.