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?
Latest comments (33)
Imo, 2 relatively recent trends have redefined the traditional frontend/backend developer roles.
1) The rise of thick-client SPAs. Anything that's not a Wix or WordPress website these days is most likely adopting an SPA architecture. You'd think that the decoupling an SPA brings would more clearly define frontend/backend roles, but ironically, the opposite seems to have happened.
My opinion for this is that creating a legit SPA is very complex; state management + other complex topics like packages, build pipeline, etc. Are almost always integrated with the view layer. So a "Frontend" developer must now have a good understanding of JavaScript, well beyond the knowledge needed to render static HTML or change a font's colour with CSS.
And if you know frontend JS well, you basically know node.js too - so what's stopping you from writing server-side code?
2) Emergence of serverless functions. Admittedly, adoption still doesn't appear mainstream. But the ecosystem is growing and greatly reduces the barrier of entry to writing backend code, by doing away with the overhead of managing servers etc.
So there's no reason a dev working with a frontend JS framework wouldn't be able to quickly pick up writing backend code as a serverless node.js function, for example.
Finally, I think other innovations like GraphQL's client-driven queries are further closing the frontend/backend gap. Everyone has to be - to some extent - a full-stack dev these days.
Just my opinion. And I believe it's a trend that will only accelerate
In my country in fact we do the following separation:
UI designers - this are people working before the web designers usually only on the UI mostly including photoshop, illustrator and etc.
UX designers - this are people working before the UI designers only and mostly on mockups... showing what elements and screens and navigation we will have nothing more.
I would explain it in steps in my company:
1) the UX guy speaks with the business analyst and by knowing what stories exists creates the UI of all on prototype mockup level without any colors or fonts or anything.
2) the UI guy takes the mockup and makes it beautiful but in a picture mode.
3) the web designer takes the psd and converts it to HTML, testing and taking care of all browsers rendering all the same.
4) the frontend developer using a mockup rest service like mocky.io (mocky.io/) makes all work but on a fake static responses, he also creates tests with chakram for example verifying the STRUCTURE of otherwise mock responses.
5) the backend developer develop a rest endpoints and make sure that the frontend chakram tests works ones they work this is merged with the frontend and a configuration endpoint properties are changed.
6) the QAs and BAs starts to test and if something from an UI perspective is broken a BUG is created and the BUG starts from step 3 or 4 or 5. Usually 1 and 2 and 3 are already confirmed and approved by the client and if there is a change there it is a new user story starting from step 1, bugs starts from step 3.
What I missed is step 0 the discovery phase where the business or functional analyst speaks with the clients and comes with a set of 1 or more user stories.
Started out my first job as a frontend engineer with the devops mentality of "being frontend engineer means delivering the best frontend product as possible, including browser app, desktop app, Unity and Unreal Engine library".
I raised up to architectural role in 8 months. I mastered frontend while learning the fundamentals of backend, infra, management, and other fields that I haven't mastered yet.
Being frontend dev at heart, I will asks the engineer manager for engineers that masters the problem my team is facing, preferably with the same devops mindset. Having everybody having different mastery but the same devops mindset is the best scenario possible for an engineering team.
I think it's a misnomer to set the skillset of "frontend developer" to only html, css, javascript.
Frontend developer's skillset should be Information Architecture, User Interaction Design, and User Interface design.
If a company wants to hire engineers with more specific skillset, they should present it as "Software Engineer - Frontend - HTML CSS".
I do have met some people having the same expectation and I feel that they can still broaden out their skill to either UI/UX design or non-presentational layer of javascript.
I'm also confused with what a front-end developer really is.
My question is: What Javascript skill should a front-end developer do?
From my point-of-view, it should be more of DOM manipulations rather than data (connecting to API's which is JS/TS) right? Because it's vast and it's somehow technical.
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.
Well, when CoffeeScript was a thing there was already a clean cut between fronend and backend.
Before that, with PHP, it was simply one huge blob 😂
IMO backend developers are typically the ones who primarily work on C, Rust, Go, or any other low level programming languages.
Anything else is qualified as frontend, or if you feel like you're more than that feel free to call yourself a full-stack developer 😀
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 the biggest fault was muddying the title of Designer.
Yes, when you devise the shape of a public web/programmatic API, you can say you are designing it. Yes, devising a schema for your data in a database engine can be called "design" (as opposed to "engineering" and "programming", which sound like developing/extending the DB engine, and "administrator" which sounds like application-agnostic Ops).
But a front-end designer is an actual traditional "designer".
You might as well call them a web designer, if that didn't have a connotation of traditional flat sites as opposed to rich apps.
They aren't about the accessibility, they aren't about the usability (that's UX), they just implement what the...
Wait. Who is the one that draws mockups in Photoshop/Illustrator or specialized wireframing software? Not graphic designers, those make art and illustrations. Not brand designers, those are about the style, not the particular screens.
Oh no.
We are doomed.
I thought I could define them by what they are not.
But we don't have enough things names.
This is the end.
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.