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 skill sets are heavily revolved around JavaScript.
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.
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.
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.
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?
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.
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 among 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 skill set 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
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
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:
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.
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.
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.
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.
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
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.
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.
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!
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.