[Swizec]

We can't solve this problem until we at least agree what "full-stack" even means.

Right now you have many frontend-focused engineers who justifyably argue that something like React Server Components is a backend concern because it runs on the server. I think they're wrong but they have a point.

You also have many backend-focused engineers who justifyably argue that something like Rails is a frontend concern because it's designed to run webpages. You probably wouldn't want to use Rails to build an ETL pipeline or an airline scheduling system, for example. I think they're kinda right but also a little bit wrong.

And ultimately the whole debate is so deep in the It Depends territory that I honestly think 90% of the people arguing come from such vastly different backgrounds and situations that they're just talking past each other. They're never going to agree because the problems they're solving are too different to ever have the same solution.

edit: I say this as someone with professional experience in almost all the usual suspects (Django, Rails, Flask, various JavaScript frankenstacks, even PHP).

[ianhmacartney]

Very much agree. The tools for various jobs differ widely. However, my current take is that full-stack is more about enablement of engineers vs. a specific product or technology. Things at the protocol level (ProtoBuf, OpenAPI specs, etc.), things at the framework level (fancy types with tRPC or Convex), things at the application level (dropping in full stack features by someone without deep expertise in both domains) all qualify in my book. And rather than a discrete "you are now a full-stack dev, my child" moment, it's about blurring the line, the same way that k8s lets some backend folks play SRE here & there.

Background. My career has spanned these in different ways:

Front-end: I started in iOS in 2010 (back then it wasn't called iOS yet - just iPhone), where I was a more pure frontend dev. The server was using python and Haskell and that team was the "cool kids" in my view. The backend/frontend contract was using ProtBuf over a socket (not WebSocket, which hadn't been standardized yet), so we really didn't work closely together, and no one was "full-stack".

Backend: Wanting to be a "cool kid" I joined Dropbox and eventually was the technical lead for Dropbox Previews, generating video, pdfs, images for user content using hundreds of machines, using a combo of Go and Python. I didn't work very closely with the myriad of teams using the previews for various products (their interface was the HTTP endpoints we exposed). One fun statistic: if you removed the cache and processed the full file for every user’s request, it would amount to processing over one exabyte of data per day.

"Full-stack" tbh my experience crossing the gap is only somewhat recent (last 5 years or so) where I did freelance / contracting for various startups and established companies. I brushed up on React, learned TypeScript, but still mostly focused on backends - which usually ended up overly robust for the level of operational expertise of the companies I was handing the projects off to: like handing off a full kubernetes setup for running some GPU machines and orchestrating some fan-in / fan-out pipelines for ML image processing, when I'm sure there were mostly-fine ML workflow companies I could have used.

Anyways this was much longer than anticipated but hope it adds some color