How to Think Like a Front-End Developer by Chris Coyier

Alright! It’s day two of An Event Apart in Seattle. The first speaker of the day is Chris Coyier. His talk is called How to Think Like a Front-End Developer. From the website:

The job title “front-end developer” is very real: job boards around the world confirm that. But what is that job, exactly? What do you need to know to do it? You might think those answers are pretty cut and dried, but they’re anything but; front-end development is going through something of an identity crisis. In this engaging talk, Chris will explore this identity through the lens of someone who has self-identified as a front-end developer for a few decades, but more interestingly, through many conversations he’s had with other successful front-end developers. You’ll see just how differently this job can be done and how differently people and companies can think of this role—not just for the sake of doing so, but because you’ll learn to be better at your own jobs by understanding how other people are good at theirs.

I’m going to see if I can keep up with Chris’s frenetic pace…

Chris has his own thoughts about what front-end dev is but he wants to share other ideas too. First of all, some grammar:

I work as a front-end developer.

I work on the front end.

Those are correct. These are not:

I work as a front end developer.

I work on the front-end.

And this is just not a word:

Frontend.

Lots of people are hiring front-end developers. So it’s definitely a job and a common job title. But what does it mean. Chris and Dave talked to eight different people on their Shop Talk Show podcast. Some highlights:

Eric feels that the term “front-end developer” is newer than the CSS Zen Garden. Everyone was a webmaster, or as we’d say now, a full-stack developer. But if someone back then used the term “front-end developer”, he’d know what it meant.

Mina says it deals with things you can see. If it’s a user-facing interface, that’s front-end development.

Trent says that he thinks of himself as a web designer and web builder. He doesn’t feel he has the deep expertise of a developer, and yet he spends all of his time in the browser.

So our job is in the browser. You deal with the browser (moreso than other roles). And by the way, there are a lot of browsers out there.

Maybe the user is what differentiates front-end work. Monica says that a back-end developer is allowed not to care about the user if their job is putting a database together. It’s totally fine not to call yourself a front-end developer, but if you do, you need to care about the user.

There are tons of different devices and browsers. It’s overwhelming. So we just gave up.

So, a front-end developer:

• Is a job and a job title.
• It deals with browsers, devices, and users.
• But what skills does it involve?

It’s taken for granted that you can use a computer. There’s also the soft skills of interacting with co-workers. Then there are the language-specific core skills. Finally, there are the bonus skills—all the stuff that makes you you.

Core skills

The languages you need to strongly understand to read, write and maintain them.

HTML and CSS. Definitely. You don’t come across front-end developers who don’t do those languages. But what about JavaScript?

Eric says it’s fine if you know lots of JavaScript but it’s also fine if you don’t write everything from scratch. But you can’t be oblivious to it. You need to understand what it can do.

So let’s put JavaScript into the bucket of core skills too.

Peggy believes that as a front-end developer you need to have a basic proficiency in accessibility too. This is, after all, about user-facing interfaces.

Bonus skills

The Figma team have a somewhat over-engineered graphic of all the skillsets that people might have, between “baseline” and “supplementary”.

Perhaps we all share a common trunk of skills, and then we branch in different directions.

Right now though, it feels like front-end development is having an identity crisis. It’s all about JavaScript, which is eating the planet.

JavaScript

JavaScript is crazy popular now. It’s unignorable. Yes, it’s the language in the browser, but now it’s also the language in loads of other places too.

Steven Davis says maybe we need to fork the term front-end development. Maybe we need to have UX engineers and JavaScript engineers. Can one person be great at both? Maybe the trunk of skills forks in two very different directions.

Vernon Joyce called this an identity crisis. The concepts in JavaScript frameworks are very alien to people with a background in HTML, CSS, and basic interactive JavaScript.

You could imagine two people called front-end developers meeting, and having nothing in common to talk about. Maybe sports.

Brad says he doesn’t want to be configuring build tools. He thinks of himself as being at the front of front-end development, whereas other people are at the back of front-end development.

This divide is super frustrating to people right now.

Hiring

Michael Schnarnagl brings up the point about how it’s affecting hiring. Back-end developers are being replaced with JavaScript engineers. Lots of things that used to be back-end tasks are now happening on the client side. Component-driven design, site-level architecture, routing, getting data from the back end, mutating data, talking to APIs, and managing state—all of those things are now largely a front-end concern.

Let’s look at CodePen. There’s a little heart icon on each pen. It’s an icon component. And the combination of the heart and the overall count is also a component. And the bar of items altogether—that’s also a component. And the pen it sits under is a component. And the page it’s in is a component. And the URL for that page is a component. Now the whole site is a front-end developer’s concern.

In the past, a front-end developer would ask a back-end developer for an API endpoint. Now with GraphQL, the front-end developer can craft a query to get exactly what they need. Sure, the GraphQL stuff had to be set up in the first place, but that’s one-time task. Once it’s set up, the front-end developer has everything they need.

All the old work hasn’t gone away either. Semantics, accessibility, styling—that’s still the work of a front-end developer as well as all of the new stuff listed above.

Hiring is a big part of this. Lara Schenk talks about going for an interview where she met 90% of the skills listed. Then in an interview, she was asked to do a fizzbuzz test. That’s not the way that Lara thinks. She would’ve been great for that job, but this single task derailed her. She wrote about it, and got snarky comments from people who thought she should’ve been able to do the task. But Lara’s main point was the mismatch between what was advertised and what was actually being hired for.

You see a job posting for front-end developer. Who is that for? Is it for someone into React, webpack, and GraphQL? Or is it for someone into SVG, interaction design, and accessibility? They’re both front-end developers. And remember, they can learn one another’s skills, but when it comes to hiring, it has to be about the skills people have right now.

Peggy talks about how specialised your work can be. You can specialise in SVG. You can specialise in APIs and data.

We’re probably not going to solve this right now. The hiring part is definitely the worst part right now. One solution is to use plain language in job posts. Make it clear what you’re looking for right now and explain what background you’re coming from. Use words instead of a laundry list of requirements.

Heydon Pickering talks about full-stack developers. Their core skills are hardcore computer science skills.

Brad Frost concurs. It tends not to be the other way around. The output tends to be the badly-sketched front of the horse.

Even if there is a divide, that doesn’t absolve any of us from doing a good job. That’s true whether it’s computer science tasks or markup and CSS.

Despite the divide, performance, accessibility, and user experience are all our jobs.

Maybe this term “front-end developer” needs rethinking.

The brain game

Let’s peak into the minds of very different front-end developers. Chris and Dave went to Dribbble, pulled up a bunch of designs and put them in front of their guests on the Shop Talk Show.

Here’s a design of a page.

• Brad looks at the design and sees a lot of components of different sizes and complexity.
• Mina sees a bunch of media objects.
• Eric sees HTML structures. That’s a heading. That’s a list. Over there is an unordered list.
• Sam sees a lot of typography. She sees a type system.
• Trent immediately starts thinking about how the design is supposed to work in different screen sizes.

Here’s a different, more image-heavy design.

• Mina would love to tackle the animations.
• Trent sees interesting textures and noise. He wonders how he could achieve those effects without exporting giant image files.
• Brad, unsurprisingly, sees components, even in a seemingly bespoke layout.
• Eric immediately sees a lot of SVG.
• Sam needs to know what the HTML is.

Here’s a more geometric design.

• Sam is drawn to the typography.
• Mina sees an opportunity to use writing modes.
• Trent sees a design that would reflow and reshape itself well.
• Eric sees something with writing mode, grid, and custom fonts.

Here’s a financial mobile UI.

• Trent wants to run it through a colour-contrast analyser, and he wants to know if the font size is too small.

Here’s a crazy festival website.

• Mina wonders if it needs a background video, but worries about the performance.

Here’s an on-trend mobile design.

• Monica sees something that looks like every other website.
• Ben wonders whether it will work in other parts of the world. How will the interactions work? Separate pages or transitions? How will it feel?

Here’s an image-heavy design.

• Monica wonders about the priority of which images to load first.

Here’s an extreme navigation with big images.

• Ben worries about the performance on slow connections.
• Monica gets stressed out about how much happens when you just click on a link.
• Peggy sees something static and imagines using Gatsby for it.

Here’s a design that’s map-based.

• Ben worries about the size of the touch targets.
• Monica sees an opportunity to use SVGs.

Here’s a card UI.

• Ben wonders what the browser support is. Can we use CSS grid or do we have to use something older?
• Monica worries that this needs drag’n’drop. Now you’ve got a nightmare scenario.

Chris has been thinking about and writing about this topic of what makes someone a front-end developer, and what makes someone a good front-end developer. The debate will continue…

“Evaluating Technology” by Jeremy Keith – An Event Apart video on Vimeo

This is a recording of my Evaluating Technology talk from An Event Apart in Denver just over a year ago. This was the last time I ever gave this talk, and I think you can tell that the delivery is well-practiced; I’m very happy with how this turned out.

In this 60-minute presentation recorded live at An Event Apart Denver 2017, Jeremy Keith helps you learn to evaluate tools and technologies in a way that best benefits the people who use the websites you design and develop.

A Redesign with CSS Shapes · An A List Apart Article

Eric walks through a really nice use of CSS shapes and @supports on a page of the An Event Apart site.

It’s a nice little illustration of how we can use advanced features of CSS right now, without the usual wait for widespread support.

The Long Web by Jeremy Keith – An Event Apart Video on Vimeo

This is a talk I gave at An Event Apart about eighteen months ago, all about irish music, the web, long-term thinking, and yes, you guessed it—progressive enhancement.

Ethan Marcotte AEA Boston June 18, 2012 on Vimeo

Ethan’s excellent talk from last year’s An Event Apart.

In this session Ethan reviews strategies for handling trickier elements that would make even the most seasoned designer quail: stuff like advertising, complex layouts, deep navigation patterns, third-party media, and, yes, actual, honest-to-goodness content.

CSS { In Real Life } | Thoughts From CSS Day

It’s clear that companies don’t value CSS skills in the same way as, say Javascript — which is reflected in pay disparity, bootcamp priorities, and the lack of visibility in job descriptions. It’s not uncommon to see front end job specifications listing React, Redux, Typescript and more, with barely a passing mention of HTML and CSS, despite being core web technologies. New developers are encouraged to learn just enough CSS to get by, rather than cultivate a deep knowledge and appreciation for the language, and that’s reflected in the messy, convoluted code, riddled with bad practices, that many of us have to clear up afterwards.