The thing I find frustrating about the idea that frontend dev is "for juniors" is that nobody would say it about other specializations.

Someone might say that it's *better* if a compiler author worked in a more full stack role.

They *wouldn't* say "compiler writing is for jrs"

Fundamentally, when people say "frontend is for juniors" they're making a few big mistakes.

Here's two of them:

1. They're underestimating the inherent difficulty of the work.
2. They're accepting memes that ridicule front end tools to color how they look at frontend developers

1. Frontend work is inherently challenging.

First, the technical work is challenging. It involves asynchronously communicating with a server in a situation that frequently involves unexpected errors in real life, while keeping the UI interactive.

At a very basic level, this is just hard. The equivalent of "the user closed their laptop" is "what if my SQL queries in Rails just failed randomly 5% of the time".

Beginner frontend devs don't think about it, but more experienced ones absolutely do.

While backend servers are largely stateless (and we like them that way), frontend applications allow the user to trigger an asynchronous request fo some remote data and then continue interacting with the app in arbitrary ways.

In backend servers, you get a largely consistent view of the world you can operate within (via ACID DB transactions), on the front-end, you incrementally grow a local cache of data that has no guarantee of being internally consistent.

Again, if you think "nobody actually works on that stuff lol" you're sorely mistaken.

Experienced front end developers spend a LOT of time thinking about how to structure their applications to minimize these issues in a way that folks with less experience can understand.

Another way in which frontend is inherently challenging is: frontend the place where the rubber meets the road on interacting with the user.

User requirements impose more constraints on what the code can get away with.

The frontend is what higher ups in your company think of when they come up with new ideas for the app.

And they very often have very particular opinions about what that frontend should look like and how it should work.

Tiny mistakes in frontend code are noticable by company execs and managers, but also users.

A frontend emergency could be triggered by a styling mistake that made one box overlap another on some random sized screen that nobody tested on.

There's nothing equivalent on the backend.

TLDR frontend devs are tasked with the requirement of implementing the part of the application that your users and execs know how to have opinions about, and know how to report bugs based on those opinions.

Frontend devs have to implement ideas (and adapt to the opinions of execs and users) in a fairly hostile environment (weird browser, ad blockers, translation extensions, etc) where the user can create weird app states at any time by moving to a part of their house with bad wifi.

And this is important: experienced frontend developers *absolutely* work on these hard problems, and try to make the solutions understandable to less experienced devs.

Some of them can be solved in frameworks, but many of them are hard to solve fully generally.

And finally, because it's actually true that frontend is an onramp to engineering for less experienced devs, experienced frontend devs work to make their solutions to these problems general enough for someone right out of bootcamp to use productively and correctly.

I've seen this at many, many companies, including Tilde. Experienced frontend devs serve as mentors and designers for the *experience of being a new developer at your company*

This is all very hard, and can easily become a specialization that consumes one's professional career. It makes no sense to single out frontend devs and call all of that something that only juniors should specialize in.

Now, I do agree that every technical role would benefit from more exposure to the full stack.

Personally, I work on Ember core, Rails backend code, and Rust backend code when I work on @skylight.

I think this is a good thing.

But nobody would ever say "Specializing in our rust backend only makes sense for junior developers in our company." Fundamentally, saying that about frontend devs drastically underestimates the difficulty of the task front-end devs are tasked with.

So that's part 1.

Part 2 is a (frankly comical) degradation of frontend tools.

As a person who's built a lot of tooling infrastructure in my day (bundler, cargo, ember inspector): front end tooling is often head & shoulders better than the tools people often smugly prefer.

JavaScript isn't unique in benefiting from transpilers. Wouldn't it be great if the C++ ecosystem had a norm where C++ 20 features largely worked on older versions of the compiler (the ones still in wide use) by transpilation?

It's not a particularly easy norm to establish, but it's true that in the JS ecosystem, you can use brand new features (and even some experimental features) even if you target much older browsers.

And it's not just true that you can transpile the code: ecosystem tools like eslint, IDE language servers, syntax highlighters, and TypeScript support, at least, the bulk of the most recent version of the ECMAScript spec well before it gets finalized.

Speaking of TypeScript, TypeScript is a best in class gradual type system for a dynamic language. Maybe with the exception of Racket, nothing else even comes close, especially when you consider ecosystem integration and tooling polish.

And this whole story works pretty seamlessly with a popular JS extension (JSX) that's not even part of the ECMAScript spec.

So you can write your code in TSX using ES2020, get polished linting and tooling, and then compile it behind the scenes to older browsers.

And not by manually specifying a bunch of features you know your browser needs.

The defacto standard way to specify what features need to be transpiled is with a browserlist specification, which allows you to say "last version of chrome" or "browsers with 1% market share"

So you just use ES2020 and TypeScript, specify the browsers you need to support (using a flexible description that's based on ecosystem maintained data at caniuse) and you seamlessly get a build that works in the supported browsers.

Need to support Node: the path is paved too.

On top of this, browser developer tools are vastly, vastly better than the tools available for most languages, certainly when you consider how easy they are to set up and how accessible they are to people across the experience spectrum.

Make fun of npm all you want, but the ways npm differed from Bundler strongly informed my Cargo design, and the Rust ecosystem is better off for not having a "only one copy of your dependency, even if it's only used privately" constraint.

There are certainly ways in which npm could be better, but it's been impressive (and inspiring) to watch the slow and steady improvement of npm over the years (decent dependency resolution these days, lockfiles ).

Yarn workspaces are being picked up in npm and pnpm, which puts frontend to the first tier of languages with good monorepo support (not perfect, but definitely first tier).

On top of all that, JS bundlers need (as a matter of basic survival) good support for code splitting and dead code elimination in a way that's understandable to less experienced devs.

They also need to be able to support dynamically loading in parts of the app in a way that's compatible with the module semantics that were originally authored.

Yes, DLLs are old. No, they don't work seamlessly with everything I said above without wizard level knowledge.

And none of these constraints are accidental or "overcomplicating the problem".

Front end development is an intrinsically difficult problem. The payoff is that we get to write applications that run on any operating system, somewhat older machines (and OSes), ...

different resolutions (from small phones to ultrawides), assistive technology, and versions of all of these things that don't even exist at the time you write the code (with the expectation that it will mostly keep working, there's no stop-world upgrade for your user's machine)

In closing: I totally agree that people should try to be generalists in applications, and that an overfocus on a single specialization can blind an engineer to important details.

But that doesn't make front end a specialization only appropriate for "juniors".

In my experience, it's easier to sink one's life into a frontend specialization than a specialization in something like Rails, and still be providing a ton of value as you learn more.

This is perversely caused (in part) by the fact that frontend is accessible enough to be a beginner specialization.

This makes experienced frontend specialists responsible for a *lot* of mentoring new developers.

It also makes experienced frontend devs responsible for creating abstractions that solve all of the above problems in a way that is accessible to a truly broad range of developer experience.

If you're a frontend dev, don't let anyone make fun of what you do, and don't let anyone treat frontend dev as "easier" or less appropriate for specialization than the more traditional backend roles.

Think of yourself as a hero who is directly responsible to the user and execs, responsible for making your application work in an extremely hostile and unknown environment (when compared to "run a go process in docker").

You're also responsible for building abstractions that the entire spectrum of experience at your company can use, because the least experienced developers at your company need your help.

And we're all here to help each other extract useful bits of functionality and even entire frameworks that can allow experienced developers accomplish all of that without constantly building the universe from scratch just to make an apple pie.

My frontend friends: I love being in a community with you.

Let's keep proving the haters wrong and shipping awesome stuff to users of all kinds of different computing devices. Let's keep dazzling people with what we can accomplish together.

We rock! Rock on!