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 one side, an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript.
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:
I think we need to move away from the term myself. We should split into UX Engineers and JavaScript Engineers. They are different mindsets. Most people are not amazing at both JavaScript and CSS. Let UX Engineers work closely with UX/Design to create great designs, interactions, prototypes, etc. and let JavaScript Engineers handle all the data parts.
So sick of being great at CSS but being forced into JavaScript. I’m not a programmer!
This schism isn’t happening under our feet. We’re asking for it.
I heard it called an identity crisis for the first time in Vernon Joyce’s article, “Is front-end development having an identity crisis?” He points to the major JavaScript frameworks:
Frameworks like Angular or libraries like React require developers to have a much deeper understanding of programming concepts; concepts that might have historically been associated only with the back end. MVC, functional programming, higher-order functions, hoisting… hard concepts to grasp if your background is in HTML, CSS, and basic interactive JavaScript.
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.
To put a point on this divide a bit more, consider this article by Trey Huffine, “A Recap of Frontend Development in 2018.” It’s very well done! It points to big moments this year, shows interesting data, and makes predictions about what we might see next year. But it’s entirely based around the JavaScript ecosystem. HTML is only mentioned in the context of JavaScript-powered static site generators and CSS is only mentioned in the context of CSS-in-JS. It’s front-end development, but perhaps one half of it: the JavaScript half. If you read that summary and don’t connect with much in there, then my advice would be:
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:
So big:
- It’s everywhere on the front end of websites. The major JavaScript front-end frameworks are seeing explosive growth and dominating job postings. These frameworks are used by loads of teams to power loads of websites. Native JavaScript is evolving quickly as well, which has lots of people excited.
- It powers backends, too. Your site might be powered by or involve a Node.js server. Your build process is likely to be powered by JavaScript.
- Third-party JavaScript powers so many front-end features, from a site’s ad network and analytics to full-blown features like reviews, comments, and related content.
- Concepts like Node-powered cloud functions, storage, and authentication, combined with low-cost and low-effort scalable hosting, have empowered the crap out of JavaScript-focused front-end developers. They can use their skills exclusively to ship entire functional products.
A front-end developer with a strong JavaScript skill set is wildly empowered these days. I’ve been calling it the all-powerful front-end developer, and I did a whole talk on it:
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:
What I am seeing is that many developers focus entirely on JavaScript nowadays and I see companies where they replace back-end developers with JavaScript developers.
What some don’t understand is that a JavaScript developer is not per se a front-end developer. A JavaScript developer may not like to write CSS or care about semantics. That’s the same way I prefer not to work directly with databases or configure a server. That’s okay. What is not okay is if you don’t want to use something and at the same time tell others what they do is easy or useless. Even worse is if you try to tell experts in their field that they are doing it all wrong and that they should do it your way.
And Jay Freestone takes a stab at why:
Over the last few years, we’ve started to see a significant shift in the role of the front-end developer. As applications have become increasingly JavaScript-heavy there has been a necessity for front-end engineers to understand and practice architectural principles that were traditionally in the domain of back-end developers, such as API design and data modeling.
It’s happened even with my own small scale work. We were looking for a back-end Go developer to help evolve our web services at CodePen. When we didn’t have a lot of luck finding the perfect person, we decided to go another direction. We saw that our stack was evolving into something that’s extremely welcoming to JavaScript-focused front-end developers to the point where we could easily put more of them to work right away. So that’s what we did.
There may be a cyclical nature to some of this as well. We’re seeing coding schools absolutely explode and produce fairly talented developers in less than a year. These code school graduates are filling labor gaps, but more importantly, as Brad Westfall tells me, starting to lead industry discussions rather than be passive followers of them. And make no mistake: these schools are producing developers on the JavaScript side of the divide. Every single code school web development curriculum I’ve ever seen treats HTML/CSS/UI/UX/A11Y topics as early fundamentals that students breeze through or they are sprinkled in as asides while JavaScript dominates the later curriculum. Can you come in and teach our students all the layout concepts in three hours?
When JavaScript dominates the conversations around the front end, it leads to some developers feeling inadequate. In a comment on Robin Rendle’s “Front-end development is not a problem to be solved,” Nils writes:
Maybe the term front-end developer needs some rethinking. When I started working, front-end was mostly HTML, CSS, and some JavaScript. A good front-end developer needed to be able to translate a Photoshop layout to a pixel perfect website. Front end today is much much more. If you want to learn front-end development, people seem to start learning git, npm, angular, react, vue and all of this is called front-end development.
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’s also frustrating to people in other ways. Remember Lara Schenck’s story of going in for a job interview? She met 90% of the listed qualifications, only to have the interview involve JavaScript algorithms. She ultimately didn’t get the job because of that. Not everybody needs to get every job they interview for, but the issue here is that front-end developer isn’t communicating what it needs to as an effective job title.
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:
When I was at Apple, my job title when I first started out there was front-end developer. Would I call myself that now? No, because it’s become such a different thing. Like, I learned HTML/CSS, I never learned JavaScript but I knew enough to work around it. Now—we’re talking about job titles—when I hear “front-end developer,” I’m going to assume you know a lot more than me.
It seems like, at the time, that lack of a JavaScript focus made Jina feel like she’s less skilled than someone who has the official title of front-end developer. I think people would be lucky to have the skills that Jina has in her left pinky finger, but hey that’s me. Speaking to Jina recently, she says she still avoids the title specifically because it leads to incorrect assumptions about her skill set.
Mandy Michael put a point on this better than anyone in her article, “Is there any value in people who cannot write JavaScript?”:
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!
Even as JavaScript continues heating up, Rachel Andrew tells me it used to be hard to fill a CSS workshop, but these days conference organizers are asking for them as they are in hot demand. One thing is certain, like ol’ Heraclitus likes to say, the only constant is change.
✌️
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
100% agreed
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 :)
Trying to be a “full stack” developer seemed like a sensible aspiration a few months ago, but now I can see this is not really a thing, at least not for me and not for the next few years at least. I am going to try to focus on being the javascript orientated frontend developer who also really tries his best at design and css, but who defers to those who know what they’re doing.
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”.
Maybe it’s got more to do with my formation, as I’ve been working for 10+ years and back then everything was about good semantics and outstanding CSS skills. Javascript, in the very old days, was little more than something to annoy the user with popups and flashy thingies.
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.
I agree with Markus here. My hope is for the industry to realise that it is as absurd for a web page to contain JavaScript to render its content is as it would be for a Word macro to produce the rest of a Word document. It’s a bit hypocritical to react to the Word example with “Ugh, why would anyone do THAT?” but the Web example with “Meh, it’s 2019, get with the times.”
I enjoy writing JavaScript, and it’s critical for things like form field validation to reduce server load, for example, but I’ve seen many client-side platforms rise and decline, e.g. Flash, jQuery, Bootstrap, Angular… and I’m not convinced React or Vue are any different. If something has no future, then there’s no point in it having any presence. Sounds harsh I know, but that is the Web. I mean, I wouldn’t partner anything I create to a product with no future, that’s just not a good investment.
A JavaScript-dependent solution is suitable for writing a game or desktop-like application, but that would mean you have something that’s ON the web, but not actually a part OF the web. Users don’t need a pseudo web rendering engine to enjoy content. There’s so much sales hype and marketing nonsense pushing these new frameworks that it reminds me of The Emperor’s New Clothes, a lot.
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)
Love this article! Agree 100% on the css/html/UX aspect of the article. the one thing I would change is calling someone a JavaScript developer.
Let me explain my thoughts… Yes, of course is super important to differentiate between a UX developers and the JS engineer. However, I would encourage to not encapsulate the people that are passionate about code/frameworks/etc as JavaScript engineers. Yes, we need to be experienced about JavaScript, buuut FE is way more that simply JS. It’s about knowing patterns, OO, functional programming, architecture, module bunders, etc. As an example, Typescript is disrupting the market (regardless of how you can feel about it). Most importantly, Wasm (https://www.youtube.com/watch?v=DKHuEkmsx3M) is doing great progress to the point that we will not need to strictly know JavaScript, and browsers will be able to read byte code.
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:
https://twitter.com/cssgrogneugneu/status/1087442576842678273
https://twitter.com/ryanflorence/status/1087473420412112902
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.
My best guess as to the asymmetry is that one is better able to satisfy bullet-points. A JavaScript developer can “make it do the things”, an HTML/CSS expert can make it do things well. But when a business person comes up with the project requirements, the items in that list translate more directly to what the JavaScript developer does. The details, all the embellishments and things that make it more accessible and more coherent are “soft” features that are harder to quantify and therefore tend to get treated as auxiliary. Some non-technical managers may not even realize they’re something that needs doing.
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.
I absolutely agree that CSS and HTML is underappreciated, and the code is suffering as a result. As someone who learned web development coming from a design position, and through HTML and CSS, I can immediately tell when a back-end developer or JavaScript developer has written the stylesheet. It’s terrible, and people don’t seem to care. People think that CSS and HTML just don’t matter, they don’t need optimising or maintainability.
I see it on Stack Overflow too; simple CSS solutions for problems are often ignored, whilst people will readily recommend pulling in jQuery to solve a layout issue. Using JavaScript to fix a layout issue should be an absolute last resort, and pulling in an entire library to solve an issue that can be resolved with CSS or a better HTML structure is utterly absurd!
Worse, developers who understand programming dismiss it because JavaScript is more ‘lucrative’, leaving the CSS and HTML to be written purely by non-programmers, inevitably resulting in less maintainable code, and less focus on code principles, reusability, optimisation and other important tenants of programming.
It’s easy to write off CSS and HTML as ‘not a real language’, and it seems too many people treat it as such. This means that so little focus is given to properly laying out the document, and the markup suffers as a result. Websites become clunky and over-reliant on JavaScript – dependent even – and the responsive side of some websites is an absolute nightmare. Maintainability is utterly devoid at times, and adding additional content into layouts can completely break them as the layout was not properly structured to be able to adapt and respond to its context.
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.
As far as I can tell, the difference between HTML/CSS and JavaScript is that it’s easier to learn HTML. It means that there’s a lot more HTML/CSS developers than JavaScript developers. This pushes the price phenomenally low. You end up with https://www.psd2html.com/ . I’ve already been rejected from one frontend/UX job because I produced something with nicely crafted HTML/CSS when all they cared about was the JavaScript. I’m not going to ever try and sell myself as an HTML/CSS developer again no matter how much I care about them.
This is pretty much my life the last 3 years. I’ve had to leave behind the majority of what I actually enjoyed doing in order to hold the job that I got, which was completely different than what I thought I was applying for. Considering that I moved cross country for it, I didn’t want to abandon a solid Amazon position to hope for something more enjoyable, especially given the feedback I got when looking around for non-javascript-framework work…
The Division Bell in the background.
Hello. I am a Designer & Mathematician. In course of a day, I may switch from visual prototyping to coding or vice versa. Javascript lets me build very custom experiences thru functions and continuity of the space. I find CSS a great compliment and sort of a ruler to manage the discrete existance and relations on the page. I believe the division is not about the tools but the two types of people: Digital Designers who doesn’t know the code/context, and Engineers who doesnt know the design language. The first crew, often, in fear of complex coding, seeks refuge and safety in basic tools with an excuse of keeping things simple. Simple is great, but arriving at simplicity thru a tool or process that has the power to create complex beauty is the real art. The second crew, just doesn’t get it. They are often engineer types who have much less exposure and practice in design thinking. I personally gave up on collaborating with an alpha-coder on UX or Visual aestatics or execution styles. By the way the same frustration exists in other fields, for example Architects vs Structure Engineers. Many engineers, just because they have the skills to execute things, are delivering the crap we all see live in. The nature of free markets and current economical ecosystem makes it hard for the real thinkers and doers to reverse the power dynamics. When there is a demand for production and to produce more things, the crew who has the prominent skills in executing fast and scalable products, becomes the front runner. The system cares less about the best way to do it, or who is doing it right, because there are no reward attached to practice of such values. Ending on an optimistic note, I imagine in near future, with a lot of disruptions in classic education, we will have a generation of talents who are less biased towards their degrees or titles and have spectrum of skills and interests in building things that matters. I never really understood why designers should generally hate coding & math or why engineers are so proudly monochromatic. They are all the same kids in playground. The fear and division bell is conditioned in education, workplace, job-titles, job-postings, etc.
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.
I don’t see an issue or any actual divide apart from the odd Tweets here and there. It’s pretty much a non-issue in my opinion. To me, a front-end developer has always been someone who writes HTML, CSS and JavaScript.
A JavaScript developer is someone who solely focuses on the JavaScript aspect of things. You couldn’t have a CSS developer because you need HTML to go with your CSS otherwise it does nothing. JavaScript nowadays has become an entirely independent language in and of itself.
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.
Preach!
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.
Simply put: front-end handles how it looks and feels and how you can interact with it, backend handles the business logic of your application. These are 2 completely different things which require very different set of skills. Just because we have a language (javascript) that can handle both backend and front-end tasks, doesn’t make everything you make with it automatically front-end.
If you write all the business logic of your application in javascript that runs in the browser, you don’t need a front-end developer, you need a backend developer.
Where your code runs doesn’t make if front-end or backend, but what it does, does!
The one side of this ‘great divide’ whose interest and skill sets heavily revolve around javascript aren’t front-end developers. They are backend developers who choose javascript as their main language. Just like some backend developers use PHP or Go.
Holy moly batman! JavaScript and myself have never been friends. Sure I can look at it, figure out what’s going on and use a bit and some jQuery to make browsers do swish things but I am in no way a programmer. Never have been. I have tried, and tried, and tried to learn programming and JavaScript and become a ‘proper’ front-end developer, but I feel you have just showed me the light! I am a front-end developer, just the type who excels with HTML and CSS, who likes design and UX, who likes to make animations and digital content! Just not programming! Next, just need to have the confidence to own it! Thank you for this!
From a guy that does all of it (design to JavaScript), let me tell you:
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…
Also with dynamic layouts/mobile-first – take for example new CSS Grids and Flex box… it’s not just the layout… it’s also dynamically filling in the grid in a network-and-page-rendering-performant way. This is where you need to know BOTH JavaScript and HTML/CSS and probably some understanding of server-side technologies (e.g. fetching sections of big data in separate requests as the user scrolls down).
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
For context, I’m a beginner currently learning JavaScript development and trying my best to learn proper markup & design as well. From this article, what should mean is that I’m the guy that focuses on the SPA libraries and pre-set UI design through additional libraries (Material-UI e.g.), but also focusing on writing semantic markup, SEO, and CSS (all of which I sincerely enjoy!)
I honestly feel bad that developers on the markup and design side get discriminated against because they “aren’t JavaScript-oriented”. JavaScript, from what I’ve written in it and read online, is already a very arcane language and a lot of developers don’t even touch it for that reason. To see the front-end side split up is quite sad for me especially when things like JavaScript have made progress. Instead, I believe that the Front-End should be split up into a bunch of seperate roles that I’ll describe below.
It seems to make more sense now to split the titles different. Instead of having “Front-End Developer” refer to only JavaScript (mostly), I imagine something like this:
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 JavaScript Developer
Developer with proficiency in modern JavaScript, React, Vue, and Angular
Front-End Design Expert
CSS Proficiency with UI + UX skills
Full Stack Front-End Developer
HTML, CSS, JavaScript proficiency. Can write semantic markup, use CSS Grid & Flexbox properly and efficienty, and can write SPAs in React, Vue, and Angular. Has basic knowledge of GraphQL and writing APIs. Has familiarity with NodeJS.
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.
Middleware, remember that term? When you say server-side JavaScript (rofl) you have gone away from the display layer/gui/ui and you have no longer the “front” end. The front is where the rubber meets the road.
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 has been a common discussion around our workplace. We have proposed that those with the “traditional” HTML and CSS skill set be given the title of “UI/UX Developer” while allowing the “Front-End Developer” title to be used for Javascript heavy positions, per new industry trends.
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.
For a brief time, I had a boss who did understand empathy for the users, and see the value in these things. When that very rare opening appeared, I was able to go for it. And it was good for a while. I had the best team anyone could ask for. But eventually that boss retired, and things took a turn. They put an IT guy in charge — the kind of guy who thinks there’s no problem you can’t solve with javascript and python.
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 am an instructor in a short duration web development program focused on the front-end side of things. I would not call us a Bootcamp school as the program is run at a publicly funded post-secondary institution, but our competition certainly are the various Bootcamp schools nearby. We try to structure our program so that HTML/CSS and design are considered as equals to JavaScript.
You nailed it when you said that many Bootcamp schools focus almost entirely on JavaScript with only a day or two on HTML and CSS. This is so true and very sad.
We as course designers constantly feel the pressure from prospective students, employers of our graduates, graduates and even from ourselves to add more and more JavaScript.
Students always ask, ‘are we going to learn this framework or that framework’, they never ask ‘are we going to learn semantic HTML’. I used to feel like we should just cave to pressure and just add more and more JavaScript and maybe shrink the HTML and CSS portion of our program, but it never felt right to do that.
For the past couple of years, I have worried that it has just become a JavaScript framework world where JavaScript is viewed as the solution to everything on the web. People write HTML in JavaScript and now they write CSS in JavaScript. Why bother with CSS…CSS is stupid…JS all day, all the time…Not my words, but that is how it has felt these past couple of years.
We need HTML, we need CSS and yes, we need JavaScript. We as educators have a duty to produce graduates that understand the importance of well coded semantic and accessible HTML and that they understand the full power and beauty of CSS. JavaScript has its place, but not every document on the web needs to be produced with JavaScript. There is a beauty in the simplicity of a pure document written in HTML and CSS.
Thank you, Chris, for writing this article. CSS-Tricks is an influential site in our field, and I am sure this post will be shared and read by many in our field. This gives me comfort, as I hope we may have turned a corner here and hopefully we can get back to a bit of a balance in web development where JavaScript has its place, but that skills in HTML, CSS, Accessibility, UX, design, and Information Architecture are viewed as equally valuable to creating a usable, accessible and visually appealing web application or website.
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 anatag ifhrefis passed and abuttontag otherwise. ThatButtonis essentially a markup mixin.So much yes. I’ve increasingly felt this every day for the last ~5-10 years or so.
good article it ensure what i already know … any front-end developer working this days and keeping himself up to date with the new technologies in this field already know all of that or at least most of it… javascript is controlling and dominating on web development not just for the web but we already see frameworks based on javascript for creating desktop and mobile apps.
as a front-end web developer you must to be comfy with the core of 3 html, css, javascript but your really have to know php, sql, nodejs, mongoDB and graphQL OF COURSE NOT front-end developer is the ring in the chain who’s connect user with server (real user data / website data) who decide all possible interactivity scenarios user can make and in return what the visual result gonna be (not what’s the data gonna receive but the look of that data and how gonna show up to the user) away from any data ‘get’ or ‘post’ to the server or any validation required.
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…
Hey Frida,
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? :)
Thanks Chris!
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.”
This is incredible to read. I identify as a designer with very strong HTML/CSS and can muddle through some Javascript. I can read it / modify it but can’t write it from scratch.
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.”
So when I see jobs for Front-end developer it usually has loads of Javascript in the description and it doesn’t sit well with me. I’m question what I am, and have imposture syndrome because I feel like I should know a lot more.
It’s really good to read this sort of thing so I know I’m not alone!
Great article Chris, indeed one of your bests. Because it describes a feeling that more and more “old” front-end developers share : there is indeed some sort of divide. JavaScript seems to be the way to go nowadays, but I know plenty JS developers who are in fact unable to write some good css. They are stuck to frameworks, write non-semantic code, are not able to maintain graphical coherence in applications. Most employers are not aware of that because of their lack of understanding the front end field. The honor front-end JavaScript developers because they have functional solutions that brings money, the “old” front-end developer, or web designer often feels like a second role.
I know a lot of JavaScript now because I work for a big project involving it, with lots of data and Angular. But I still prefer designing things. I wish I could be a better front-end developer on this side : deeper understanding and mastering of CSS, SVG, animations… That’s not what most employers are seeking badly.
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’m not a journalist (even though my degree says it). I’m not a designer (even though I worked designing newspapers and magazines for years). I’m not a ‘html and css’ person (even though I made a lot of stuff without a pinch of javascript). I’m not a programmer (even though I mainly write javascript nowadays).
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:
In my case, I do everything. From wireframing, to layout, a bit of UX and then the actual HTML, CSS, JavaScript and Vue implementation (currently learning React, Redux and React Native).
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.
While I agree with the article, the terms we ended up using are “Front-End Designer”, and “Javascript Engineer”.
The problem is the mass influx of JavaScript developers who are given the title front-end. Someone needs a new title. Maybe JS guys should be called JavaScript developers? Or should HTML/CSS guys be called UI Developers
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.
First, comparing a title like “Front-End developer” to “JavaScript developer” is part of the misunderstanding. You are comparing a goal/domain to a language. JavaScript is just a tool in order to achieve dynamic websites, for example.
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:
“You’ve worked on medium to large web applications written in JavaScript. You embrace unit testing. You’re HTML, CSS, and design competent.”
While a web integrator is more akin to:
“translate a Photoshop layout to a pixel perfect website.”
This is also partly because a website nowadays is most of the time a web application, so it requires a programming language and not “just” HTML/CSS (again this is not negative). I think most JavaScript developers would gain a ton by getting good at HTML/CSS and the same goes for Web Integrators.
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.
As someone who mostly has worked on sites for non-profits and small businesses, there’s never been a need for me to learn any of these javascript frameworks as they are focused on web apps. The average site doesn’t need to be a web app.
I find even the term ‘web app’ a slightly odd and confused title, which is apt given the content of the article.
JavaScript developers always boasts about being able to create a ‘single-page web app’ quickly and efficiently, and for many instances that’s true. But in short, a ‘web app’ can just a website that has a bunch of favicons added, and manifest.json file set (which itself is just a dozen or so lines, which can readily be generated once and reused on a bunch of websites just by updating a few of the variables manually). This app (which is really just a website) will save to the user’s smartphone or tablet, and be available to use when they have an Internet connection.
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.
One benefit of JavaScript is that you can create something called a ‘service worker’ that allows you to save files locally so that a user can use the website even when not connected to the Internet. In addition a one-page website means different ‘states’ (which can be seen as analogous to being different pages, or pages showing different content) are not generated by going to a new page by clicking a link (for example) but just loading new content into the existing page via JavaScript, and storing that content as a ‘state’ so that a user can skip back and forth between content and always know where they are. Because service workers require you to explicitly state what files you want the user to save, and there are not loads of different pages but one page that swaps out content depending on what a user does, this can make it easier to decide or even automate saving files locally. A lot of these frameworks thus automatically handle this whole situation. That said, it’s not imperative to creating a web app – you can still do it manually.
In short, a web app can be created with no JavaScript, very simply, and even retrospectively. And a web app that is capable of operating offline can be made with very simple plugins that require very basic knowledge to implement.
Using frameworks to create web apps can make configuring this process much simpler by automating a lot of it, and handling a lot of the ‘state management’ side of things (for massive projects with a really complex code base and dozens of people working concurrently, having a fixed system that forces everyone to write in the same style is helpful, and having the state of the project – which may be large enough that no one person even works on the entire thing – can again make the website more manageable) but ultimately, if the complexity of setting up such a system is greater than the complexity of managing such a system without JavaScript (which in many cases is true) then people are not being sensible or efficient by using frameworks, and rather just following a ‘cool trend’.
Frameworks have their place. But as this article alludes to, they are not the catch-all solution. Sometimes, the increase complexity rather than reduce it. A good programmer – even one specialising in JavaScript – doesn’t necessarily just know how to use every JavaScript framework under the sun… they also know when not to use one, and instead use raw HTML and CSS.
I agree — judging purely from job postings, you would think that every website out there is a single-page web app, powered by APIs and reactive Javascript. But most businesses and people and organizations just need a darn website. And those websites should be fast-loading, accessible, responsive, beautiful, and effective — and that’s a job for a front-end developer.
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.)
In my experience (over 20yrs), if you aren’t great at JavaScript, you’ll struggle to find jobs. In fact, I and another so-called “CSS expert” were devalued and eventually pushed out of [big software company in Seattle].
As JavaScript frameworks have taken off, we’ve seen backend business logic move to the Frontend, requiring more complex/formal coding skills in a space that used to be reserved primarily for user interface layout and interactivity.
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.
I started writing HTML then CSS and eventually learn jQuery. I remember the struggle each of these technologies posed so I could feel competent in any of them. HTML was a head ringer, tables, nesting and memorizing all these tags, OMG! Then CSS, the box model, floats, and clearing them for layouts OMG! JavaScript starting in jQuery, not understanding how you can pass a value as a function or anything actually it was so hard!
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.
Meanwhile iphone was in their second or third generation. People were already hooked to this tiny screen device. So browsers or website makers wanted to have their share in people screen time. Hence browsers became powerful. With power they have now more room to compensate Javascript. A rather complex JavaScript and rest is described well by chris in this article.
Albeit this article is about Front end developers but did this shift affected backend developers as well?
Hallelujah!
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 digress…
Very nice article ! I remember when I was a fresher in front-end development doing HTML and CSS works for a start-up, a senior asked me “When are you going to learn JavaScript? Don’t you want to get into better IT companies?”. I was puzzled by his statement and even started feeling embarrassed for not knowing JavaScript. Today, I’ve learn’t enough JavaScript for DOM manipulation and traversal. Quite fun by the way ! :)
I’m a newbie at all this, self taught, and my passion is HTML and CSS. Now I’ve been plugging away at this for about 5 years and it occured to me about 3 years in that I had to learn more than the basics of JavaScript…I’m talking pure JavaScript, no React or what have you…When I decided I’d like to build websites, my goal was to become a front-end developer – as I understood it to be HTML, CSS and basic JavaScript. Of course the further I get into this world (and I am in love with this world baby) the more confused I am. Now I call myself a front-end designer. Still not sure how to market myself and not at all confident enough to apply for front-end developer jobs. Outside of frame works I don’t really want to to be a full stack developer. It’s way to much for my little brain to handle. I say all of this because it’s good to see these issues being brought to the forefront. It means they are being handled and that change should be embraced. I believe there is room for all us and all of us have a role to play. The industry is every changing, rapidly so, and it’s time for re-evaluating the roles and how we all use the powerful new tools that are being developed. This article gives me hope. I think I’m finally in the right profession. And I see a place for me…It’s a good thing!
It’s going to be much simpler I think & hope. The near future will make the front-end dumb, in the good sense. Javascript in the front-end will be a mere reflection of data controlled by a back-end of microservices orchestrated by a middle layer. I don’t see a role for front-end people who know just HTML and CSS, you need to bring more to the table.
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.
2001-2005: Web developer. I did classic ASP (visual basic 6.0), XML, XSLT, javascript, MsSQL, server maintenance, DNS, CI/CD, backups, email. Basically everything. Today you’d call that a “Full Stack Engineer”.
2005-2011: Front-end developer. I specialised in the front-end because CSS was there, and I honestly loved the huge differences between browsers. I was great at it. Javascript was basically just jQuery to show modal windows. I wrote HTML in templates that were sent down the line by server side code (Java, .Net, Ruby.)
2011-2015: Front-end engineer. The first bigger front-end frameworks made their appearance. I had forgotten how to stay up-to-date with regards to writing good code, so I had to relearn it. I used Backbone JS, Ember JS and a few others. Basically, I was great at HTML, CSS, and–in due time–also javascript.
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.
If you like HTML and CSS but do not want to learn javascript: Please, for the love of all that is nice in the world, refine your UX or UI-designer talents if you have them, and do that. The world doesn’t have enough of you guys who know what they don’t know.
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).
Obviously I had to space around those languages, i learnt LESS and SASS, i know some vanilla javascript, i had to learn a few basics of PHP and i know how to move around a DB too. Hell i even had to learn webpack and gulp to work with some of the new open CMS theming kits.
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?…
I think the divide has grown scaringly big and there’s a urge for a new, specific figure to group up these javascript heavylifters. I don’t know, “Logic developers”, I’m starting to fear that goin further our “seniority” as front end developers could suffer greatly.
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.
https://opc.com.au/blog/no-longer-just-developer
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.
Chris, you knocked it out of the park with this one. Great, fantastic article. Valid point, well spoken, and stylishly told. The article turning RED for “JavaScript Don Got Big” section is great storytelling. The quotes bring the story home. Chris, your personality and heart really shine here. Keep it up!
THANK YOU!
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.
Only four of use all that, and really all we need is to compile SASS and minify CSS and Javascript. Yet every time we want to upgrade the framework, we have to go down the rabbit-hole of a whole new dev stack. It’s ridiculous.
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.
Being more of a back end developer with JavaScript skills I find it appalling how the front end is being done now days. A lot of the work can be done with HTML/CSS and a little JS. Everything is just overly complicated for no real reason. I’ve been really digging the elegance of Basecamp’s model of web apps where they use HTML snippets/pages to do the work. Super simple and it gets a lot of the benefits of a JS front end for a fraction of the work. They can even do it for mobile apps which really surprised me.
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 divide is a myth. Effective front-end development requires identifying your goal and basing your priorities around it on a case by case basis. If there’s a design to match, that’s your goal. If not (you may be writing a JS utility for example) then JavaScript quality takes priority.
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.
I share the same frustration. I’ve been a Web Designer, Web Developer, and Front End Developer, mainly working on designs and HTML/CSS and basic presentational JavaScript/Jquery. I’ve seen that there are many Front End Developers today that are basically Angular/React experts and many job posts that require exactly that for a Front End Developer. I’m not sure I want to be an Angular person, I like designing, semantics, usability, SEO, accessibility, etc. And I have seen that good Angular/React people don’t care much about those things, can’t work with images, for example, don’t have any artistic skills and usually tend to do complicated things that could easily be done with CSS alone… So I think the whole problem is the absence of a clear role/title for those developers. They are not exactly back end developers. They are not exactly Front End Developers either. It all comes down to this: the whole idea of a Front End Developer is a person that can write code that is directly tied to design, which is HTML, CSS (Sass/Less) and presentational Javascript (Jquery/Bootstrap), etc. Those people have a great eye for details, understand colors, can work with images, care about semantics and SEO and now more and more about accessibility. At the same time, the idea of Back End Development is for developers that work on server-side code, database, etc. The engineering behind an application. Those people are great at math. But they don’t usually like HTML and they tend not to care about how things look like… Not even their hairs… So, to me, there is clearly a role missing here. We need to define a new role for developers that are in between those two. And I call that the “Middle Layer Developer”. So there you have it! Three distinct roles that connect everything! No need to have an identity crisis anymore. And the divide has been closed. To sum up:
Front End Developer – HTML (Semantics, Accessibility, SEO), CSS (Sass/Less), presentational Javascript (Jquery, Bootstrap, and others), image work, connection with designers.
Middle Layer Developer – Angular, React, Vue, Node, Go, as well as HTML and Javascript (the connection).
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
This…! ^
This trend has also affected backend developers as well. When I got started, PHP was the go-to for most applications. That’s why there was such an explosion of numerous PHP frameworks, and a working knowledge of at least 2 frameworks was important. Many frameworks have since died off or gone stagnant as the new preferred standard has become Node.js. According to Indeed.com, PHP has become the 7th most popular backend language with JavaScript taking the #3 spot. Everything moves so fast, it often feels impossible to keep up.
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.
More recently I have begun to wonder if too much reliance on JavaScript frameworks and libraries was resulting in today’s developers simply not knowing HTML and CSS as well as we all did and all took for granted when I learnt the trade. Your article is confirming that idea as being the likely cause. Unfortunately it is the accessibility compliance that suffers, besides poor coding and CSS.
I have noticed this divide/trend for a number of years and it is very validating to read this article. I am very much on the HTML, CSS, a11y, design, and UX side of the Front End Developer role. It’s no joke that my skill set is undervalued in my company because I am not an expert in Javascript. (I only know enough to get by.) However, when my “full-stack” developer colleagues need help debugging these things, I am the first person they call to for help…and it happens often than you’d expect because I am the expert. Or, they just brush over these parts and let me clean up their mess later. I am not your HTML and CSS custodian!
The monetary divide is real and completely unfair. How can one language be the defining line for salary?
When it came to discussing a raise with my boss last year, I was not given one because I lacked Javascript skills. So sorry it was my mistake for filling my time with code reviews, refactoring HTML and CSS, and teaching our “full-stack” developers how to write proper HTML, CSS, and a11y that I did not have time to prioritize learning the company’s Javascript frameworks.
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.
Over the years, we have grown confident that CSS and HTML are code. I don’t see the rise of JavaScript and structured programming practices as a threat, but a welcome addition. A discipline that once again we need to bridge to, especially for the most of us who dabbled in JS when it was a simpler browser-based language.
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?
I used to be a “full stack developer” but that was simply because there was no one around to pick up the back end. I spent all my time thinking and worrying about things I had to learn about security and servers and so on that I didn’t keep up with HTML/CSS. Currently I am working solely on UI and leaving all that stuff to some excellent back end developers. They are equally happy not having to build the front end. JavaScript is where we meet.
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.
Path 1: That person starts to learn about User Interaction and User Experience, then becomes an UI/UX Designer. This person usually has a deep knowledge in JavaScript, but focused on DOM interaction and design.
Path 2: That person starts to learn about frameworks, implementation and kinda lingers on the edge of front and backend. This person usually has a deep knowledge in JavaScript, but focused on functionality, not design.
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?
Scope
Closures
Prototypes
Linear algorithms
…
— divide right here —
Partials & Curry
Trees, Graphs
OOP
TDD
…
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.
Waoh! What a great post that summarised what have been bothering for some years. My HTML/CSS skill has not taken me notable position just because most of job postings out there are all about JS. And I have been learning JavaScript for more than two years now. Pls, help us resolve the overlaps in this field so that we that are coming up in this field can take our skillsets beyond limitation.
I have decades of experience in both JavaScript and CSS, but I’m absolutely not on the JavaScript side of this great divide.
JavaScript is awesome, it’s my favourite language to use. However, I would never build a website that is rendered by JavaScript. I mean when there’s no site without JavaScript, i.e. client-side rendering.
Client-side rendering is flawed. We did that for a customer in 2004, never again! I think we hit every one of the issues from Everyone has JavaScript, right?. It just wasn’t worth it.
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).
Most website authors (that care about accessibility) only follow WCAG, but UAAG says it’s an accessibility requirement to allow users to disable scripts. So can client-side rendering be considered accessible, or not? They’re certainly not accessible when the JavaScript doesn’t execute.
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:
https://hackernoon.com/the-backendification-of-frontend-development-62f218a773d4
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.
“Frontend Weekly” is written by the JavaScript Weekly people, so it is understandably biased. Headlines there are all framework based. (https://frontendfoc.us/issues/380)
Managing Image Breakpoints with Angular
Animation in React
Working with the React Context API
New JavaScript Features That Will Change How You Write Regular Expressions
“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.
It has become a problem for me, since on one hand, the javascript ecosystem changes too fast and it’s difficult to learn even the names of all the libraries out there, while on the other, my practical knowledge ended up being that of a ui web developer, so it becomes even more difficult to jump to the JavaScript side without feeling I wasted my time on the design side (I like css/html and ui overall, but it feels weird to be in this particular position).
Brad Frost has already coined a nice word for this .. semantic issue. I’ve been using it ever since: Frontend Design
To quote from his post: ” Frontend design involves creating the HTML, CSS, and presentational JavaScript code that makes up a user interface. ” – so, its exactly what this article is about, isnt it? The great divide between Javascript Frontend Developers and Frontend Designers (back in the days we just called it Webdesign, but nowadays folks think its something what graphic designers do .. ugh).
This discussion is really nice and needful so its great that someone like Chris Coyier write about it. I am currently working as html/css front-end developer. If i see the job opportunities in the Netherlands there is slightly a shift thats separate between these two disciplines. That being said i totally agree that writing correct html / css is not an easy job and especially in large projects its a huge challenge to organise and write maintainable css, i, still by myself have a lot of challenges in this area and learning everyday. But i think we should be honest the salary and the job opportunities are much better for js engineers and thats why companies want a front-end developers which are good in both fields and i totally understand that. I even think that a html/css front-end developer should train him/her self to learn javascript because you can better communicate with your engineers if you understand some basic concepts. This also applies to javascript engineers who should do some reading about html/css, basic knowledge about box model, css layout (grid, flexbox etc).
My opinion is that we shouldn’t separate these to disciplines and demand from html/css designers as well as javascript engineers to write decent html/css and write decent javascript.
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.
I used to be a front-end developer back when all you needed was HTML, CSS and jQuery and/or JavaScript. But without a solid foundation in React, Vue or Angular, I feel like I”m sitting in no-man’s land.
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.