Stacks evolve over time. But it’s not just what technologies they use, but what technology we even consider a part of a stack. What fullstack means morphs over time.
Chris Coyier - What Does it Mean to Be “Full Stack”?
Today I got into a Twitter #BEEF about the appropriateness of the term "fullstack framework." Some of you may know that I am the host of a podcast called Fullstack Jamstack and have made my name as a developer advocate for RedwoodJS, a self proclaimed "fullstack" JavaScript framework.
However, I do not make any claims to ownership of the term. My thoughts on the term and its definition are fiercely personal, and I welcome others to have their own passionate beliefs around it. I want to elicit dialogue around the term, not tell you what it means.
Why is this personal for me?
Before joining the RedwoodJS team I was learning how to code at Lambda School, learning a "fullstack web development" curriculum. This curriculum contained roughly:
- 10% HTML/CSS
- 85% JavaScript/React
- 5% Node/Express/Postgres
I felt this was an uneven split between the frontend and backend. It didn't seem accurate to label this as a "fullstack" curriculum, instead it seemed more accurate to call it a "frontend" curriculum with a very small amount of backend material included at the end.
What is the definition of "Full?"
I start with the postulate that the term "full" contains the most essential quality of "completeness." To say something is "full," is to say there is nothing left to add. This is why I would consider a stack without any database or storage to be incomplete.
How often do you use an application where everything you did with that application disappears after you take a break from using it? If you're just reading a blog post that's probably fine, not everything we do on the web requires persistence. But if you're writing that blog post, it's a different story.
Is there actually just a frontend and backend?
A recent turn of phrase has come up called the "front of the backend" to describe the illusive middle ground between the client side and the server side. Does this mean there is a "back of the frontend?"
There is the HTML and CSS for the content and styling and JavaScript (or some sort of JavaScript framework) for the client side interaction. But the data fetching logic and state management can be decoupled from the content and styling itself, forming its own layer of the application. This is the space Redux and React Query play in.
On the backend you have an operating system, server side language (or framework), and database for authentication, authorization, and persistence. But you can abstract a layer above that with an API mesh, serverless functions, or containers that let you ignore the actual operations of the underlying system.
What else should be included in the definition of "fullstack?"
What about accessibility, internationalization, localization, security, deployment, DevOps, automated testing, design systems, data collection, analytics, emails, etc? How wide does the definition go? Is it even reasonable for us to expect a single developer to ever be fullstack?
Unfortunately I don't have the answer to that question. But as long as we are going to be selling the term for our bootcamps, our frameworks, and our podcasts, then we need to think carefully about what we mean when we use the term.
Thank you to Alex for his thoughtful notes and pushback on this piece.
Top comments (6)
As a "full-stack developer" since 2008, I can help with some resolution over the term: it's bullshit. Affiliate marketing niches were always looking for full-on and complete developers and by that they meant their own software stack, something that at the time end even before was never "just LAMP" for example. You would call yourself "principal developer for X" which in turn meant you are a "full" stack developer at that company.
The biggest conspiracy theory is to think somehow the term was invented by developers with the rise of new software stacks - that is very wrong. I also distinctly remember people and companies up until like 2015 looking for people capable to define and build their entire stacks and not knowing how to search for such a person, sometimes described as "we need a one man army developer".
When I first saw the term used in job descriptions it was simply stupid, you could be a full-stack developer with some specialisations listed, like java/php/node and everything around it, but it never meant "everything everything". Greedy people trying take credit for the term or making up search engine trends (tl;dr: bots) are just a waste of time and attention in a market where the term has been so overused it essentially lost any value ever since someone somewhere prefixed it with "junior".
Not trying to rant but my attachment to the term is long dead, Developer Relations and Developer Advocate being the bread and butter of what being a great developer means lately :D
Well I'm glad to hear as a Developer Advocate that I've got the right title at least 🥳.
I think that's a totally valid rant. My use of the term has never had anything to do with job titles or even people really. For me it's more to do with frameworks. It's mostly just been a useful shorthand for me to specify a framework that includes some kind of client side tool, a server, and a database (Redwood, Blitz, Bison as the canonical examples) in contrast to a framework that is only client side (React, Vue) or client side and server side but without a database (Next, Nuxt).
Do you think there's a more suitable term to describe this concept, or should I just give up on trying to find a succinct way of explaining this distinction?
I mean in terms of development I view anyone seriously into it as an engineer and treat words and complex terms as attention media / hype. It's good to be able to talk to everyone, but not worth the damage projecting such thing onto oneself causes :D
I think there is an unhealthy attitude towards specialization in the web development community. It is extremely odd for an industry to develop a culture where people openly claim they can do everything.
I blame unrealistic job postings that list every possible skill involved in development for driving people to claiming they can do it all.
I agree and this is why I don't think all of the things listed in the last section should be included in the term fullstack. To me I think of the term as defining the application code itself, not the meta code around it which includes things like deployment and CI/CD.
Being fullstack doesn't mean you know everything, it means you have an end to end understanding of all parts of your application independent of the different aspects of your application that change across different deployment providers.
I think we’re mostly on the same page, but I just don’t think it is a relevant or healthy concept. The moment you codify the idea of “end to end understanding” people will take that as a new minimum and I’d bet you anything we’d start seeing “Fullstack Plus” as the new buzzword as people start inflating resumes and job postings and egos.