{"id":280085,"date":"2019-01-21T09:48:46","date_gmt":"2019-01-21T16:48:46","guid":{"rendered":"http:\/\/css-tricks.com\/?p=280085"},"modified":"2021-08-19T13:03:54","modified_gmt":"2021-08-19T20:03:54","slug":"the-great-divide","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/the-great-divide\/","title":{"rendered":"The Great Divide"},"content":{"rendered":"\n
\n
\n

Let\u2019s say there is a divide happening in front-end development.<\/em> 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<\/a>, and in-person discussion, it\u2019s, as they say… a thing<\/em>.<\/p>\n\n\n\n\n\n\n\n

The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.<\/p>\n\n\n\n

\n
\n

On one side,<\/strong> an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript.<\/p>\n<\/div>\n\n\n\n

\n

On the other,<\/strong> 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.<\/p>\n<\/div>\n<\/div>\n\n\n\n

Let\u2019s hear from people who are feeling this divide.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In response to our post, “What makes a good front-end developer?”<\/a><\/em>, Steven Davis wrote<\/a>:<\/p>\n\n\n\n

I think we need to move away from the term myself<\/strong>. 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.<\/p>

So sick of being great at CSS but being forced into JavaScript. I’m not a programmer!<\/strong><\/p><\/blockquote>\n\n\n\n

This schism isn’t happening under our feet. We’re asking for it.<\/p>\n<\/div><\/div>\n\n\n\n

\n

I heard it called an identity crisis<\/em> for the first time in Vernon Joyce’s article, “Is front-end development having an identity crisis?”<\/a><\/em> He points to the major JavaScript frameworks:<\/p>\n\n\n\n

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.<\/strong><\/p><\/blockquote>\n\n\n\n

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.<\/p>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n

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.<\/p>\n\n\n\n

\"\"
Who gets the job? Who’s right for the job? Is the pay grade the same for these skill sets?<\/figcaption><\/figure>\n\n\n\n

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<\/a>:<\/p>\n\n\n\n

I’d love more job descriptions to be more vulnerable<\/strong> and open \u2014 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.<\/p><\/blockquote>\n\n\n\n

\"Job
This seemed to work pretty well for us at CodePen. Our own Cassidy Williams said she really appreciated this writeup when Rachel Smith sent it to her to consider.<\/figcaption><\/figure>\n\n\n\n

“Front-end developer” is still a useful term. Like Mina Markham described to us<\/a> 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:<\/p>\n\n\n\n

Front-end developer is shorthand for when the details don’t matter. Like being in an indie-rock band \u2014 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 \u2014 we just have to use it.<\/p><\/blockquote>\n\n\n\n

To put a point on this divide<\/em> a bit more, consider this article by Trey Huffine, “A Recap of Frontend Development in 2018<\/a><\/em>.”<\/a> 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:<\/p>\n\n\n\n

That’s OK.<\/em> You can still be a front-end developer. 🙏<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Remember just last last year how Frank Chimero, who builds incredibly great websites for himself and clients, was totally bewildered<\/a> with where front-end development had gone? To summarize:<\/p>\n\n\n\n

… other people\u2019s 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\u2019s when I closed my laptop and slowly backed away from it. We\u2019re a long way from the CSS Zen Garden where I started.<\/p><\/blockquote>\n\n\n\n

A long way indeed. I might argue that you don’t have<\/em> to care. If you’ve been and continue to be successful building websites any way you know how for yourself and clients, hallelujah!<\/em> Consider all this new toolchain stuff entirely as an opt-in deal that solves different problems than you have.<\/p>\n\n\n\n

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<\/a>:<\/p>\n\n\n\n

As toolchains grow and become more complex, unless you are expertly familiar with them, it\u2019s 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.<\/p><\/blockquote>\n\n\n\n

Who needs these big toolchains? Generally, it’s the big<\/em> sites. It’s a bit tricky to pin down what big<\/em> means, but I bet you have a good feel for it. Ironically, while heaps of tooling add complexity<\/em>, the reason they are used is for battling complexity<\/em>. Sometimes it feels like releasing cougars into the forest to handle your snake problem. Now you have a cougar problem.<\/p>\n\n\n\n

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<\/a>:<\/p>\n\n\n\n

Big team needs “x” that\u2019s why “x” is the best solution for everyone. I think this is highly toxic for smaller teams with different requirements and definitions of what\u2019s “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\u2019s VIP circus.<\/p><\/blockquote>\n\n\n\n

What is going on here? What happened? Where did this divide come from? The answer is pretty clear to me:<\/p>\n\n\n\n

\n
\"JavaScript<\/figure><\/div>\n\n\n\n

So big:<\/p>\n\n\n\n

  • 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.<\/li>
  • 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.<\/li>
  • 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.<\/li>
  • 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.<\/li><\/ul>\n\n\n\n

    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<\/strong>, and I did a whole talk on it:<\/p>\n\n\n\n

    \n