It’s time we applied “separations of concerns” to frontend engineering!

Is it okay to require pixel perfect, accessible, high-performance frontend developers, with a progressive enhancement-oriented mindset and a knack for code modularity? YES.

Should every FE developer be doing all of the above every day in parallel? Probably not.

I’d use the analogy of “jack of all trades, king of none” for those who do all the above every day. I know because I did that in my early frontend years. Instead, now, I try solving one problem at a time.

e.g., pixel perfection has to be solved by a UI Framework, not unlike Bootstrap or Grids. Having such a framework ensures your UI widgets are in order and work cohesively across devices, form factors and are pixel aligned to your vision. UI Frameworks have been proven to increase frontend team productivity by a lot.

Not having to eventually worry about the above while developing features means you’re focussing on the business logic and not “if/when/how/why” your info component will work with your accordion.

Here are ways to ensure you’re focussing on one problem at a time:

1. Pixel Perfection: Let the UI Component library layer ensure pixel perfection for design. Sometimes this means saying “NO” to design asks which violate the already defined design system for your org. If there must be an exception, get your design guidelines updated and build support for these requirements into the framework layer. Over time, Design will consistently adhere to the guidelines.
2. Accessibility – is an interesting area. Mostly neglected, but more often, not implemented properly. While most developers take the web for granted, we often miss out on people with disabilities. Disabilities do not only entail physical deformities, but it could also be something as minor as colour blindness which requires Design to choose accessible contrast ratios. One would go deeper to ensure screen readers are able to properly identify and read associated metadata, in the correct order. Not many web development teams focus on this aspect in-depth, but those who do, are often blessed by search engines over the competition.
   This layer is handled by the UI component library development too, but ideally done a stage after the initial set of UI widgets are available.
3. Performance: One would argue that every piece of code we write should be performant, so how would one separate this concern. I’d like to point out that the basic responsibility of ensuring common best practices are ensured is on the developer at all times, but advanced performance techniques like debouncing where applicable, memoising, caching etc needs to be thought through two times – once before any coding begins, laying out the approach, and later when the code goes to review. Pull Request driven git workflows allow teams to critically evaluate every piece of code that gets shipped eventually. This layer has to ensure that the code is performant.
4. Progressive Enhancement: occasionally thought through at the end, this technique lets end users get a pleasant experience of using your web/mobile applications by reducing waiting times, download sizes and reducing overall internet congestion. Everybody loves a quick time-to-render timeline, most just never devote enough development cycles to ensure it is ensured regularly.
5. Code Modularity: My recommendation to frontend development teams in almost every industry is to take a couple of dev-days dedicated to revisiting code written over the past few sprints across platforms (web/mobile) – try and figure out what can be reused, move it around to shared states. This is a hat we wear while writing any new code, to ensure code repetition is kept to the minimum.

Think about the above. If you’re asked to continuously write new features back to back. Could you do enough justice to every aspect listed above while ensuring timely delivery?

As a Web Engineering Team Leader at various companies – small and large, I’ve had to dedicate enough time for the above cycles to ensure new Frontend developers understand the importance of the various activities.

Depending upon the size of your org you might want to try one of the following:

1. Have rotating responsibilities between the various FE devs in the team on a regular basis.
2. Have dedicated sprints for the above when everyone focuses on one of the above topics for a week or two.
3. For micro teams, let the developers focus on one thing at a time, it is okay to be building UI components for a sprint and not deliver a feature during that time – especially if it means future deliveries are going to be more dependable.

Do you agree? How does your team currently handle all of the above?