As a frontend developer, I've always found it difficult to draw the line between what is considered to be frontend and backend development. Apparen...
For further actions, you may consider blocking this person and/or reporting abuse
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.
you are not alone~ =)
css-tricks.com/the-great-divide/
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.
I feel like because the technology is growing so fast and it's always changing, every developer feels this way. What is my focus? What is my role?
Most developers are constantly learning and practicing everything it's hard to say until you get a role that demands you focus on x technology.
So it seems open for now but I believe it's safe to break down into:
Front end
Back end
Full stack
And then an explanation with your primary tech stack focus.
Like front end angular or front end Vue or backend python etc., And I also know X technology.
In the case of front end that is more CSS orientated I think the role web designer or web developer seems to still fit even though most people who code CSS probably don't spend a lot of time on the actual design. So even that gets tricky.
If you design websites more and code a little: web designer.
If you design websites a little and code more: web developer.
In the end a company will be small or large. If they are large they're going to need focus on a specific stack. And all you have to demonstrate is that you've built stuff with that stack and you know it well.
If it's a small company they're focus might be on a specific product and are open to you figuring out ways with whatever technology you prefer to simply work on the product.
Thanks for your reply. I think that it's all the variations of the role that make it hard for companies to understand!
I get your descriptions, although I'm a frontend developer and definitely couldn't design a website. Like, not at all. I see a good design vs bad, and can take designs and recreate them very well in code, but you certainly wouldn't want me designing your website 😁
It's really confusing in these times to navigate between the frontend/backend spectrum. On one hand I have come across job descriptions that wanted html, css, js, sketch, photoshop etc i.e more design related skills, and on the other hand there are job descriptions that want angular, react, python, SQL etc and they both have the same job title - Frontend Developer.
I totally agree with what Michel Klages pointed out. It would also be great if the companies be more open about what type of experiences they are looking for in a candidate and what kind of work they are expected to do on the job rather than just focusing on the job title.
I agree completely! And that's good advice in terms of how companies should advertise for this job. I haven't done much in terms of recruitment before so it's good to hear what people would like to know on a job ad.
The line has definitely gotten blurry for me very fast in my career. Most of my work as a front-end dev is making UI changes and getting things responsive and accessible. But I increasingly get tasks focused mostly or entirely on back-end changes, such as recently adding model validations to our Ruby on Rails backend.
My rule of thumb for things outside one's speciality is "knowing enough to be dangerous." I try to know enough about Ruby and the Rails framework so I can grasp basic functions and infer how something works by reading it over. I still needed some help to get those validations right, but they were small corrections and not the "you need to do things an entirely different way" kind of feedback. Following this rule I've been helping to blur that front-end/back-end line, but I honestly think that's inevitable for development teams. The rate of change today has just accelerated that.
I would say my front-end title speaks more to my speciality than as a limit to my skills. I learn the most about CSS and JavaScript, but that doesn't mean I won't write Ruby scripts or side-projects either. Semantically, I think web developer titles will communicate more "I focus mostly on this along with other needed skills" instead of "I do this and nothing else."
The downside is how this encourages the "full-stack" myth. Helping more people understand that knowing at least the basics of everything doesn't automatically make them qualified for "full-stack" is a huge challenge.
I agree with everything you just said 😁
It's a good way to think of it as a specialty, rather than the only thing you can do.
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.
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
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.
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 😀
Hey Lynne. Great read. A lot of developers feel this same anxiety. If you haven't already, check out The Great Divide by Chris Coyier (css-tricks.com/the-great-divide/).
I don't think it's useless to split front from back. We're developers, we separate concerns. Front end means client side in my opinion. We're concerned with the client, or what the user directly interacts with.
I think the core of this anxiety has grown from the lack of knowledge in hiring processes. Companies love to hire someone who can wear multiple hats instead of multiple people with 'specializations'. From that, Back end, Front end, and Full stack have arisen. Full stack and back end is blurred/confused with architects, dev ops, and admins. Front end is confused/blurred with Full stack and UI/UX design. UI/UX designers are now being blurred/confused with Front end developers. There is a need to have an understanding of the different disciplines, but actually EXECUTING the work requires a specialized focus in my opinion. Cross-discipline collaboration is best when individual specialists are collaborating - not when one individual is expected to work cross-discipline.
Again, it comes down to the problems with how companies are hiring, and then it just snow balls out to headhunters and agencies, and then again to developers who are just trying to give themselves the best chance of being employable.
Look at this job description I just found in 5 seconds with Google for a 'Front end/UI Developer':
Preference would be given to candidates with:
Thanks for your reply! I have read The Great Divide by Chris Coyier, and it's a great in-depth look at these issues.
I wanted to get the Dev.to community's thoughts, discussion, and experiences on this as it is all so varied.
From my experience (and I'd hope it's the same for others), it's not as big an issue when you've been with a company for a while and they respect you, listen to you, and can recognise where your skills are and how to get the best from you. But I'd imagine, and I might be wrong of course, that it would be a bit of a nightmare for a junior dev right now who isn't quite as sure of what they are capable of yet. Trying to find work with such a variable job spec.
I think the best companies can do for now is be more up front about what they actually require you for when recruiting, and what specific skills are key to the role.
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.
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.
Before, developers coded for computers; today (frontend) developers code for (end)users.
Here's the game-changing!
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 😂