console.log()

Why the Frontend Kingmaker isn’t Full-Stack: A History

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

I have made the case that in 2024 frontend developers are the Newest New Kingmakers, and therefore deserve a place beside more established Kingmakers hailing from the backend and IT operations spheres.

Evidence of the frontend’s rise is everywhere. Client-side interactivity and the UI is where much of the most exciting software innovation is happening (lately I’ve been following what Stepan Parunashvili calls the Database in a Browser, with Carl Sverre’s SQLSync being a particularly original approach). The frontend’s reputation has also benefited from engineers becoming valued consumers of managed cloud services intended to handle backend ops. All of this has spurred a renaissance surrounding the frontend’s image, so that practitioners working at the top of the stack are now vocally embracing the label “frontend” as a worthwhile and hip segment of the developer community.

This pro-frontend sentiment is a very recent occurrence. It’s significant that Vercel’s messaging around “The Frontend Cloud” is less than two years old. Even five years ago many developers I know shuddered at the thought of committing themselves to the label “frontend,” and most aimed to assume the title “full-stack” (a distinction I expand on below). How should we account for the rise of the Frontend Kingmaker? In this second installment of my three-part series, I discuss the history of the frontend and web development. I will also cover the contentious idea of the full-stack developer, which until 2019 threatened to subsume the sovereignty of frontend development as a viable profession. I also touch on the recent SPA Wars, which have gone far toward saving developers working at the top of the stack from stagnating or becoming pigeonholed as React developers.

So let’s talk about the frontend’s journey to its newly elevated rank.

 

In the Beginning, Web Development was All About Frontend


Tim Berners-Lee at CERN (Image credit: CERN)

I know, I know, but hear me out.

Tim Berners-Lee’s “hypertext project” for CERN shared documents written in HTML. Without interactive elements, hypertext offered a pure frontend experience. Sure, when it launched in 1990 Berners-Lee also performed operations labor by hosting his website on a computer famously adorned with the warning label: “This machine is a server. DO NOT POWER IT DOWN!!” And yet, into the present it is hypermedia—text and images—that distinguishes the WorldWideWeb from the sort of internally-facing computation that corporate mainframes handle.

How the web looked and performed were top of mind in those early days. The HTML Working Group was founded in 1994 to standardize the language, which the W3C took over from 1997 to 2015. 1996 witnessed not only the CSS 1 recommendation’s publication, with the CSS Working Group being founded the following year, but also the creation of JavaScript as part of Netscape (which became the ECMA-262 standard). Of course, innovations have only accelerated from there. If the internet is a vehicle for sharing media, it means that all SaaS, serverless, and web-based services are heir to the sort of client-side, user-driven experience for which the frontend specialized.

The frontend experienced an auspicious beginning, but you would be excused for not realizing it until very recently.

Since the 2010s, there has been a persistent stereotype that frontend development is a stepping-stone to real, serious engineering work. Practitioners laboring at the top of the stack are perceived to have intern or junior-level skills. Moreover, the code that frontend engineers write is often discounted as trivial or, worse, optional, particularly when it comes to accessibility and QA. For too many, the frontend is window dressing while the backend is essential. The frontend is also frequently gendered feminine. As a 2017 lawsuit against Google brought by three women developers, plaintiffs Kelly Ellis, Holly Pease, and Kelli Wisuri, notes:

Google pays backend engineers more than frontend and fastracks them for promotion. On the teams Ms Ellis worked with and observed at Google, almost all backend software engineers were men. Almost all female software engineers, however, were frontend engineers. The skills required to perform these jobs are equal or substantially similar.

One reason vendors historically ignored frontend developers is because they were perceived to have little involvement in purchasing decisions. Sales consultants continue to discount the frontend’s importance for this reason, with the Boston Consulting Group, for instance, recently claiming that, “cloud-native application developers and DevOps engineers have particular clout in purchasing decisions.” It is true that the greatest spend in an engineering department tends to be on infrastructure (servers, databases, hosting). But it is shortsighted for the providers selling these products and services to target only backend and operations engineers. As more and more sophisticated infrastructure and operations abstractions appear in the marketplace, the developers responsible for selecting and managing ops is diversifying (more on this in a follow up post).

 

The Nadir of Frontend & Rise of Full-Stack

But the nadir of the frontend engineer is in large part a consequence of the rise of the “full-stack developer.” The notion that frontend developers were the persona non grata of an engineering department in terms of decision making and resourcing sway emerged in 2008 when Randy Schmidt, currently a senior project manager at Burns & McDonnell, identified the “Full-Stack Web Developer” as “someone that does design, markup, styling, behavior, and programming.” This sense of the phrase shifted full-stack’s previous definition from the 70s and 80s, which referred to full-stack developers as those practitioners responsible for the operation of both hardware and software. Today, “full-stack” is used exclusively to refer to engineers tasked with developing for web as well as mobile, and possessing mastery of both frontend and backend skills.

Throughout the 2010s, the full-stack/ frontend/ backend distinction became central to how hiring managers and engineering leadership formulated their teams. Frontend has come to distinguish developers who write JS, CSS, and HTML, as well as any code touching the UI which includes APIs, GraphQL, CMSs, browser testing, and WCAG compliance. Backend handles server side code, which generally covers areas like database maintenance and security, but full-stack developers can do it all. It takes a very small leap to understand why pay disparities and sexism attached itself to these distinctions.

Between 2010 and 2020, no one wanted to be a frontend engineer (ok, except for me, my friends, and loads of talented developers who realized the frontend is where it’s at). For pragmatic reasons many engineers working at the top of the stack instead positioned themselves as “full-stack.” Of course, even today the full-stack role persists. At a Christmas party last year I asked a woman if she was a frontend engineer, probably after spending several minutes chatting about front-endy things, but she looked genuinely horrified at the accusation: “There are no frontend engineers at our company. Only full-stack.” Mea culpa. There are clear historical reasons to shy away from the label, particularly among woman developers and those looking to secure the highest salary, but the full-stack has failed and suspicion against the frontend is waning.

 

Why Full-Stack Failed

Companies benefited inordinately by having developer jack-of-all-trades available to work at every layer of the stack. It’s like having 2 developers for the price of one! But the expectations placed upon full-stack developers have proven unrealistic and often unpleasant for workaday practitioners. For this reason, the full-stack role has received significant backlash from within these communities. As Laurie Voss succinctly explains:

You can’t learn the whole stack. Nobody can. Maybe it was possible in 1990, the day after the web was invented, but I’m not even sure about that.

Beyond its impossibility, the insistence of so many employers upon hiring full-stack developers has had the consequence of leading to burnout, anxiety, and unnecessary cognitive load. A decade ago, “discouraged developer” Tim Bray voiced his frustration with the idea of a full-stack developer, who is expected to master the front and back of the stack as well as IT operations:

But there is a real cost to this continuous widening of the base of knowledge a developer has to have to remain relevant. One of today’s buzzwords is “full-stack developer”. Which sounds good, but there’s a little guy in the back of my mind screaming “You mean I have to know Gradle internals and ListView failure modes and NSManagedObject quirks and Ember containers and the Actor model and what interface{} means in Go and Docker support variation in Cloud providers? Color me suspicious.

The full-stack role undermines the tinkering, exploratory spirit that has long invigorated the profession of software development. DevOps engineers are expressing a similar sentiment to their disillusioned full-stack developer counterparts. Tired of trying to master the skills required for development and operations, many DevOps practitioners lobby to resegregate these roles into separate domains in order to lighten the mental strain imposed by assuming a mastery of both. It is no wonder that things began to look up for the maligned frontend engineer in the 2020s, heralded by Coyier’s “The Great Divide,” which established the frontend’s renewed identity and mastery of client-side interactivity and the UI.

 

A Post-React Frontend

I will leave an extended analysis of the frontend’s future for a later post, but I want to round out this history-focused analysis with the most recent challenge to the sovereignty of the frontend role: the rise of single page applications (SPAs).

For many aspiring frontend (and full-stack) developers looking to write JavaScript professionally, learning React—the most popular JS framework—remains the most direct path to employment. Advice on job boards and podcasts often recurs to this contentious theme. Indeed, whether folks hoping to reskill into the tech field ought to learn vanilla JS, or jump straight into React, continues to be hotly debated. Although learning a JS framework is a pragmatic approach, particularly for individuals looking to maximize their earning potential quickly, the suggestion that frontend === framework narrows and condenses the frontend’s range.

It is imperative for folks invested in developing apps with rich interactive UI experiences to keep the frontend profession from being condensed into mere framework maintenance. Developing and designing for the frontend is a broad and creative endeavor. If frontend engineers are reduced to React developers, their collective identity will suffer.

React may be a large and vocal player in the frontend space right now, but the SPAs continuing dominance is uncertain. Many apps are adopting HTML-first architectures that eschew heavy JS wrappers. Static site generators (SSG) and server-side rendering (SSR) have also seen a resurgence in popularity owing to their performance benefits. Moreover, issues relating to client-side interactivity, including hydration, caching, signals, and islands, continue to generate excitement among the web developers I follow. Innovations and improvements in these areas in particular have drawn many of the brightest minds to take part in, and invigorate, this space apart from the JS frameworks that threaten to suck all the oxygen from the room.

To wrap up this history and analysis of the Frontend Kingmaker, the renewed respectability of developers working at the top of the stack has been significant. Instead of a dirty word, devs are now wearing the profession of “Frontend Engineer” with pride. Although, many web developers will continue to eschew this title as a means of professional survival owing its long tenure of being perceived as lesser, as I have endeavored to show, the times, they are a’changing.

Header image: “A King eating Pancakes” created with Dall-E

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *