Let’s say there is a divide happening in front-end development. I feel it, but it’s not just in my bones. Based on an awful lot of written developer sentiment, interviews Dave Rupert and I have done on ShopTalk, and in-person discussion, it’s, as they say… a thing.
The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.
On the other, an army of developers whose interests, responsibilities, and skillsets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
Let’s hear from people who are feeling this divide.
In response to our post, “What makes a good front-end developer?”, Steven Davis wrote:
This schism isn’t happening under our feet. We’re asking for it.
This rings true for me. I enjoy working with and reading about modern frameworks, fancy build tools, and interesting data layer strategies. Right now, I’m enjoying working with React as a UI library, Apollo GraphQL for data, Cypress for integration testing, and webpack as a build tool. I am constantly eying up CSS-in-JS libraries. Yet, while I do consider those things a part of front-end development, they feel cosmically far away from the articles and conversations around accessibility, semantic markup, CSS possibilities, UX considerations, and UI polish, among others. It feels like two different worlds.
When companies post job openings for “Front-End Developer,” what are they really asking for? Assuming they actually know (lolz), the title front-end developer alone isn’t doing enough. It’s likely more helpful to know which side of the divide they need the most.
My hope is that the solution is writing more descriptive job postings. If clearly defined and agreed-upon job titles are too much of an ask for the industry at large (and I fear that it is), we can still use our words. Corey Ginnivan put it well:
I’d love more job descriptions to be more vulnerable and open — let people know what you want to achieve, specify what they’ll be working on, but open it as a growth opportunity for both parties.
“Front-end developer” is still a useful term. Like Mina Markham described to us recently, it’s who people that primarily work with browsers and people using those browsers are. But it’s a generic shorthand, says Miriam Suzanne:
Front-end developer is shorthand for when the details don’t matter. Like being in an indie-rock band — who knows what that is, but I say it all the time. Shorthand is great until you’re posting a job description. When the details matter, we already have more detailed language — we just have to use it.
That’s OK. You can still be a front-end developer. 🙏
You might be exploring layout possibilities, architecting a CSS or design system, getting deep into UX, building interesting animations, digging into accessibility, or any other number of firmly front-end development jobs. There’s more than enough to go around.
Remember just last last year how Frank Chimero, who builds incredibly great websites for himself and clients, was totally bewildered with where front-end development had gone? To summarize:
… other people’s toolchains are absolutely inscrutable from the outside. Even getting started is touchy. Last month, I had to install a package manager to install a package manager. That’s when I closed my laptop and slowly backed away from it. We’re a long way from the CSS Zen Garden where I started.
A long way indeed. I might argue that you don’t have to care. If you’ve been and continue to be successful building websites any way you know how for yourself and clients, hallelujah! Consider all this new toolchain stuff entirely as an opt-in deal that solves different problems than you have.
And yet, this toolchain opaqueness prods at even the people necessarily embedded in it. Dave Rupert documents a real bug with a solution buried so deep that it’s a miracle it was rooted out. Then he laments:
As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming.
Who needs these big toolchains? Generally, it’s the big sites. It’s a bit tricky to pin down what big means, but I bet you have a good feel for it. Ironically, while heaps of tooling add complexity, the reason they are used is for battling complexity. Sometimes it feels like releasing cougars into the forest to handle your snake problem. Now you have a cougar problem.
The most visible discussions around all of this are dominated by people at the companies that are working on these big and complex sites. Bastian Allgeier wrote:
Big team needs “x” that’s why “x” is the best solution for everyone. I think this is highly toxic for smaller teams with different requirements and definitions of what’s “maintainable” or “sustainable”. I get in touch with a lot of smaller agencies and freelancers from all over the world and it’s interesting how their work is often completely detached from the web’s VIP circus.
What is going on here? What happened? Where did this divide come from? The answer is pretty clear to me:
Through all the possibilities that swirl around the idea of serverless combined with prepackaged UI frameworks, a front-end developer can build just about anything without needing much, if any, help from other disciplines. I find that exciting and enticing, but also worthy of pause. It’s certainly possible that you become so framework-driven going down this path that your wider problem-solving skills suffer. I heard that sentiment from Estelle Weyl who goes so far as to say she thinks of developers more as “framework implementers,” reserving the title of engineer for tool-agnostic problem solvers.
This front-end empowerment is very real. Particularly in the last few years, front-end developers have gotten especially powerful. So powerful that Michael Scharnagl says he’s seen companies shift their hiring in that direction:
And Jay Freestone takes a stab at why:
I am a designer and I think I’m pretty good at HTML and CSS, but that’s not enough anymore to be a front-end developer.
Robin himself gave himself the job title, Adult Boy That Cares Too Much About Accessibility and CSS and Component Design but Doesn’t Care One Bit About GraphQL or Rails or Redux but I Feel Really Bad About Not Caring About This Other Stuff Though.
It feels like an alternate universe some days.
Two “front-end web developers” can be standing right next to each other and have little, if any, skill sets in common. That’s downright bizarre to me for a job title so specific and ubiquitous. I’m sure that’s already the case with a job title like designer, but front-end web developer is a niche within a niche already.
Jina Anne is a front-end developer and designer I admire. Yet, in a panel discussion I was on with her a few years ago, she admits she doesn’t think of herself with that title:
What I don’t understand is why it’s okay if you can “just write JS”, but somehow you’re not good enough if you “just write HTML and CSS”.
When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
Mandy uses her post for peacemaking. She’s telling us, yes, there is a divide, but no, neither side is any more valuable than the other.
Another source of frustration is when the great divide leads to poor craftsmanship. This is what I see as the cause of most of the jeering and poking that occurs across aisles. Brad Frost points to the term “full-stack developer” as a little misleading:
In my experience, “full-stack developers” always translates to “programmers who can do front-end code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
Heydon Pickering says something similar. When you’re hired at this mythical high level, something like HTML is unlikely to be a strong suit.
… one of the most glaring issues with making Full Stack Developers the gatekeepers of all-things-code is the pitiful quality of the HTML output. Most come from a computer science background, and document structure is simply not taught alongside control structure. It’s not their competency, but we still make it their job.
Just like it may not be my job to configure our deployment pipeline and handle our database scaling (I’d do a terrible job if that task fell to me), perhaps it’s best to leave the job of HTML and CSS to do those who do it well. Maybe it’s easier to say: Even if there is a divide, that doesn’t absolve any of us from doing a good job.
Just as architecture and developer ergonomics are all our jobs, we should view performance, accessibility, and user experience in our line of work. If we can’t do a good job with any particular part of it, make sure there’s someone else who can do that part. Nobody is allowed to do a bad job.
It’s worth mentioning that there are plenty of developers with skill sets that cross the divide and do so gracefully. I think of our own Sarah Drasner who is known as an incredible animator, SVG expert, and a core team member of Vue who also works at Microsoft on Azure. Full-stack, indeed.
I expand upon a lot of these topics in another recent conference talk I gave at WordCamp US:
Is there any solution to these problems of suffering craftsmanship and skill devaluation? Are the problems systemic and deeply rooted, or are they surface level and without severe consequence? Is the divide real, or a temporary rift? Is the friction settling down or heating up? Will the front-end developer skillset widen or narrow as the years pass? Let’s keep talking about this!
I have a lot of feelings about this topic but the most immediate feeling is art directed blog post
intense art directed blog feels intensify
My feelings too.
Very interesting article. As a newbie to this industry it actually made me feel a better about not knowing everything yet. For the past six months I have been looking into all kinds of stuff trying to figure out my path forward and what to really dig into long term and everything just seems like a can of worms. And every can of worms is filled with cans of worms :)
BTW this site looks amazing. This article would be a nice read regardless, but with the quotes and sections etc all looking so slick it makes it an even more enjoyable read.
Full Stack Developers are a thing, though. The industry just evolved so quickly the definitions of these positions haven’t been able to keep up. You can be full-stack in the sense you understand the programming logic throughout the entire application stack. You don’t necessarily need specialized knowledge in any particular domain of the stack, but you know enough to get it all connected and functioning. You usually will also have a inclination, you could be more backend or programming focused, or are stronger with traditional frontend skills like html and css. BUT you usually will always have a decent understanding of the full stack and what that implies and be able to connect and make a FULL application, but what is lacking is singular specialization and refinement in any one of the areas of the stack. With all the new libraries and frameworks that are out there full-stack development isn’t not sensible. Things like Vue and React make it so that you’re basically coding in the backend.
Holy crap, I needed this. Please chain-mail this to every Technical/Digital Recruiter EVER.
That’s a great read.
I know my way around ”advanced” JS, Node, React and all that stuff, but I always consider myself primarily on the other ”army”.
I recon it took me a long time to get on board of the JS train, I really hated the language at first. Then ajax techniques made us love it, and then jQuery (and mootols!) made it much easier to work with JS and build good things with it. And finally the modular SPAs frameworks / libraries came out and the JS side of thing exploded in popularity.
At the same time, lots of developers from backend languages started moving into the front-end, as did parts of the responsibilities. Also many devs came into front-end not from a ”web developer” background at all, but getting away from primarily ”desktop” languages. And that’s where accessibility went down the drain, and we started seeing ”CSS is crap” rants everywhere. I wonder how much of the trend for TypeScript has to do with turning JS into something more Java-like…)
Anyway, I’m lucky enough to understand both sides of the argument, but I really believe the industry is missing on one side. The job offerings (and salaries) for primarily JS based developers is over the roof, and that’s taking a toll on markup quality, while saying ”I’m primarily a CSS specialist” will probably get you no job at all (and some bullying while we’re at it)
And that’s leading new people to focus strongly into the JS side of things, and so does the courses and bootcamps. FreeCodeCamp gives an extremely awesome curriculum on JS, while barely touching CSS in a single chapter, from a ”applied visual design point of view” (that even confuses semantics and visuals in most of the lessons).
That makes it feel like a ”old school” vs ”new school” type of discussion, while it should really be reckoned as two different and very important specialisations.. I like to call it “JS engineer” for the JS specialist and “UI engineer” for the markup / a11y/ CSS one … but I’ve seen job offerings titled “UI engineer” that are 100% the JS-heavy profile. We need to agree on the titles.
Sadly the trend is fairly clear: JS will inevitably take over everything front-end. Really my only hope for the industry to recognise the importance of the other role lies in the accessibility issues. Maybe 2019 will be the a11y year, fuelled by fines and demands starting from the Beyonce issue las week, which will lead the industry to desperately seek someone to fix their crap. Exactly the opposite reason for a11y of what I’d like to see, but anyway….
I’m loving the new design a little more everyday, btw
Nope, that will never happen.
Because 1KB JS > 1KB Images > 1KB CSS > 1KB HTML
therefore highly optimized html/css only sites will always be faster than js-based sites.
It’s weird how this seems to be such a big issue with front-end development, but I don’t see it so much with other disciplines. You wouldn’t call a personal injury attorney for a real estate dispute. Even in the engineering fields, you wouldn’t hire a structural engineer to design a satellite. Is it the lack of specificity in the word “front-end”? Is it just because of the newness of the industry or lack of understand from outside of the industry?
Thanks, Chris. “If I could remember the names of these particles, I would have been a botanist” – – Enrico Fermi in a letter to Lederman.
Easy. Just bring back “Web Designer.” Then we can describe the dichotomy as “Web Designer” and “Web Developer.” Maybe not.
I would suggest, front-end designer, to distinguish from the graphic designer role.
‘but somehow you’re not good enough if you “just write HTML and CSS”.’
I blame Bootstrap for that. Bootstrap is “good enough” for people who don’t need or want to write HTML and CSS. (about 80% according to Pareto)
I guess, what I am trying to say is that an engineer is way more than knowing a specific language. Just like you never call a backend engineer a Java/c#/c++/etc engineer, there should be a better term for engineers that like the “backend” of the front-end. I personally like: Front-end engineers, UX engineers, and BE engineers.
Thanks! Great article!
I am the guy on the right side of the help wanted ad. Round glasses but less hair.
Division of labor on large projects has created the necessity for separate roles. But the dividing lines are in the wrong places.
In the marketing world, we are all in the business of developing, publishing and managing content – and not just for websites but for all targets.
The clearer and more manageable divisions are where we have traditional separations of concern between structure (html), styles (css) and logic (js). The toolchain you are using may or may not make that easy.
Slow clap Thank you!
Notable Twitter conversation:
The article is on point. There is just so much to learn now to be able to call myself a Front-end Developer. I’m more of a UI/UX Engineer.
This was great, as someone who learned and focused on HTML/CSS/JS and PhotoShop (as mentioned in the article) with the title “Front End Developer” — I found myself in a completely new world as I started looking for other development. One term I’ve seen more often that jives with a11y, HTML semantics, and overall good UX is the ‘UI Developer’ title. It’s much more fitting of what the ‘Front End Developer’ term used to mean.
I am a little teed off at the quotes suggesting that full stack developers can’t handle both good front and back end code, as well as design. That’s a very elitist way of thinking, paradoxically…
Often, the case is either not caring about design or (in my case) not having enough time to perfect it. Design takes time, testing, and input, from multiple people of different parts of the ecosystem. APIs, too.
We have these two types of people at the company I work for. I’m a “web designer” who… wait for it… designs things for the web. I use html/css/some js to design things. We also have a front-end developer who takes care of the “dev” side of the front end. We both work on the engineering team. It works very well, two years and running now.
TL;DR we need to bring back the ‘web designer’.
I personally am happy this has arisen. I am originally a “back end” developer thrown into front end because the designers there couldn’t handle the more complex logic a modern application needs. The divide let’s me be what I am: am engineer. I didn’t go to art school, I only know color theory as math, I’m unconcerned with aesthetics and prefer a terminal. And front end designers need me, that’s obvious as I can’t seem to escape front end development. That need is an indication we do indeed need two different disciplines defined on the front end:
Engineers, and designers. Like we uses to call them.
I don’t think this is quite right, though. I would say that I am more skilled/passionate on the HTML/CSS side of things, but that does not make me a Designer. I have no true design background or training. And I work with a designer who doesn’t know how to code at all.
My job title is Front End Engineer, but I always introduce myself as a Front End Developer, because even though I am pretty solid with React and spend a ton of time working on JS, I do not think I am an Engineer in terms of greater architectural understanding.
I think it is just a spectrum, and to a certain degree, most of us will be living somewhere in the middle.
This isn’t to diminish the UX side, to be clear. I’m details-obsessed, personally, and CSS is one of my favorite languages. I’m only speaking to the perception that outsiders (those generally calling the shots) may have.
Yep. Nailed it. It’s what I call “the backend has moved to the front end”.
The current job titles and recruiter knowledge of who does what is getting pretty bad too. It’s a jungle out there.
Hey speaking of front end, why does your comment email text field not have type=email? Boom.
The divide is monetary as well – good luck finding a $100k position as an expert of HTML and CSS.
These fundamental languages are being treated as entry-level knowledge, but like others have said, the quality of the code has suffered. I could tell CSS was becoming a “means to an end” the moment I learned it was a thing to write styles directly in React components.
Now I have to learn React just so my entire career doesn’t become limited, lol. I have a decade of experience to offer but none of it matters because I’m not an expert in these libraries that nobody needed 5 years ago. I don’t have anything against the libraries themselves – they’re super useful sometimes – but I don’t like how they let people effectively ignore 66% of what makes up the web.
By all means, it is important to separate out development so that peoples talents are not stretched too thin between what are syntactically very different coding conventions. But we also need to have much more respect for HTML and CSS, and start seeing them as important languages in their own right. We need to treat those who write it as developers, and instil the (already existing and readily available) principles in our projects. In short, we need to become less obsessed and focused purely on JS.
Sure, JS can solve many problems. But that doesn’t mean it’s the best or only solution for every problem. Sometimes JS is essential, but sometimes – if the document can be more meaningfully structured in the first place – by using JS we are simply sticking plasters over a gaping wound.
In such an instance, we should consider that maybe it was a good idea to invest more in the HTML/CSS side of things in the first place. But by then, it’s almost too late.
I’m much more on the HTML and CSS side of things myself, and I feel this great divide all too often. I see both sides as equally important, and from my perspective, having dabbled on both sides, being an expert/artist at HTML and CSS is infinitely more valuable than being a moderately proficient JS-framework-geared dev, BUT it shouldn’t stop there.
If you’re going to err on the HTML and CSS side of front-end dev, make sure you’re a master of your craft; expand your horizons a bit. If you love CSS, pick up SCSS. It’s not a necessity, but with it you’ll be able to do more and much more easily, and you’ll ultimately be more valuable, not to mention that it’ll make you much more relevant within the front-end “semantic” dev spectrum and community.
Moreover, in response to Keith point, there is a substantial monetary divide when it comes to types of front-end devs, due mainly to supply and demand, and justifiably so. HTML and CSS might be enough for some roles, but it’s simply not enough if you expect to be valued equally with your JS-heavy counterparts. Cross-train yourself. Become an exceptional designer in Photoshop and Illustrator, or become proficient in UI/UX design using Sketch/Adobe XD/InVision Studio/etc. Or more practically, become at least moderately skilled in PHP and basic jQuery. Those skills are both easy enough to pick up. Basic understanding of jQuery is typically expected in classical front-end roles, and PHP devs make far more than non-PHP devs, though PHP is bound to benefit you in many more ways than income and may even inspire you to continue learning other languages.
The Division Bell in the background.
Great read. Also as a newbie really motivated by all this actually. With so many different avenues it can be intimidating to keep plugging away at times.
Found this site just recently in my quest for developer status, have enjoyed the content!
Chris, thank you for putting this article together, it was a cathartic read. I’m fortunate in that the team I’m in values what I bring, that we all play to each others strengths, and that we’ve built some amazing stuff together, but that doesn’t stop me from wrestling internally with my own relevance and skill set. And though it doesn’t really bring me any closer to overcoming my own biases and mental roadblocks, it’s somewhat comforting to know I’m not alone.
Much like a back-end developer who writes code in PHP or Ruby and then also does bits with databases and servers. I’d class someone as a PHP developer if they only focus on PHP. I don’t understand where this so-called ‘identity crisis’ has come from.
It’s almost as if people decided one day they don’t like their job title and need to come up with something new and unique to make them sound different and interesting. Engineer, developer, programmer… it’s still just writing code. Can we settle on developer?
Great post. I think what mostly surprised me reading this is that a lot of people are feeling an ‘us and them’ divide.
This year I started my first full stack role; prior to that I had spent about 7 years working in various front-end roles. I’d like to think I’ve “earned my stripes” mastering foundational aspects of front-end. I know this wasn’t the intent but one particular quote in this article made me feel a bit singled out as a full stack developer, that I probably shouldn’t be touching CSS or similar because my output may be ‘pitiful’ in comparison to someone who works exclusively with such languages.
More importantly I don’t think “full-stack developer” should necessarily imply that a developer is equally adept at both frontend code and backend code. What’s to say someone might be a junior full stack developer? Are we not allowed full stack developers that aspire to learn both sides of the coin but are only at a competent level for now? It is evident though, especially from reading this that some full-stack developers have a bit of a ‘god complex’ issue and this is unfortunately why full stack is associated with being a ‘master of all’.
There’s no shame in admitting our limitations and gaps in knowledge. If you aspire to be full stack or are currently learning both, but perhaps haven’t brushed up on CSS in a few years, reach out to those that have for advice. Don’t play ignorance the situation and assume that what you can produce is ‘good enough’ – you’re giving the rest of us a bad name.
We’re shoe horning too many aspects of a very complex medium into one job title and it’s no wonder people are feeling the pressure; forced to adapt, accept defeat or unfortunately in some cases play ignorance to things they don’t full understand and ‘trundle along’ producing poor code.
I believe we need more job titles, but also a set that are universally identifiable across the industry. Or we risk people being coined ‘half-stack UX interaction designer’ …and nobody wants that.
I think a big part of the problem with front-end development is that most people consider everything that happens in the browser ‘front-end’, while this isn’t true.
Front-end and backend is not the same as clientside and serverside. Just because your code runs in the browser (clientside) doesn’t make it front-end code.
Where your code runs doesn’t make if front-end or backend, but what it does, does!
I love when a UX/Frontend developer hands me a ready to go layout, with images, spacing and hex/rgba values for colors.
I know that layout is not my strong suit (they turn out to be “just ok”) and I deeply appreciate having someone to handle that for me, because I know it will be miles better.
You don’t even have to write the HTML and CSS.
The layout alone already makes me look at you like a hero/heroine, so don’t take your job for granted.
I love you.
Thanks Chris for this great article and video. (And I love the new look for your CSS-Tricks site)
The web started with static web pages. At that time UI/UX design was much less dynamic (i.e. plan vanilla CSS1/2)… less animations and less interactivity on a single page/screen.
But now we’re seeing convergences here, like CSS variables and keyframe animations (somewhat of a declarative language for dynamic CSS), interactive with every element on the page…
So my point is that if someone is hiring you to create a modern (web) app/page, they want you to be able to be proficient in more skills than were needed by web developers in the early web days. Just like if you take your recent car to the garage to be fixed, you’d be pretty worried if they told you they only know all about fixing cars from 1970 and earlier… you expect them to know how to fix all aspects of your modern car (electronic/engine/computer chips) or bring in a specialist if needed.
I think employers/recruiters need to understand this problem the most…Employers need to give their employees time/tasks to build them up in to a well-rounded ‘developers’… And if you’re self-employed (or your employer doesn’t care), you have to try to build yourself up.
I’ve recently felt so overwhelmed by the divide in Front End Development. It all started a couple of years ago I went for a position as a UI Developer which expressed HTML/CSS/JS and TDD as the core skills. As soon as they put TDD on the job spec then I found this filtered down into the other larger organisations in the city. Next was Angular 2+ in the job spec, then it was React…I’m starting to think developers are just magpies, eyeing up the latest shiny thing.
To counter my own argument I made a small brochure site the other week and used Gatsby and WordPress. It took a lot longer develop but it get 95+ across the board in a lighthouse report and feels lightning fast to use.
This is a great article which gives a great overview of web development over 25 years and why things have moved on – https://hackernoon.com/modern-web-development-bf0b2ef0e22e
I really think the role is going to start to niche into areas of expertise but the core skills of laying out and building a page in HTML/CSS/JS will still be at the heart of it all.
This is such a beautiful post and it resonates so well to most of the other roles (titles?) in product teams.
For example, Ann Rockley said it for content strategists, at: https://contentmarketinginstitute.com/2016/02/types-content-strategist/ Likewise for UX designers. I will use this post as a reference in my team!
This article enshrines the struggle in my career. Heavy JS knowledge has always been elusive to me. I gained my skills and knowledge in the change to the semantic web and continue to hone those skills. However, I’ve always been a “hybrid” designer. I’m often shunned to dev by some design focused companies and then I’m not “techy or developer” enough for dev teams despite the developers saying they need my help with the front-end. It’s really tough some days.
Thank you so much for talking about this <3
Front-End Markup Developer
Responsible for HTML, markup, and semantics
Front-End UI Designer
CSS Proficiency with good design skills
Front-End UX Designer
Same as #2 but with UX skills
Front End React Developer
Proficiency in React and its sister libraries (like react-router e.g.)
Front End Vue Developer
Proficiency in making UIs with Vue
Front End Angular Developer
Proficiency in making UIs with Angular
Front-End Design Expert
CSS Proficiency with UI + UX skills
Full Stack Front-End Developer
As you can see, there are many niches in the term “Front-End Developer” which creates a lot of prejudice and confusion. I think that by splitting them up into more manageable roles related to the front-end, then it clears things up. The term “Front-End” developer should be reserved for the rare diamond who can fill all of these niches in one go.
Great snapshot of the current state of affairs in 2019 front-end web development, Chris. I continue to try to learn and excel in both domains (because I like them equally) but I feel like the center won’t hold much longer and wonder what the field will look like in a couple years. One thing we know, it won’t be boring. Keep up the great work in your articles and podcasts, we need wise voices to help us deal with this massive change with compassion and intelligence. Onward.
I think this illustrates a larger issue with business and these converging disciplines. It’s not just “front-end”, but also “full-stack” and even terms like “performance”.
I’ve seen the term “full-stack” used to describe a developer who also tests. I’ve also seen performance testing that is 100% focused on the back end (url or app stress testing) with zero concern for the client whatsoever.
There are probably a number of issues at play here, but it’s certainly concerning to see. It just underscores the importance of speaking up for the neglected (but necessary) elements before organizations learn the hard way.
Over my 25 years doing this stuff, we first had web designers, web developers, web masters. Then we started formalizing with back office vs designers. For a while we then had DBA, middleware, and designers. The customer (front) facing side of things has been mainly treated as a designer for a long, long, long time.
Skipping a few steps to the current status, UX/UI and front end designer are even separate roles. Front End Designer and Front End Engineer now divide us.
This is not helped at all with cheap clients trying to get us to overwork under the guise of “full stack”. Cool, so you know AAA level ADA compliance, databases, contemporary design, CORS, testing, D3, 3D, Jenkins and the box-model hack? Expect an exhaustive time-boxed code challenge to get paid barely enough that a specialist in one of the above disciplines will make.
“Front End” people have done the community at large no favors.
This really resonates.
I’ve been fortunate in that I’ve been able to take a fun hobby that I picked up in 1996, and turn it into a job. A career, even. But I’ve certainly noticed this divide forming. The things that made it fun and worth pursuing at first have been devalued in favor of a complete emphasis on skills that were once just one small part of it.
The only way to keep doing the job was to sap as much of the fun out of it as possible, until it basically became something else. The unstated part of this is that there’s virtually no career path when you need to keep constantly adding on new domain knowledge, skills and responsibilities, just to keep the job you already have.
I’ve been stuck in mismanaged, IT-focused organizations that could never possibly see the value in UX, CSS, accessibility, interactions, and the like. They become checkbox items that a “real developer” can take care of after they’re done programming. For them, CSS as a skill begins and ends with an understanding of the syntax. To organizations like this, it doesn’t matter if your website is the only point of contact with your users and customers — if it involves code, it’s just something the IT department can deal with.
I got tired of this mindset of code over empathy for the user, but I adapted. I picked up new skills that frankly I didn’t want just to stay employed, but mainly I knew I had to get out of it. The writing’s been on the wall for years now. I knew the only way out was to make the shift into management, but that’s not easy in a small organization with little room for growth. I put in 60 hour weeks, spoke up at meetings, and basically took initiative whenever possible to try to make the change. Mainly, though, I got lucky.
Even though I was running a highly functional small team, having completed many successful projects and achieved important outcomes, I knew things were about to turn toxic, and it would be time to go. Now, less than a year later, my entire team has left that organization or been laid off — more victims of the mindset that elevates writing code over empathy for the user.
I hate to be the pessimist but a FE dev who doesn’t have strong JS ( or coding ) skills ( data structures, algorithms, scalable architecture, etc ) is likely to become scarce in the coming years.
Tools such as Webflow, etc and better compliance from browsers have made the HTML/CSS focused FE dev less indispensable. Sure, Webflow is not perfect but in many, many cases it is good enough and it will get better.
Absolutely fantastic post. Love the custom art directed style.
I fall on the HTML/CSS side of things. However, I would challenge my fellow HTML/CSS side devs to invest the time in learning something like React. React w/ JSX honestly feels like the closest thing I have to SCSS for my markup w/ some simple logic that really speeds up my workflow.
For instance, a
Buttoncomponent that renders an
hrefis passed and a
buttontag otherwise. That
Buttonis essentially a markup mixin.
So much yes. I’ve increasingly felt this every day for the last ~5-10 years or so.
Good article but just leaving a comment to appreciate the design and sectioning of this blog.
I extremely loathe people who do this to others even myself.
I appreciate the time and effort in this article. One thing I’d like to stress more is the economical perspective. I think a lot of companies hope it will be cheaper to hire a full-stack dev instead of several people to fill multiple roles. It reminds me of the time when companies were on the hunt for “unicorns”, based on the same idea – saving money by hiring fewer people with broader skillsets.
Can’t help myself joke that the next popular job-title is going to be Unicorn Full-Stack Dev…
it’s true that most companies are looking for full-stack devs but writing “front-end dev” in their job descriptions. When I was looking for a job the last months or so, I rolled my eyes many times when I was asked “And can you work with [replace with any backend-/ js-framework here] as well?” – Of course I’m able to work with this frameworks, but at that time I didn’t want to! The job description clearly stated “front-end dev” and was all about templating for CMS or e-Commerce systems, so why the heck were they asking me that? As you said: simply to save money and get the perfect jack of all trades.
Unfortunately I’m afraid that this discussion will not end this practice. It’s totally understandable for companies to save money, but why do they have to take somebody for a ride with deceptive job descriptions while the person in question is looking for a new job? :)
So many of these quotes resonate loud and clear.
5-10 years ago i was a “unicorn” that could take research, design, do HTML/CSS, enough JS to be competent, and wrap things up in the CMS template language de jour. Today my team is myself and a CMS/SysAdmin, and I feel I’m constantly playing from the back foot. I spend a lot of time just trying to figure out what to worry about and what to leave behind. My email says “Front End Developer” but really I’m just a front end technology wrangler, that’s trying to keep a large(ish) site current and in the sweet spot for the resources we have. Lot’s of planning and road mapping take up a lot of my time.
I recently had the “node manager to install a node manager” type experience and decided then and there to enroll in a bicycle frame building class. I’m too old to be continuously chasing my tail. The steady inundation of new tools is just too complicated to be much fun anymore. The industry is evolves faster than it’s labels. Perhaps it’s time to shed those? Let’s go with “I’m a JS engineer” “I’m an HTML/SCSS dev.”
Also have some experience with php / WordPress development but I don’t care about JS framworks tbh. I’ve tried and it just doesn’t click.
I’m very much this “On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.”
It’s really good to read this sort of thing so I know I’m not alone!
As a print layout designer that moved to “web design” (which later I learnt that wasn’t a nice term anymore), I feel good about this post. Now, working as a front-end developer (hah!) at one of the biggest newspapers of Latin America makes me wonder how I’m seen by the industry. I’m graduated in journalism* and not in computer science (or similar).
But for the market:
I have to layout, design, structure and program every product that I touch, and now I’m learning back-end development (going against what you said about full-stack coming from programming to design. I’m going the other way around).
It’s really difficult to know what to put in my resume.
(that sounds weird, english isn’t my first language)
One of the captions mentioned, “Is the pay grade the same for these skill sets?” The rest of the article didn’t touch on this at all. I’m very curious to hear your thoughts on this matter in more detail.
For myself and my career direction, I was stuck right in the middle of this rift when I get let go from a position in early 2017. I was applying for FED positions where the description was what I thought I wanted. When I would get in to the interviews, or the tests, it was all about JS Frameworks, Node and other stuff that I truly have little desire to dig in to.
As I have seen this “divide” grow online and heard in podcasts, it caused me to think about who I am as a developer so I can truly talk to people about what I do and WHY I like it.
I was the kid, and I am the adult, who LOVES building Legos, but one of the things I like about Legos for me is following the instructions. I am creating something, but I didn’t need to design it. This told me I knew I like to create, but not always design. I very rarely take a bunch of legos and just build something random. I don’t have that wiring.
What I do love about the creating that I do though is the collaboration and problem solving. I like the task of working with a team of people who want to create the best thing we can for the problem at hand. We each have our skillsets, but we also know collaborating will create a better product than just putting a designer in a room.
On the JS side of things, I struggle. That’s just me being honest. I have worked hard to get to where I am currently. I know I have so much more to go and I have to actively push myself to get there because it doesn’t drive me very much. That being said, JS is, and has been getting, more important than it was 15 years ago when i was building table based layouts. So I know I need to dig in, get uncomfortable and find a way for me to learn, understand and grow.
I’m from Brazil and I worked in small companies (+ – 10 people in the development sector), here’s my experience:
I do, however, feel a great relief when there is an UX Designer that does the layout part. He lifts that burden from my back because I know I am not good at it. The layouts I do turn out to be “just ok”. That UX individual doesn’t need to write the HTML and CSS, for I am very comfortable writing it and I’m pretty good at it.
And you know that UX guy? He is also responsible for content creation for social media and sometimes even the ADs for them!
At least in small companies here in Brazil, those functions kinda blend into one job title because people really do all of it. Granted, they are not perfect in every aspect, but usually they are pretty good in one and ok in the others.
Great post Chris, you really covered the high points over the past few years. I’d also consider including a shoutout to Rachel Manning for her recent thoughts on the subject (and great graphics!): https://blog.prototypr.io/dissecting-front-end-job-titles-7f72a0ef0bc5
I offered a potential solution to the job title/job postings issue: https://twitter.com/withinsight/status/1086271812835729408
Could we just call the people who choose to major specifically in React, Vue, GraphQL, styled-components, nodejs, etc with minors in CSS/SCSS, HTML, Interaction Design, SVG, WP Theming, etc Front-End Developers? Then those who major in CSS/SCSS, HTML, Interaction Design, SVG, WP Theming, etc and minor in JS libraries, nodejs, etc Front-End Designers? Seems like that’ll do it and we can call it a day.
Wow, I think that was one of the best reads on this topic. As someone who shifted from Web Designer to Web Developer to UX Engineer to UI Developer to Senior Front-end Developer who’s studying Interaction Design, this article gave me so many feelings. I met brilliant Front-end developers who didn’t understand CSS basics such as specificity and I’m now at a point where I think that this is totally okay. What is NOT okay though, that the one who understands CSS specificity and can build a well maintainable UI architecture is considered to be a junior front-end developer. I guess we have to accept that ‘front-end’ is getting more and more complex which is not negative, but it means we can not keep on track with every topic very well which brings more specialised roles. I think a problem is that companies or CTO’s often don’t have enough understanding of the detail requirements of the actual job so they’re just looking for a front-end developer who can do it all. But cheap.
So much to say about this!
Well written but I think you are circling over the answer without going into it.
But it allows for much more.
If I had to pick a term, and I don’t mean it in a negative way even though some might find it to have a negative connotation, I would instead oppose “Front-End developer” to “Web Integrator”.
To me, a Front-End developer is exactly what is described in the CodePen job offer:
While a web integrator is more akin to:
“translate a Photoshop layout to a pixel perfect website.”
As for a FullStack developer, they just don’t exist.
Sounds like the complication stems from calling designers, developers.
Great point…I’ve taken to calling myself a front-end designer. I think it more fits my area of expertise.
Great article Chris! You’ve summed up in words what I’ve seen happening ever since I took a job coding non-responsive websites in plain HTML & CSS back in 2011.
Recently I’ve had to take up the job search for the first time in 8 years. I consider myself a CSS and HTML expert, yet I’ve come across so many job postings for “Front-End Developers” that don’t even mention HTML or CSS! They all want you to know React, or Angular, or Vue but don’t mention css formatting techniques, accessibility, semantic HTML, UX… It can be super frustrating.
I find even the term ‘web app’ a slightly odd and confused title, which is apt given the content of the article.
A ‘web app’ has not really got anything to do with being a ‘single-page’ app (which again is just a single-page website) – they are distinct things.
Very much feeling the identity crisis as “Frontend-developer”.
Recently had a depressing laugh when creating an Angel List profile, selecting skills from the prescribed list. Every language you could think of, including 3 JS frameworks but no CSS or HTML. Feels like unintentional gatekeeping.
I suspect that if HTML and CSS were available to select, absolutely everyone would select them, rendering (!) them pointless.
That’s not to say that they are pointless. Rather, it suggests a massive gap in perception of what it means to “know” them.
CSS, that’s when you use a style attribute instead of a tag for formatting, right? Cool, I know CSS. Except I don’t.
Do all really good CSS developers know SASS? Maybe that’s the answer. Listing SASS as a requirement would separate “real” CSS developers from those who just know what it is. (Except I don’t know if the premise is correct.)
I feel old just by reading this. Idk why, but I have the feeling that the HTML/CSS side is mostly coming from older generation of frontends. The ones started in the Zen Garden era like myself. And the other side are mostly the younger devs.
I feel old coz I also remember when Flash had this same division. On one side was the animators, and the other was the ActionScript developers.
It’s been years and I think it takes years to be honest. This industry is not easy to dominate, the goal post keeps moving. And now I can write severs, configure docker build processes and truly build full stack applications. I don’t know if I just took the worst possible path to this destination. I do know people seem to really like working with me, I also know I love UI/UX development, and working with designers is still one of my favorite things to do.
I even pushed for the removal of titles are my current employer and all developers wether back or front end are just Engineers. The entire time my drive to just do the best work I could do was what guided me. But even with over a decade of experience I still feel like I have so much to learn. It’s still exciting and I still want to create the most visually fluent and accessible master piece of my hearts desire. Maybe one day I will.
I dicovered Front end development (at least that what it was called) when CSS 3 came on stage to perform. That was good time, things like border radius, gradients and animation arrived to the spec.
Albeit this article is about Front end developers but did this shift affected backend developers as well?
The necessity of splitting the front end into three overlapping areas has been a fact for years.
The front end- engineers, developers and designers, focusing on js, markup/css, design/ux respectively, with a skillset focus on one of these areas and knowledge spillover into the others.
The complete set being a rare beast called a full stack front end developer. Never mind the mythological full stack developer, although they do exist, but tend to want to be left alone and work with one focus at a time.
Job descriptions including ‘full stack developer’ usually means the company is either looking for an underpaid miracle man or doesn’t know it’s own needs, which can be an opportunity… Or a nightmare.
Oh what a wonderful world we weave
As a former (!) full stack developer (like 10 years ago, when there was only web developer, no back end, front end, etc. roles) who transitioned into primarily front-end developer and struggle now to keep up with the almost annual onslaught of new JS libraries and frameworks, and facing again a career divergent path decision (to become a JS developer or settle as UI/UX dev) as the “great divide” becomes more evident, this article resonates deeply with what I also feel for some time. I’m so glad I’m not alone in this dilema.
I’ve been trying to put my finger on this divide for a while and this post summed it up pretty nicely.
I actually saw a job description not too long ago for a Front-End role that was seeking an ‘HTML & CSS expert’, which went on to describe the importance of having this role in their company in relation to maintaining document structure, naming conventions, BEM, code optimizing/debugging, UX, etc. I thought to myself “What a dream job!”.
Unfortunately, it does seem most companies prefer front-end devs with experience in Angular, React or Vue, and in turn, provide those candidates with higher pay grades.
Wow wow wow! Thank you so much Chris for this discussion. I’m really happy to have found it and read it. I felt a big release of frustration and anxiety coming out after reading this article. I have been always fond of Front-end development, but it’s becoming a huge struggle for me to find another job based on the title of just “Front-end developer”. I’ve been doing this work for over a decade, and I really considered myself a “professional”. It really decrades you when you go for the second job interview of a “Front-end developer”, and you are handed with a task containing stuff like “Web sockets” to connect with an “echo server”, fetch all this data, and render dynamic content while building the whole layout in the time span of a few hours. Not that I couldn’t do it, but I personally consider this more as “back-end” related work. I was so frustrated that I just closed my laptop and left the building. I think this article should be spread around, and I will do so when I release my article next week. Thank you!
I would agree that we need individuals who can do quality work in all areas to work together to build great websites — that we shouldn’t be building bad ones…but how?
In general, businesses are not incentivized to create great websites when a bad one will do – and by bad I don’t mean one that is poorly designed and executed but one that lacks accessibility, uses subpar HTML, duplicates and misuses CSS, and perhaps has security holes a mile wide.
I’ve listened to a decent number of DotNetRocks podcasts and they mention on a somewhat regular basis their belief that a professional credentialing organization similar to that found in other vocations is necessary for the software development industry. There is an episode with Uncle Bob from a few years back that looks at this in some detail and highlights the Obamacare’s healthcare.gov fiasco as a tremendous example of why software quality standards are needed.
I’m not sure if this sort of credentialing is the answer…and I’m completely self-taught, so I’m a bit resistant to the idea due to concerns about how this would impact hobbyists and those working on side projects…but my point is that businesses (without a cultural shift far beyond the web industry) will not (generally) spend the money to create a good/great product when a poor/okay project will provide acceptable profit margins.
(imho, in many cases there is significant ROI to be gained from investing in a better product – but a large percentage of companies don’t seem to recognize this potential…it is frequently a struggle to convince an organization that making x change will pay off)
I’ve been doing this since 2001 when we didn’t have CSS and JS was only used to validate forms. Not to create a false sense of seniority, I’m just saying: I’ve been through multiple changes of job titles and expectations.
2015-now: Front-end engineer, still, just with newer toys. But honestly, I’m seeing TypeScript coming up and its ROI is horrendous, except all the back-end developers bleeding into the front-end world (thanks Angular) are very uncomfortable not strong-typing their code. So TypeScript is making big waves, and I hate it.
Future: I’m hoping that with the use of React or Vue.js I can focus on strong user experience in a relatively dumb front-end. Let me write the user interface, the components, connect it to the browser, make it responsive, i18n it, add a11y on top, value semantics, work SEO.
And yes, that does mean that I’ll know how to write a FizzBuzz. JS array functions and ES6 additions and all that jazz: I don’t think anyone in this field can get away with not knowing any of that anymore. Staying up-to-date isn’t an option, it’s mandatory, and this field of work changes FAST.
Maybe the great divide is just a natural consequence of the fact quality skills require time and effort to acquire and there is no practical way to be great at everything. Let’s remember that great UI skills are useless unless they implement a great solution. This binary classification will surely become more fragmented when a new UI technology is developed to solve more complex real-life problems in the near future. For now, companies need both types of UI developers and must force them to talk to each other or risk creating sub-optimal solutions.
Really nice article!
I think one of the issues leading up to this is some people started to think of CSS and HTML as programming, which it strictly speaking is not.
So people who mainly did CSS and HTML were called “Front end developers”, which really was a misnomer.
Now i’m not trying to diminsh what they do, but I think it’s a slightly confused title if you mainly work in CSS and HTML.
I think maybe there should be some sort of “front end design/ux” role that is responsible for things like markup, css, a11y, ux etc.
So basicly I think that “front end developers” need to expand more towards the backend, and that “front end css/html” people should expand more towards the designers/ad/ux role.
All three roles (back end, front end, design/ux) need to widen their responsibilites/skillset to work with each other more effectively.
I’m sure many people disagree, but this is just my thinking. I’m not saying it’s the one and only truth.
We all work together to make a product, all these roles are needed.
I see a different divide:
side 1: people who excel/specialize in 1 aspect of (web) development and always work in a team: css / html / ux design / front end coding / back end coding / database design / dba / api programming / project management / defining requirements / system engineering / testing / training / support desk / dev ops.
side 2: people who do (almost) all stuff themselves and are not dependent of team members
The company structure and a person’s experience, determine if you’re in side 1 or 2.
Nice long article. Forgot to say about React/Angular/ect are used by the US gov agencies and some foreign states to do traffic analysis. The illusion that the marketing of those technologies will produce a continous improvement in software will vanish as soon as the new generation of technologists arrive. Computers are running almost at the same speeds as 10 years ago due to developers ill prepared. Think about it! don;t let the media buzz and old narratives cloud your future/
Wow. That was an amazing post.
I find myself in the “Full stack designer” niche. A slot I had to take after 8 years being enslaved to “make that .gif banner”, “we need a flyer”, “design this landing page”, “write that content”, “we need a lightbox on that gallery”, “we need a custom wordpress template”, “can u setup a joomla website?”…
So i find myself in having proficiency in “graphical tools” and coding (even advanced hybrid languages like twig and such).
My real love is and has always been everything coding HTML and CSS (with a spray of jQuery), and i humbly think I write clean, slim, beautiful, coherent and well commented code. When all around i see HORRIFIC code, specially coming from people/apps trying to destroy the need of a front end developers (Adobe Muse, Squarespace, Wix’s code makes my skin crawl in anguish).
But I’ve always associated the term “front end” to the “face” of a project, so i’m baffled whenever i see job postings for “front end devs” that should know react, or angular, or vue.. Why on earth should i know those? What have those to do with frontend…
I had a couple interviews with a big company in Amsterdam that were looking for a front end developer, everything was good, i got declined because in wasn’t skilled on “big data analysis”.. What has that to do with frontend?…
Asking whether someone knows JS, HTML or CSS is like asking whether a cook can use a knife, oven or a spatula. As long as recruiters want “just a webpage”, they can hire any front-end developer they want and they’ll get one. If they want anything past a “just a website” they better be more specific to what they want.
Hello, I’ve read the article so well.
During various interviews, I found out that each company interprets the part of frontend very differently. So I was thinking about this.
May I translate this article into Korean on my blog? It will be helpful to many Korean frontend engines, including me. I’ll make sure to add a reference.
I wrote a similar (But much shorter and less researched) blog post late last year.
I’m currently working on a small government website, with about 30 pages and 20 documents.
And it’s all running through Docker, Containers, Lagoon, custom made admin interfaces, custom distribution…
Honestly, this thing could be static HTML hosted on a smart fridge, but no… we need to add complexity to reduce complexity.
I work on a website that has over 150,000 pages. We have more than 1 million users and 3.5M pageviews a month. We have an 9 person team, including a supervisor and dedicated designer. Our site has to be both responsive and accessible.
We don’t have a CMS and we don’t really need one. Our pages are HTML/CSS with some PHP thrown in. For the most part, they load fast.
We use Foundation framework with SASS.
I have to tell you that the most painful part of developing this website was setting up the dev stack for the framework. Orignally it was SASS/HTML/Jquery. Then the next major release was Node, Bower, Mustache, Grunt. Now, within the same release there’s no more Bower, no hint of Mustache (what was the point of that anyway) and Gulp instead of Grunt.
I’m not saying there aren’t situations where you need all that, but I’m guessing there are a lot of sites out there using complex dev stacks that really don’t need to.
I’ve been playing with Intercooler.js for a project I’m working on and have been very pleased with how easy it is. It does cause you to think a little differently about how to write a web app, but once you get the hang of it is pretty straight forward.
I’ve noticed how complex the business apps we create at work when really all it is is a page with a bunch of forms on it yet many time we are not even using a form!
There is a lot to say and tlak about here. It’s great that amazing folks like Chris can be in places to compassionately share multiple sides of such topics.
I think of “front-end” like “sports player”. That’s it. Okay, well maybe more like “football player” (soccer or American, you pick). We can all imagine that a football quarterback has very different skills than a kicker.
If a sports team says “We need another football player”, that’s obviously not specific enough. If they say, “You must throw for touchdowns, kick field goals, and catch the ball like your hands are velcro AND do it in a wheelchair” well, then their recruiter or hiring manager has suffered a few too many concussions. (because if you’re in a wheelchair, you’ve already got way more skills than most people I know!)
I hope that player A won’t disrespect player B since they play different positions on the team. Otherwise we’re talking about a respect and/or maturity issue, not a tech or category issue. The same, in my opinion, goes for anybody that talks down to those who focus on HTML & CSS. Respect & maturity.
For jobs, they jsut need to be specific and honest. For job finders, if a job description is not clear and that ugly moment comes up during some interview, it’s a learning experience for you (and you can blame the company for not being clear, or for over-reaching), awkward as it is. That’s the harsh part that isn’t always avoidable.
I believe it would be all smooth if we started to use terms like Front-End Designer and Front-End Engineer. I personally define myself as the first, but usually don’t find jobs that fit, sadly.
The identity crisis stems from the realization that you might need to beef up either JS or your observational skills. Nothing is lost to you, on the contrary, you should now have direction on what to learn next.
Back End Developer – server-side languages like C#, Java, PHP, Database, Web Servers, APIS (here the connection), etc.
Now, does that make sense? :-) Let me know your thoughts!
I agree that there is a missing role there, but Middle Layer Developer is kinda too generic. Is he responsible for middlewares as well? Not just in the middle layer, but also in the backend?
You see, it starts getting confusing right off the bat.
Maybe frontend designer and frontend developer/engineer would be better.
Essentially you are connecting the backend to the frontend if you are in the middle layer.
Maybe something regarding implementation/systems binding. Bridge-end Developer. Connection-end Developer.
I don’t know, the name needs A LOT of work xD
Thank you for posting Jason re “it often feels impossible to keep up.” I was one of the first people online creating websites — in vanilla editors with cgi scripts and payments not hashed. I cannot believe how far we have come online since that time. Last week, I stopped working on learning React and wondered not if I should try to keep up, but if I can. I’m juggling too much to stay on top of everything and things I’ve learned haven’t been built upon but instead disappeared. I thought the world was full of people far more capable than I am and that it was finally time to just kick the can. It helps to know others feel the difficulty in keeping up. Thanks.
This is a fantastic, well thought out article. I’ve shared a similar sentiment for the last few years. So many great points!
This article sheds huge light on a problem I have only recently begun to (I think) undertand. As a former front end developer but now an accessibility consultant, I am constantly amazed at how many of my accessibility audits come back from the developers for rechecking with only half the defects fixed. Sometimes they come back for rechecks 3 times before all is correct! – even though I give very detailed solutions often including the exact markup they need to use.
At first I thought it was because developers simply did not did not have any interest in the accessibility – but these are often IT teams at major banks and other organisation who, I know, have a determined requirement for achieving full WCAG compliance for regulatory reasons. (And also bear in mind the client pays for every recheck.) To me, as a front end developer myself, the solutions generally seem absurdly simple (the markup needed for accessibility usually is) – so why don’t they get it? Sometimes a framework may not physically allow them to introduce extra bits of markup, but that is not the major problem.
The monetary divide is real and completely unfair. How can one language be the defining line for salary?
Julie. I can totally relate to this. Well said!
@Julie Perfectly, well-explained, real-world everyday experienced scenario. Bravo. You are better with HTML and CSS works and developers are better with their coding parts. You both need each other (mostly the developers need designers more) . Most of the developers do like this “they just brush over their coding parts and let the Web Designer clean up their mess later”. I am also a Web Developer and in starting I was doing like this. Then after seeing what problems Web Designers face, I realized mistake on my part. Then I tried to solve most CSS problems by myself or from online help (reading sources etc.) Now I am used to write perfect formatted code and I don’t like messed up code like some parts here and there.. (though it takes more time but I PREFER it.) In my opinion, both Web Developers and Web Designers should discuss ideas, problems, skills together to deliver perfect product at the end.
This was all started by Google with dart, go and angular. They have long wanted to control the web, move away from standards, away from html, css, js conventions and towards a compiled language experience that eventually will look nothing like html. Facebook got involved when google looked like they were going to dominate, possibly for good reasons, but with transpilers, babal, webpack, grunt, gulp they just accelerated us away from standards and towards the compiler (transpiler). The obvious critique of jquery sites (where html, css and js were nicely seperated, server side rendering was not needed, seo just worked, designers and developers worked side by side etc. ) was it created spaghetti code. But where this occurred, this was a function of bad tech leads or bad developers. Code layout using jquery could always be modularized, maintainable and self documenting. Now with react and redux/mobx etc you get file spaghetti, a massive global store of global data, complex state management, full dependency on js and a full compile (transpile) process. Its the google dream. Its a dangerous place. If you want to earn good $$ you are forced to embrace it but it makes system development more difficult not less. And I am talking about big systems (which is another fallacy – no front end is that big. No front end needs the complexity of react or angular). So google wins….
I think you summarised things pretty excellently there!
Great article and thread of ideas and comments.
Having come from a mainly design background into front-end development I know one of my greatest assets is speaking the language of design and development and understanding the concepts and limitations on both sides. Personally, I think splitting the world of ‘Front End’ into two distinct camps would benefit most, as the HTML/CSS experts could be required in more cases to also have a decent eye for design and some form of design training, and the functional front-end coders could focus more on their own expertise without needing to have their head in the design world so much.
IE it wouldn’t just benefit the developers who have less understanding of heavier JS coding and frameworks, it would also benefit the developers who really struggle to see designs and built sites the way a designer does and end up building sites with 10s or 100s of small design-related bugs.
Very interesting and relevant!
A few thoughts:
1. When people grumble about technology, my first thought is always: “When the printing press was invented – people who didn’t see its value grumbled. Is this the same thing?” If you learned Cobol early in your career and never learned another language, that’s cool, but don’t complain if your job prospects are limited and people adopt the next technology. Who’s skillset exempt from change? Resistance to adaptation works if you are an alligator or a cockroach, but it is seldom a good strategy for humans.
Humans are by nature creative problem solvers. Current communications technology, arguably a paradigm shift still in its infancy, presents us with capabilities that were unimaginable in the recent past (easy to forget). IMO, the JS revolution is the 2nd major, relatively universal development which provides us masses with tools to create content that takes advantage of those capabilities. Of course you don’t have to learn the new tools, but if you complain, consider that you might be a Luddite and see #1.
There’s plenty of poorly hand-coded HTML and CSS from the good ol’ days (I contributed my share), perhaps the majority of the code on the web fits this description. Quality comes down to the efforts and capabilities of the individual who is writing the code – no matter what tools they use.
Having worked for more than 20 years in front-end development, this rings very true. But I do not share the pessimistic views it seems implied by the byline “Two front-end developers are sitting at a bar. They have nothing to talk about”.
We’ve always bridged disciplines, since the start of this craft! We took design and matched it to code, document structures, semantic and a distributed medium. We enforced accessibility and decoupled structure from presentation, all while experimenting more and more with interactivity. We translated business needs and goals into good conversion rates thanks to web performance, responsive design, consistent and reusable UI implementations.
And we made this an industry.
If we can work alongside designers, I don’t see why we can’t alongside front-end engineers.
We have so much to talk the bar will be closing with us inside…
I am so happy you wrote this article. I began digging into learning React and higher levels of JS when WP and even Drupal began talking blocks. I started working on in html when the very first sites went online and the world online was a wild west unsettled frontier. Despite years of experience, I have been growing in feeling that I am falling behind, cannot keep up with all I need to master and getting somewhat jaded about my skills. I actually enjoy digging more deeply into JS and learning React but dang it, trying to be good at everything is a challenge. But even worse is this nagging feeling that all of the effort I have expended over the years has resulted in my skills being second-class …is jarring. I am so busy that I have not discussed this with anyone but have felt my insecurity growing as JS dependence had grown. Seeing this article and reading the responses got my body off my bed at 4am! I am not alone. I did not know. Thank you so much for giving light to this … now where do we go from here?
People who know html, css and jquery we call layout designers. They are beginners who didn’t learn js yet. And if you’ve been in the industry for 20 years, and haven’t do it, I have bad news for you – either you are incompetent, or you are tired of your work, and you should try yourself somewhere else.
Actually, I couldn’t disagree more.
I think everyone starts with HTML and CSS, and that person choose one of two paths.
Both of them have a very strong claim for their titles.
You can’t have a good site/app without knowing your target audience and making it a good experience for them, the same way that you can’t have a good site/app if it fails, is slow or has unexpected behavior.
By the way, why so grumpy?
(Editor note: I deleted the comment this replied to because it wasn’t just grumpy, it was angry and rude.)
I’m curious where this divide actually sits within JS. Most FEDs I assume can use at least basic JS events and DOM manipulation along with some understanding of data structures such as arrays and hash maps. But what exactly is the divide?
How about this as a preliminary proposal?
— divide right here —
Partials & Curry
I see a lot of new FEDs using the latest and greatest APIs to create intelligent chats, image recognition, etc but evidently this article provides a more somber assessment of the state of FED.
For ordinary websites, there is no user need satisfied by client-side rendering. You’d need to be working on a game or something to justify it, but not an ordinary website.
I also think accessibility is awesome. There is a trinity of guidelines for accessibility; web content (WCAG), web user agents (UAAG) and web authoring tools (ATAG).
My dilemma is if you use client-side rendering, are you still only concerned with WCAG, or are you now also under the jurisdiction of UAAG?
UAAG states “A user agent is any software that retrieves, renders and facilitates end-user interaction with web content”. So if your website is rendered client-side, it’s also a user agent, but one that can never meet UAAG. You have needlessly scripted your own embedded inaccessible user agent into the browser.
Someone informed me about this article after reading the one I wrote. This has been a problem that I’ve been watching grow for over 5 years…
The “Backendification” of Frontend Development:
Please understand, I’m probably the closest thing to there is to the Mythical Fullstack Developer (with a Business background to-boot). I was cheering for Angular and React before they were cool. But what seemed great in concept fell apart during implementation.
I’ve accurately predicted the future before and my current sense is to go all-in on Vue. Read my article to find out why.
Great article, something that’s been bothering me for the last 5 years.
I have a practical question for anyone reading this. How would a front-end developer, that’s doing more of the ‘design’ side of things, look for a job? What titles / subjects / words should one look for?
This split is evident in the Front End focused newsletters.
Managing Image Breakpoints with Angular
Animation in React
Working with the React Context API
“Frontend Focus” is more balanced. (https://frontendweekly.co/)
Exploring a Back/Forward Cache for Chrome
When is a Button not a Button?
What Should Developers Consider When Planning a React Application?
The Dark Side of the Grid
“CSS Tricks Newsletter” is actual journalism, not just an index, and is the best of the bunch IMHO. (https://css-tricks.com/newsletters/)
how to use CSS Grid the right way
a few services that allow you to do cross browser testing
Social Cards as a Service
Writing Animations That Bring Your Site to Life
I really needed to read something like this coming from an expert.
I’m an informatics college student and have a technical degree on programming. As a student I learned concepts about databases, object oriented programming, data structures and so on.
When I decided to get serious about specializing on frontend development (I already had some css/html knowledge), I started learning angularjs and got excited to use it in some real-world project. But when I got my first job, my responsibilities as a frontend developer were almost exclusively related to making pixel-perfect websites with just a bit of jquery involved. I never got (and still haven’t got) the chance to use MVC frontend frameworks, since they were not needed. I guess they are only required for really large projects.
Brad Frost has already coined a nice word for this .. semantic issue. I’ve been using it ever since: Frontend Design
I’m curious; is “web designer” not a good enough term for those designing web these days? To me, “developer” is synonymous with “programmer”.
Thanks for writing this article. The pain is real.
To be honest though, I’m so turned off by the dependency hell that is JS development, that I’m done and moving on.
Sorry to hear these kinds of things. I watched Bruce Lawson’s, Accessibility – Back to the Future talk (https://youtu.be/T2CjuAwrAq8) where he asserts, quite compellingly, that our JS-heavy toolsets are costing users dearly and doing them a disservice. Which is just not on!!
I don’t use these kinds of JS-based things, I could, I’ve even written full-stack JS desktop applications before, but right now I’m on a massive platform built using Scala+Play+Twirl, there’s little scope for JS in the browser given Progressive-Enhancement is mandatory for this huge customer.
What’s worrying is the idea that all Web Developers are or should be JS Developers. I don’t like the lack of distinction, so after watching Bruce’s great talk, I think I’ll market myself as a Worldwide Web Developer just so people know there’s a difference between something that’s made ‘of the web‘, and not just some JS-dependent application that happens to be ‘on the web‘.
TIL I’m a Unicorn-Among-Unicorns—not only am I competent full-stack, I started in HTML/CSS. I don’t say that to brag more to say that I’m a little surprised that it’s so rare as to be thought impossible. There are certainly days when I feel the depth of either skillset outpaces my ability to keep up (accessibility notably does not come as naturally as I’d hoped by now) but in general I have everything I need to slice your PSD, park a pixel on a dime and then spin the rest of the site around the pixel without mussing up its margins and then build you an API to control the spinning. But, I got here through growth over a career that started as a hobby in 1999. It feels like far more a daunting thing to do now with all the complexity but I still don’t consider the two mutually exclusive.