This post is not just another take on the never-ending “generalists vs. specialists” debate. We'll be looking at one specific area – web development. We won't be talking about mobile apps, machine learning, game development, and whatever else is on the horizon; this post is about web development only. So let's start with a brief history of how it evolved in the last two decades.
The major shift happened somewhere in the 2010-s when frontend frameworks emerged. A remarkable demonstration of what they made possible is Trello, a popular issue tracker released in 2011. It was built on the Backbone.js framework, which was cutting-edge technology at the time. Since Trello used the Single Page Application (SPA) architecture, it didn't require a full page reload to interact with the server. And it felt fast! Trello was very popular, thanks to its good design and a generous free plan, so many people tried it and are still using it.
Trello wasn't the very first SPA, of course. Another famous example is GMail which was introduced in 2004. However, Trello was built on a frontend framework, and frontend frameworks promised to do a significant amount of heavy lifting for you. It was around early 2010-s when frontend frameworks really started to take off: Backbone and Angular.js were released in 2010, Ember.js in 2011, React.js in 2013, and so on.
I'm not sure if it was pure coincidence or a result of Trello's popularity, but at that time TODO list had become a canonical example, showcasing the capabilities of JS frameworks.
Simultaneously in the 2010-s there was an explosive growth of APIs:
Many organizations realized that building APIs could be a way to save development efforts and move faster. The same API can be behind a web application and a mobile app, and when needed, it can be exposed outside and used by external integrations. Widespread adoption of the REST API concept has further boosted the API development.
And so, some developers started to specialize in this area and call themselves frontend developers. It seemed reasonable because the industry was moving rapidly. All that additional complexity required additional time to study, and developers were always in demand. Many “traditional” web developers converted to backend developers and were glad they wouldn't have to deal with that ever-changing frontend mess.
APIs became a natural separation of responsibility between the backend and frontend. Backend developers would build an API, and frontend developers would build a web application on top of it.
The separation of backend and frontend roles provides two major benefits:
Some people would argue that there are additional benefits of faster and/or better quality development due to higher specialization, but it's not always the case. It could be true for some projects and false for others due to the reasons outlined in the next section.
Not everyone has hopped on that backend-frontend separation train, though. Simultaneously with frontend developers, a competing role emerged – full-stack developers. They were specifically required to work with both the backend and frontend, like in the good old days, but with modern technologies. Facebook is a notorious example – there was a time when they proudly stated that they hired full-stack developers only. You can also find full-stack positions in Google, Netflix, and many other reputable organizations.
Why hasn't everyone embraced that frontend-backend role separation? Well, because it isn't free. Besides the benefits mentioned above, there are some issues, most notably:
Extra dependencies to manage. Backend and frontend separation has introduced a dependency. Frontend developers rely on an API but cannot build it themselves. As a result, they need to talk to backend developers first, agree on the API design, and then wait until backend developers implement it. If they don't have other tasks to work on while waiting, they can build an API mock, work with it in the meantime, and then replace it with a real API. If later they discover that something is missing in the API or it doesn't work as expected, they need to talk to backend developers again and then wait for an update or fix.
Mediocre APIs often emerge as a result of such separation. Sometimes, frontend developers can see that the API they're using is not perfect, but at the same time, they can work around it with some hacks. Of course, ideally, they should report it to backend developers and suggest improvements, but that entails some friction, so issues often end up being neglected. For backend developers, it could be harder to see usability problems with their APIs because of a lack of “dogfooding” – they don't use what they build themselves.
Workload distribution problems, especially in smaller teams. It's much easier to prioritize work in a team of full-stack developers because all of them can work on any task. The percentage of the backend-vs-frontend work during the project's life may vary. With dedicated backend and frontend developers, their workload is often suboptimal. Frontend developers could be overloaded with high-priority tasks, and backend developers cannot help them, and vice versa.
Some technologies cross boundaries. Let's take Server Side Rendering (SSR), for example. With SSR, the same code is executed on the server side and then in the browser. Technically, it is closer to the frontend since it mentions the frameworks that frontend developers are typically using. However, frontend developers would no longer be in their traditional territory – they would be running their code on a server. Another example is Hotwire for Ruby on Rails which was introduced in 2021. This takes an alternative approach, suggesting adding interactivity to web pages without traditional SPAs and APIs. WebAssembly is another interesting technology for high-performance code that can run on both server and client.
Lack of product thinking. Since full-stack developers work on all aspects of a task, they tend to understand better the big picture of what they're building. Frontend developers see how people would interact with software, but they may have a vague understanding of its internals. Therefore, it may be hard for them to decide what would be easy to build and what is challenging, and which optimizations are possible. On the other hand, backend developers understand the internals very well, but they may not look at the product from the end user's perspective.
What has changed in frontend development since the 2010-s? Well, many things, but most importantly – it has matured:
This is not to say that all problems on the frontend are solved, but today it's much easier to work with it than ten years ago. Yes, a large portion of complexity is still there, but it's no longer such a mess, so there are fewer reasons for backend developers to hate it.
It depends. There could be no benefit from full-stack developers in areas of your project with little or no back-and-forth between the backend and frontend. Hiring dedicated backend or frontend developers is easier, and it matters.
However, if interactions between the backend and frontend happen regularly, and most tasks require working on both parts – then maybe consider hiring at least some full-stack developers. Hiring would be more difficult, but it's certainly doable. I know it first-hand since we've been hiring full-stack developers at ivelum for years. If you don't take it from me, take it from Google, Meta, Netflix, and others. High-qualified full-stack developers do exist, and it is possible to find them.
You can also have a hybrid team – some frontend and backend developers and some full-stack folks to take the best from both worlds.
When you read these lines, I bet you already know the answer. It's perfectly fine if you don't want it – specialization is nothing wrong. Most job offers nowadays are for frontend or backend developers, and it's very unlikely that it'll change anytime soon.
If you'd like to give it a try, then go ahead! Even if you are not going to apply for a full-stack position, a better understanding of what happens on the other side will help you to see the big picture and be a more productive collaborator. And if you really invest in it, you'll be able to apply for a broader range of jobs and build complete features from start to finish.
Here are a couple of random thoughts on this topic:
And that's all I have for today. Happy coding!