When I was early in my career and working for one of the big tech companies, I was usually the most junior developer on the team. And often times, I picked up tasks that no one else wanted. Because I was working with a lot of senior developers, that meant a lot of frontend tasks. You know - things that were not considered “real development”.
Frontend development was painful and it was subjected to tragedy of the commons.
Frontend development has come a long way since then. There are frameworks, turing complete type systems, there are build tools (that are not shell scripts), you write CSS in JS and you code against a virtual DOM.
- Reconciling state via event-sourcing and compaction is the core concept behind the de-facto state managemeynt library for React. And it all happens in the browser.
- You come across use-cases you need to be mindful of the trade-offs that need to be made in using immutable constructs vs. mutable ones.
- Observables are part and parcel of any complex frontend application. Piping
onChangeevents to an observable, throttling, debouncing and filtering those events dramatically increases the readability and the maintainability of the code.
- You don’t have the luxury of
/var/tmpto write things and retrieve it later, and every API call to use an exernal data store may or may not succeed.
localStoragemight not be reliable enough. Or worse, it might succeed but HTTP transaction would fail for whatever reason, in which case you’re in big trouble if your updates are not modeled to be idempotent.
You’re not solving 2010 problems anymore
As a frontender, your scope had grown from being competent with flex-box and DOM APIs, to solving a subset of the problems that we see in distributed systems, and having the knowledge to make the associated trade-offs.
Sure, the scale of the problem might be different, but you have new challenges:
- Running the same code in web browsers built by hundreds of vendors for thousands of devices with vastly different specs provide new challenges. The usability of your software cannot be dependent on how good the connection to the server is.
- You don’t have the luxury of turning things off and on again. There are many many layers of caching between your frontends assets in a production server and the user. Production errors are expensive, but the complexity remains the same.
Perceptions don’t change as fast as technology does
Sure, the world has changed dramatically in the last 7-8 years for frontend development, and we’ve had mammoth paradigm shifts like - “Let’s code against a virtual dom” and “Let’s write plugins for a compiler so we can evolve the ECMAScript standard faster”.
But in the human world, perception do not change with the same velocity.
Anecdotally from my experience and people I know, having “frontend developer” in the CV will fit you in a box that is very hard to get out of. Both while being recruited and after getting the job. I’ve been in large organizations where people stop doing frontend work, to distance themselves from the impression that they don’t want associated with.
This 2014 article from udacity sums up my point the best:
A front-end dev is responsible for the interior design of a house that’s been built by a back-end dev.
There’s nothing wrong with being an interior designer, but there exists a large enough volume of real engineering problems in this space. And this “perception problem” turns away the very people who want to solve hard engineering problems where it counts.
In some parts of the industry, where the formerly technical reign supreme and the edicts are handed down to non-technical recruiters, the situation is so bad that the “senior developer” is mutually exclusive from “frontend developer”.
Technical people are after all, people. And people like putting things in mental boxes. It is my opinion that there isn’t consensus yet on where the competent 2020 developer with frontend skills reside. I don’t think using “full-stack” to solve the problem helps as well because it’s too broad.
In the meantime
My strategy has always been to translate the knowledge I have in the frontend to backend systems and vice versa. (You might be surprised how much in common Redux has with Kafka Streams conceptually). The more I do, that more I realize that the fundamentals are the same. The same way buoyancy, collision avoidance, and recycling water are common problems to both light cruisers and submarines.
The path to being a competent developer lies in both sampling a lot of technologies, and finding a subset that you can specialize in. If you do hope to specialize in the engineering problems of the frontend, I recommend you don’t call yourself a frontend developer.