What I look for when I review front end code

There’s no silver bullet to writing awesome code, but there are best practices to be followed that will make your life (and the next person’s) easier.

When conducting reviews and architecting solutions, these are the things I think about:

How maintainable is this?

Will I come back to this code in 6 months and be able to understand it? A great way to aid this process are well-reasoned code comments.

There are a lot of differing opinions about the implication of commenting your code — like the existence of comments mean your code isn’t obvious enough — but I’d argue in favor of them every time. The reason being: context. The greatest gift you can give to the next developer (that includes future you!) is a peek into your headspace.

—

Is this designed in an accessible way?

There are a number of great specifications for accessibility on the web. The most prominent one is WAI-ARIA.

While I don’t expect my developers to have this memorized, I do look to see if they tried to use the site via keyboard only and added relevant tests. It’s the least we can do to support the many different kinds of people that visit our projects.

A good starting point on the journey toward better accessibility in your projects is to use the fantastic jsx-a11y eslint plugin: https://www.npmjs.com/package/eslint-plugin-jsx-a11y

I also meet with our designers regularly to give feedback on color contrast (you can check your own site’s contrast here!) and other UX concerns.

—

What are the performance characteristics of this code?

Browsers are getting faster every day and what was deopt’ed yesterday might not be a problem tomorrow.

vhf/v8-bailout-reasons

However, if you are supporting mobile devices, some more aggressive strategies are worthwhile.

In particular, I look for code that optimizes for creating the least memory pressure (therefore leading to less frequent garbage collection events.) Desktop browsers usually can execute GC pauses rapidly, but it can be catastrophically slow on mobile devices and lead to poor perceived performance, also known as “jank”.

Key items to watch out for:

1. Creating a lot of garbage-collectible objects every rendering cycle.
2. Not reusing arrays in hot code paths (you can empty them out by setting length to 0 and then use them again, e.g. array.length = 0)
3. Event listeners on scroll (avoid if possible, or use a passive listener if your browser support matrix allows it)
4. Undelegated event listening for large lists of homogenous nodes (each new listener is one more thing for the browser to keep track of, use a delegation strategy where possible)

—

Does it look good?

Something that surprises me about many front end developers I’ve worked with is a mental divorce of functionality from design. People tend to expressly fulfill the needs of a JIRA ticket, for example, but don’t put nearly as much time or effort into making sure the end product is jank free-and feels right.

I do acknowledge that UX intuition is a special skill, but it’s one that can be learned and honed through practice.

One thing I definitely recommend for FE devs of any experience level are crash courses in color theory and visual design. This knowledge allows you to become part of the creative process, rather than the last mile. It’s a real game-changer in terms of how you work with your more visually-oriented colleagues and can drastically shorten the feedback loop when building out web experiences.

That’s all for now, hope you found this useful!

—

Check out my projects:

• markdown-to-jsx, an ultra lightweight markdown React component
• buttermilk, beautifully simple routing for React projects