I like the term Front-End Developer. It’s encapsulates the nature of your job if your concerns are:
- Building UIs for web browsers
- The spectrum of devices and platforms those web browsers run on
- The people who use those web browsers and related assistive technology
The breadth of knowledge for all-things front-end development has gotten super deep. I’ve found that front-end developers that have stretched themselves to the point they are thinking of themselves as full-stack developers more and more. I think that’s kinda cool and empowering, but it doesn’t mean that everyone needs to go that wide.
Brad Frost referred to sides of the spectrum as “back of the front” and “front of the front.” I once drew the line, in The Great Divide, as heavy JavaScript vs. not. These distinctions aren’t to divide people, but to acknowledge the spectrum and that there are people all over it.
In a new article called “Frontend Design, React, and a Bridge over the Great Divide,” Brad makes the point that the role of “Front-End Designer” exists on the spectrum right smack in the middle between design and development, where “development” refers to the back-end or deeper JavaScript stuff.
The jobs?
- Crafting semantic HTML markup
- Creating CSS code
- Authoring JavaScript that primarily manipulates objects in the DOM
- Testing across browsers and devices
- Optimizing the performance of front-end code
- Working with designers
- Working with back-end and application developers
That sounds like the “traditional” explanation of a front-end developer to me — if there is such a thing — but it makes sense to rename that role since front-end development is the term that got so wide.
Brad adds these responsibilties to the list:
- Create a library of presentational UI components
- Author and document a robust, intuitive component API for each presentational component
- Determine how flexible or rigid the component library should be
- Maintain the presentational components as a product
That’s where I think this metaphor comes in:
Me, Brad and a slew of you out there are front-end developers. We work in browsers and we care about the users and where and how they interact with those browsers. We do the things on Brad’s first list like craft HTML and CSS, work with designs and do testing. We share that common trunk of skills on the tree above.
But Brad is more of a systems designer than I am. His dot lands somewhere differently on that tree. I don’t know if I’m particularly skilled at anything, but my dot definitely falls elsewhere on that tree. Perhaps on an entirely different branch, as I quite like working with JavaScript tooling and logic and APIs and such. The bulk of Brad’s article is about React and finding a place in the realm of front-end development where the job isn’t ignoring React, but working with it in such a way that doesn’t mean every other aspect of development doesn’t have to come along for the ride.
Think about it as a new building. It’s not put together with stones and cement anymore. It’s putting together premanufacted walls, that need to fit in each other. We are architects that know how the systems others did work and how to put all together, even if we are not the ones that actually build the walls. We need to know every new system and how they interact with the old ones. We bring together the consumer needs and those given by the manufactures. We are the architects, we are front end developers, not the
plumber.
That’s a pretty nice way to describe our job to non-techy people!
Nice article
As someone who has always done a little of everything, these distinctions don’t mean a whole lot to me. One important thing I do think about is a few critical primarily “back end” concerns that I fully acknowledge are not my area of expertise, like database performance, security, and networking concerns. In those cases I bring in someone to either do the work or consult on what I’m doing.
So really it’s all a matter of what skills you have (or want to have). I even knew a guy once who was really what you’d probably call a “back end” person but for some reason he had really gotten into CSS. Didn’t care about design and didn’t touch javascript, he was just good at making a working page look just like the design.
I’m from Europe, not the U.S., and I don’t get all these articles and rants about different titles and roles. Does a title carry much more meaning over in the US? Who cares what you guys call yourselves, it’s what you do that matters. If you wanna do more design-oriented work, speak up and tell your employer, if you want to do more programming, say that!
It’s up to each person to communicate what they can, and want to do in this industry, it’s not something a blog post or tweet can dictate. This is just overblown by bloggers and “influencers”.
A title is just a word a person or company chooses at random, it doesn’t mean anything, it doesn’t represent anything.
Start caring about the WORK, not the title.
The title matters insofar as others who you work with use it to define what you do. It was a surprise after I was hired by my current employer, as a front-end developer, to find that HR put “designer” in my title. I feel like it limits me beyond belief, putting me in a little box where people are surprised when I ask to be involved with code (to put it lightly). It matters a great deal when your title doesn’t accurately describe your skills and others are using your title to assign you work.
Nice one
I am not worried about the labels, except in as much as they inform HR and Managers. And they do.
I worked at an ad agency in 2014, and they were aware that some people are better at CSS and other people are better at Javacript. (And, some people are good at both.) Because they were concerned with both Code Functionality and Design Fidelity, we had people on our teams who could cover the spectrum.
But in almost all job descriptions, I see an emphasis on Javascript. It is assumed that “anyone” can do HTML and CSS. They are not thought to be difficult skill areas.
Given that companies are also trying to reduce the number of developers by making front-end developers do full stack, there is a compression of people to work load, but also a reduction in the value placed on skill sets.
This bias impacts the products we produce. It can create complications for Designers and UX, and by extension the Users.
Since these are our skill areas, we need to have language to describe the range of capabilities we cover. Where are they applicable and how can we work to produce functional, useful, engaging sites. If we can’t talk to people outside our competency areas, we will not be able to accurately represent the work we do.
As an illustration, physical engineering has many Disciplines, Civil, Electrical, Mechanical, etc. They don’t, at this point I think, argue with each other trying to claim the simple “Engineering” title for themselves. They don’t have to cram all of their areas of expertise under an uninformative Mono-term.
Instead of arguing over the exact range of the simple term “Front End”, with each of us projecting our own expertise as the locus of the definition. Lets continue to discuss this and arrive at language that allows us to talk about the varied and constantly expanding range of capabilities we cover.
What I like about this is that as someone who feels the pressure of needing to always learn new skills. It instead shows that crafting your current skills depending on what you do is still a great approach to becoming an amazing front-end developer.
I wonder if better titles would be “UI Dev” vs “API Dev”. A UI Dev would handle anything the user actually interacts with, while the API Dev would handle state management and how the app interacts with the server. An API Dev would also be better at working with databases while the UI Dev would have legitimate design skills. A “Front-end Dev” would run the full gamut of the client side, but not expected to be an expert.
This also indicates to me that the term “full stack dev” is becoming increasingly outdated, there’s just too much going on to produce professional quality work in ALL areas at the same time.
Nice. Google has a term for this already. UX Developer. This is ME. Finally.
April 1st, 2004.
That’s when Gmail launched, and in doing so, initiated the modern era of “web apps”. Suddenly, there was a realization that you could do a lot more in a browser than just build a marginally-interactive website. You could use some advanced JavaScript to build something that functioned like an actual PROGRAM.
The Great Divide, as you call it, began then.
So here’s my proposal, informed by that 15-year-old history: Leave the term “Front-End Developer” to refer to the original meaning, the HTML/CSS people—those of us who can make a perfectly functional and beautiful website without a single line of JavaScript if need be. For the other side of things, for those who focus on programming in JavaScript, coin a new term, “Front-End Programmer”.
After all, that’s what each “camp” does. The one develops websites. The other programs web apps.