The boring front-end developer

Cool front-end developers are always pushing the envelope, jumping out of their seat to use the latest and greatest and shiniest of UI frameworks and libraries.

They’re often found bridging the gap between native apps and web and so will strive to make the UI look and behave like an app. Which app? you may ask. iPhone? Android? What version? All good questions, alas another topic altogether.

However, there’s another kind of front-end developer, the boring front-end developer. Here’s an ode to the boring front-end developer, BFED if you will.

Browser support

The BFED realises that while not all experiences will be identical, all browsers can be used to consume a website, even gasp, IE6 and below. He/she will promote Progressive Enhancement and Cross-browser (not Multi-browser) scripting at any given opportunity.

The BFED also realises it is not a feat to drop support for a particular (set of) browser(s) and understands that forgetting about the existence of those users hurts them and their perception of the company/product.


The BFED realises that users have different abilities and preferred ways of using a computer. Whether it’s a mouse, finger, thumb, screen reader, keyboard or a combination of all, make websites consumable no matter the audience, screen size or capability of the browser.


When given the choice to add a preprocessor (e.g. LESS, SASS, CoffeeScript etc) to the tech stack, the BFED knows there’s a much deeper impact beyond just “writing less code”.

“Will debugging code be more difficult?”, “Might performance degrade?” and “Will I be slowed down due to compile times?” are just some of the questions the BFED will consider to avoid problems in the future.

UI design

The BFED embraces the constraints and limitations of the browser so that he/she doesn’t find him/herself in a world of Adaptive Design and UA sniffing because that world is horrible, ill-advised and costly.

It is best to include the BFED early on in the UX design process to save wasting time designing a UI that should ultimately be avoided (see Fixed Position and Misusing The Select Control for more on that) and that can likely be designed more simply.

The BFED will also suggest the use of native form controls realising that browsers will enhance the experience where possible, particularly on mobile, and doesn’t try to control the look and feel too much as he/she knows that the brand will not suffer because of that decision.

The BFED will also suggest that links are styled as such, and with underlines, so that users can identify them within copy.

Third party CSS and Javascript libraries and frameworks

The BFED will carefully select third party code based on the quality of the code itself by reviewing source code, not based on the popularity of said code. He/she favours reliability over popularity every time.

UI architecture

The BFED will adhere to the following quote:

As a Lead JavaScript Engineer, I try to get my team to write as little JavaScript as possible.

James Norton

Furthermore, the BFED realises that Single Page Applications cause severe problems and that avoiding them and leaning on the server appropriately, provides a better experience and reach.


The BFED will develop a site based on the context of the problem and provide a solution accordingly. He/she will not just use [insert buzz word here] to improve his/her chances of finding another job based on the current technology fad in order to increase their day rate.


Be a great front-end developer. Be boring.


My response to Hacker News comments.

Inspired by The Boring Designer by Cap Watkins’ — thank you.