To the contrary, I feel the distinction to be very arbitrary and especially in the context of web applications so muddy it’s almost useless. Who is responsible for websockets? CSP? JavaScript chunk caching? Web worker edge deployment? File uploads? HTTP/2 stream usage?

The web as a platform shouldn’t be constrained by two arbitrary, isolated boxes, because that’s not how it works. A software developer writing code necessarily has to get involved with stuff running on client and server devices and everything in between them out of sheer necessity, if they even want to understand how modern technology works in this space.

There was a time when “full-stack engineer” actually meant someone who could run an entire application end-to-end—HTML/CSS, backend, databases, nginx, Linux servers, deployments, the whole thing. As Big Tech productized those environments and startups realized they could merge multiple roles into one salary, the title became increasingly attractive. People saw the compensation associated with true generalists and started putting “full-stack” on their CVs even when their experience only covered a slice of the stack. Bootcamps and junior developers adopted the term too, and hiring managers kept accepting it because the candidates were otherwise solid.

Now the title has been diluted to the point where it often just means “comfortable with JavaScript on both sides of the wire, plus maybe Mongo or Redis.” The original depth is gone, replaced by tooling and abstractions that compensate for the skills the term used to imply.

It’s a sad world.

-- actual (retired) full-stack engineer

It's really not hard to be good at both. Or at least to understand enough to be fluent in both.