8 Things Every Front-End Developer Must Learn

Let’s start off by talking about what this post isn’t: This isn’t a list of languages. This isn’t a list of libraries. This isn’t a list of complaints. This doesn’t contain any code. There are plenty of opinionated posts like that out there.

Every new feature at Degreed undergoes a rigorous vetting and prioritization process. We move quickly and we crank out a lot of great features month to month. As such, we have to be sure that the things we are working on are going to provide value. We have to be sure that we are executing well and not leaving out important details that will make these features successful.

As a front-end developer, there are a handful of concepts that I mentally “check off” as our team marches through the planning and execution phases. These are crucial habits for success. The earlier in the process you begin thinking about these, the more smoothly things are likely to go. Since Degreed is all about learning and sharing what we’ve learned, I wanted to move them from a mental checklist to a real checklist. I hope you find this useful and that you will share some of your own ideas in the comments below.

• Accessibility
• Responsive Design
• Performance
• Consistency
• Cross-Browser Compatibility
• Security
• Internationalization
• Usability/User Experience

Let’s take a closer look at each concept.

Accessibility

A diverse set of users is going to interact with your product. Caring about cross-browser compatibility but not about accessibility is a contradiction. According to WebAIM, about one fifth (20%) of the population has some kind of disability. WebAim goes on to make the following statement:

“Not all of these people have disabilities that make it difficult for them to access the internet, but it is still a significant portion of the population. Businesses would be unwise to purposely exclude 20, 10, or even 5 percent of their potential customers from their web sites. For schools, universities, and government entities it would not only be unwise, but in many cases, it would also violate the law.”

How will the feature you are developing work for someone who can’t use a mouse? Is there an alternative action you can create that enables a keyboard only user to perform the same task? How will visually impaired users “see” your content? What is the basic type of component you are building and how will you describe that to screen readers? How will increasing base font sizes in the browser affect the overall design?

Learn more:
It’s Not About Morals: Accessibility is for the Masses
Getting Started With AriaAccessibility Patterns for the Web

Responsive Design

We are well beyond the point where mobile users have outnumbered desktop users. The sooner you start thinking about how a feature will behave on different screen sizes, the more successful your feature will be and the fewer compromises you’ll have to make to pull it off.

What will happen to your feature when it is viewed on a smaller screen? What will happen on a large projector in a conference room? What if your user rotates their portable device from horizontal to vertical orientation? If a user is happy with a feature on their laptop, will they be just as happy with it on their phone?

Learn more:
For a Future-Friendly Web
Responsive Images: The past, present, and future
DevTools Device Mode

Performance

Optimizing for faster performance in the planning phases of a project isn’t always necessary. It’s a good idea to keep it in check as you go, but also avoid premature optimization. Perceived speed is often more important to think about in the early stages, since the design and flow can have a big effect on it.

How will you develop this feature in such a way that it doesn’t slow down your user from completing the task they set out to do? How will you indicate to your users that they aren’t going to wait too long? How can you mask wait time to have better perceived speed? Are you familiar with all of the best practices and known issues with the framework, library, or methodology you are using to be able to avoid optimization pitfalls?

Learn more:
How to Make Apps Feel Faster
Better Performance Through Better Design
Top CSS techniques for optimal performance

Consistency

Consistency is always easier to manage at the beginning of a project than during the maintenance phase or when adding new features. Having a clear style guide and a clear set of coding guidelines can be invaluable. Rules like this can feel restrictive at times, but it turns out that’s a good thing, especially as your team grows and people come and go from your organization.

Does this new feature look and feel the same as the rest (i.e. follow the style guide)? Is there anything being proposed that would mean adding to or changing the style guide? Are your coding patterns going to be clear and feel comfortable to the next developer who sees it?

Learn more:
Introducing: U.S. Web Design Standards
Large Scale CSS Refactoring at trivago
Building the UI for the new The Times website

Cross-Browser Compatibility

Chances are you do not need me to tell you why supporting various browsers is a good idea; it’s one of the primary roles we have as front-end developers. What I will say is that the longer you do it the more likely you will be able to spot pitfalls early. Having a clear set of supported browsers that your whole team agrees upon is vital to having constructive discussions about how a design might behave and how things might need to change to be accommodating.

How will you “gracefully degrade” this feature in browsers that may struggle with it? Does it make use of native browser components that might affect the overall design (radio buttons don’t all look the same, scrollbars on Windows based browsers may affect the overall width, etc.)?

Learn more:
Modern browser testing
Think you know the top web browsers?
Browser Support for Evergreen Websites

Security

Keeping in mind that most forms of client-side security should be seen as a deterrent and not actual security, there are still plenty of exploits we need to be aware of and be thinking about as we move into the coding phase of our new feature. It is our responsibility to work with server-side developers to ensure we are in sync with our checks and balances in that regard.

How much of this new feature relies on user input? How could this feature be used to exploit other features? Are you making assumptions about the amount and type of data you will be getting from a user or from the server? Are you going to rely on code someone else wrote and do you understand exactly what that code does?

Learn more:
Cross-site scripting for dummies
Of Course I’ll Let You Execute Arbitrary Javascript Code in My Users’ Browsers
Web security

Internationalization

Your audience, your budget, and your strategy all play a big factor into whether or not you can or should be worrying about internationalization (i18n). If you do need to support multiple languages (at the time of this writing we support more than 25 languages at Degreed) it’s important to keep in mind how the text in your new feature will affect the layout as it changes in length.

Does the design account for varying amounts of text? Are there any idioms, slogans, or slang being used that might not make sense if translated literally?

Note: even if you don’t support i18n, these pitfalls usually also apply to accessibility!

Learn more:
Text size in translation
Writing for an international audience
8 of our favorite ridiculously long German words

Usability/User Experience

While all of the above bullet points have to do with the overall user experience, there is a lot more that goes into UX. Every team approaches UX ownership differently, but there is no question that it is part of the front-end developer’s job no matter who “owns” it.

Are there any potential points of confusion with the design? Will your grandparents be able to use this feature? Can you think of a more standard approach or pattern that users will already know and recognize?

Learn more:
10 Things I Learned About UX By Being Drunk
The essential secret to successful user experience design
Why UI Changes Annoy People and How to Handle It

Conclusion

Frameworks come and go, available tools continue to come and go to make our jobs easier, and languages continue to evolve. My intent with sharing this list is to provide things you must know that will continue to be useful no matter what else changes in the industry.

All of the links shared in this post can also be found in a tidy little Pathway on Degreed where you can keep track of the links you’ve read or watched and begin adding them—alongside all of your learning—to your Degreed profile.