As a frontend developer, I've always found it difficult to draw the line between what is considered to be frontend and backend development. Apparently I'm not alone in this!
My first job in a digital agency involved me working with HTML, Sass, and Coffeescript to build websites that match as closely as possible to the designs provided by the design team. In addition to this, I would work with Ruby on Rails, which our custom CMS was built on, to pull through data into the views.
I had a great mentor in that job, who taught me so much about Sass and code organisation, which I'm still very passionate about today (I can't thank you enough Simon!). As a junior I was thrown in at the deep end, and for me it was the best way to learn.
In my mind, this was a frontend developer's role, and it felt clearly defined at the time.
A new chapter
In 2015, I moved to a different digital agency. The frontend developers wrote HTML, Sass, and some JavaScript, and then passed it all on to the backend developers to hook up to the CMS.
Things have changed a lot since then, and now our frontends work with the CMS and C# Razor markup, as well as React and Vue when required. But it seems that since frontend frameworks have gained more popularity, the definition of what a frontend developer actually does has become even more blurry.
Other people can sometimes struggle to know which tasks are frontend and which are backend. Sometimes I feel as though people don't entirely realise the amount of work that is involved in frontend development.
We're in a sort of hybrid role that works between designers and backend developers to make sure your website looks awesome and performs well.
It also becomes difficult when recruiting new frontend developers. As a company, we pride ourselves on building websites that match our designs as closely as possible. People will literally tell me if an icon is a few pixels out. And I know what you're thinking, but that's not a bad thing. It has made me better at my job and the smallest changes like that can have a massive effect on the final product. Everyone in the company knows this. It's a team effort and it's constructive. No one takes it personally. Everybody cares deeply about what we're creating.
The difficulty in recruiting a new frontend is that we need someone who is extremely capable with HTML, Sass, styling, and the design side of things - but also a great JavaScript developer. And it seems that they are more divided than ever these days.
The questions I have for the dev community are:
- Does anyone else struggle with this, or is it just me? 😁
- As a frontend developer, what do you consider your role to be? How would you define it?
- Do you feel that the title 'frontend developer' is appropriate for the vast amount of skillsets it covers?
- Have you had similar experiences in terms of recruitment, and finding someone with the same expectations in the role?
I think it's an interesting discussion and I have heard of instances where frontend developers feel under-appreciated because people "don't really know what they do". Also for the sheer amount of skills they are expected to know, in comparison with backend development.
What are your thoughts on this?
Top comments (33)
So I was originally hired as a UI developer. And yet most of the code I've written is for back-end code and minor tweaks to the front-end (none of them with styling). I think the divide of what is considered the front-end and back-end is more prevalent than ever.
Designer = Front-end dev role
Front-end Dev = Full-stack Dev role
Full-stack Dev = Unicorn 🦄
When I started working on React.js I knew it was the end of the separation between traditional frontend and backend. A colleague of mine and I where thrilled as we got to work on both logic and presentation (we are both full stack devs). Then I started to notice a lot of really great traditional backend devs who got thrown into the world of React and now struggling to grasp how to convert a visual design into a working html/css. It really baffled me why since Frontend devs have always been looked down upon by Backend devs. After all It's JUST HTML/CSS right? Now they know that is WRONG! It takes a really creative mind to look at a visual design and then architect/craft that into SEMANTIC ACCESSIBLE html/css. One thing is for sure, both traditional frontend and backend devs have now found new appreciation and respect on each other's expertise.
I think it's a spectrum.
Though in the end, isn't it a little useless to split things into front-end and back-end? Isn't it more important what types of experiences you have?
For example, writing the backend of a game-engine may be very different from writing the backend of a webpage with data stored in a SQL-database, even though both may be classified as "back-end"
I agree about not splitting them, and I mostly think of myself as just a “developer” because like you said, I do some tasks that could be considered “backend”. However there are still different skill sets involved.
First reply nails it.
Like any generalization of a complex topic, trying to pigeonhole a software developer into one of two categories is going to fail pretty massively at being descriptive of what they actually do. Like they are two separate checkboxes that have nothing in common. The fact that if you ask 5 different people what the terms mean you will get 7 different answers, and that every 5 years those 7 answers change, means to me that the value of these two terms is less than zero.
Yeah agreed, when recruiting we should try and avoid pigeonholing people as much as possible. This is something for me to think about, in terms of trying to get across the experience required > the job title/tools used.
Dividing the two disciplines was something I didn't like, and was quick to change when I started haha.
The problem I have is that everyone recruits for "frontend developers" and ask for HTML, CSS and JavaScript but when you dig into the roles the things you'll end up doing are really different. In one company you'll be writing a lot of CSS and thinking and about designs and UX, but in another you'll be writing mostly React/Angular and thinking about managing state and API calls - I find it really difficult to look for frontend jobs because of the vagueness of the term "frontend developer" 😥
I know what you mean! This is what is confusing both for people looking for jobs and for companies recruiting. They need to be really aware of what type of developer they need.
My position is officially "Front-End Developer". I primarily write and develop components for use in A/B testing. Primarily. I've also been developing a lot of tooling for helping make that process faster and more efficient.
Are these back-end tools? They're not running on any server, so I hesitate to call them back-end tools and myself a full-stack developer (at this job), but these tools aren't used in the front-end either.
I'm also on a very small team and have been heavily involved in trying out different tech and making overall design decisions for what we do. Does this now make me an engineer? I have no idea. Am I still a front-end developer?
The lines get more blurred and gray with each passing day.
This is pretty much how I feel!
Having a bit of a frontend identity crisis 😁
Isolation is the problem, and front-end vs. back-end is the same battle that waged in coding vs. administration. From that battle emerged the concept of DevOps, where things unified, and developers contribute to multiple components.
I see the same thing happen with front-end vs. back-end. If we consider this a protocol split, like a front-end may only talk JSON with the back-end, then a front-end developer will be severely stunted in their abilities. Creating UI's often requires changing how the back-end works. It's counterproductive to require a continual back-and-forth with other developers on every minutiae.
Being labelled front-end would imply your focus is on the UI, the most immediate part of the user experience. You will be the foremost authority when it comes to technical matters in code relating to the front-end. To somehow say this limits the code you touch, is counter-productive.
In all roles where I've worked on front-end, I've always touched code on the server as well. There's no way I'd be able to build the UIs I want without being able to do that.
That's really interesting, I like to hear what other people's experiences are. I've talked to various different frontend devs who have a variety of different ideas of what their job role is.
One of the things I've observed around the terrible-toggle of Front-end/Back-end is that there are two different perspectives of it - from the technical-side and the business-side.
You've already touched on the technical-side, where you tend to find people that fit the Back-end profile (system-programmers, micro-services, "everyone should learn C as their first language", etc) that 'look down' on people that fit the Front-end profile (Web-programmers, mobile, "everything that can be written in JavaScript should be written in JavaScript", etc) as a lower class of developers. This is a well-worn topic that I don't have much to contribute to other than the fact that I think it's bunk. We're all trying to solve the same 2 hard problems - cache invalidation, naming things, and off-by-one errors.
But that's an us-vs-them story between equals. The other side is management-vs-employees.
Senior management, like executives, look at things with a much wider lens and cannot deal with all the minutia of who does exactly what. Anyone who has been involved in any sort of long term planning/scheduling has experienced the process of dealing with the concepts of Person-months or Full-Time-Employee (FTE) months estimates against available capacity. It's obvious that treating everyone as interchangeable cogs is fundamentally flawed and yet if you need to do this sort of planning and you have more than 5 devs you need to do some sort of abstraction and generalization. I think the Front-end-vs-Back-end is too high-level and too general a solution but if you need a few, simple terms for C-levels to use across the industry I don't have a better answer 😛.
I agree completely with it being more of an issue with management vs technical. Definitely not trying to have that same old discussion about front end vs backend.
I tend to think that most developers can work with what they are given, we’re all problem solvers!
I guess it’s that for planning purposes we need to fit under a certain label for various reasons, but it’s difficult when it’s such a broad spectrum.
The split is slowly dissappearing. But as always, you'll do better the things in which you have more experience. We have the same skills, but use them for different purposes.
In the end I think we'll all be just devs. You can be an expert styling or an expert implementing Rest APIs, but you are just a dev that happens to have more knowledge of one specific topic.
The dev that is a CSS expert can implement a Rest API and the Rest API expert can style using CSS, but you'll do better&faster the things you're used to do.
Front-end = code executed in the browser.
Back-end = code executed on the server.
However, I'd expect any developer that classifies as one to at least have a little bit of knowledge about the other.
Being a front-end developer is context dependent. Being a front-end developer that does design-heavy work with light JavaScript than a front-end developer who works on complex React applications.
you are not alone~ =)
css-tricks.com/the-great-divide/