The ongoing defence of frontend as a full-time job

I am currently looking for a new job. One thing that keeps happening is that people get my CV, are impressed but then ask me that I seem to be focused on the front end a lot and what my experiences with backend and full stack development are. It seems to me that we’ve come full circle back to when I started as a web developer and had to sell and explain the notion of a front end expert as a real, full-time job, 21 years ago:

Here’s the deal: a frontend developer isn’t a mediocre coder that only dabbles in “easy” languages like HTML, CSS and JavaScript. A frontend developer is someone who made a conscious choice to build interfaces for the unknown with a laser sharp focus on the end user’s experience.

The web isn’t just another compilation target. It’s a platform that allows the user full control over the look and feel. It’s also the only platform resilient enough to weather any change you throw at it. The web works on desktop, android and iOS. And it can do that with one codebase. If you have dedicated developers who know what they are doing and don’t just expect to find a plugin or extension that will magically make your product accessible to all and perform well.

Here’s the not so dirty secret: no matter what platform you choose, what language you write your code in or what framework or library you use – the final thing that arrives on your web users devices is HTML, CSS and JavaScript.

Each (with HTML to a small degree) can cause performance problems, cross-browser functionality issues and become a barrier for users on sub-par connections and platforms or with different abilities. Slow performance is known to lose you end users and being inaccessible is a legal and compliance issue that can get you sued.

I’ve worked on the biggest web sites on this web (yahoo.com, bing, Microsoft…) and on the Firefox and Microsoft Edge (Chromium) browser. Browser makers want one thing: not being blamed for being slow or showing things “wrong”. So we work with lots of internal and external partners to see why their products are misbehaving. This could be extension providers, framework creators or development teams. In these “performance clubs” both in Mozilla and Microsoft we kept running into the same issue: web products with tons of senseless HTML, mostly unused CSS and an absolute avalanche of JavaScript sent to the end users with no benefit to them. All the benefits were for the convenience of the developers and the flexibility to build whatever with a framework that promised optimised output.

The move to full stack development caused us to build a bloated web that loses you customers and costs you a lot of traffic that simply isn’t necessary.

There is of course another reason why our web products don’t deliver: componentisation without big picture planning.

Web products these days aren’t build as documents, sites or even includes. They are built as independent components, each flexible enough to be applicable in many different contexts. That’s grand, until people assemble them nilly-willy and as many as they want to. At times we found 20 different, highly customisable button components that did the same thing.

Here’s where a frontend developer would smell that something is amiss immediately and could trace the waste.

Frontend developers are:

• Browser performance experts
• Cross platform development experts
• Accessibility experts
• Compliance knowledgeable
• Design and Test department connected
• Fiercely dedicated to the end user

We truly are the shape shifters of the market. So to say that someone who is “just” a frontend developer isn’t flexible enough means first and foremost that most people still don’t know all the things this job requires.

The argument that CSS and client side JavaScript isn’t real coding is nonsense, too. It’s especially ironic that people who claim that also don’t want to touch CSS as it is “too hard and strange”. CSS isn’t about colours and padding any more, with grid, subgrid and flexbox it’s a fully fledged layout system. And it does animation and responsive rendering. With media and container queries you have amazing flexibility and with cascade layers you even have control over how browsers should render the current design.

It is your choice. You can hire frontend developers to build your product, or make it happen somehow and later on hire performance and accessibility consultants to fix what doesn’t work properly. Bear in mind though that the further down the production you are, the harder it will get to optimise and fix a product as you will also clash with new feature work.

When people ask me why I am “just doing frontend”, I can happily explain these things and proclaim that I am proud to be a frontend engineer.

The defence RESTs, POSTs and GETs your feedback.

Addendum: This is also applicable to all the other jobs we have in the market. A good database engineer can save you seconds of loading time, a great cloud engineer can lower your bills and a great backend engineer make sure your servers only do the job they should and not run optimisation pipelines for a huge pile of unused frontend code. And with all the big players right now trying desperately and shortsightedly to please stockholders in times of inflation by laying people off rightsizing, the market is awash with talent. And maybe you can afford three experts for the price of one 10x full stack ninja rockstar who lives in a city where 80% of their income is their rent.