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.

And that’s a wrap. I recorded my last video in the German LinkedIn Learning video course on “Browser developer tools for non-developers”. My favourite stumbling block over the course of the last few days was me starting a sentence with “Und hier verwenden Entwickler:innen…” (“…and here is where developers use…”) and making a pig’s ear out of it by saying “Und hier verenden Entwickler:innen” (“and here is where developers perish”).

I will now do some demo recordings of an English version of the course we will offer LinkedIn US, so fingers crossed that this will be taken on. I think there is a lot of good in explaining the power people have over the web we are given if they know what they can do using tools built into their browsers.

We don’t need to click through annoying, redirecting overlays or wait for download buttons to become active in a minute’s time. We also don’t need to install dozens of extensions just to download some images or be able to control or download a video.

A lot of these annoyances can be worked around using browser developer tools. Where this gets problematic is that developer tools are obviously built for developers, so they are not the most user-friendly. But I think that if you explain the basics and show people how to use them, they can be a great help.

And maybe it is a good thing to ask non-developers to give browser makers more feedback that a design-by-committee, let’s-add-another-tool-why-not approach to developer tools design isn’t the best idea to start with. I’ve tried hard to make browser developer tools more approachable the last three years and we had some successes. Now we need others to follow suit and re-think tooling.

I am currently in Graz, Austria to record a video series of “Developer tools for non-developers” for LinkedIn Learning. We had a massive ride by car down here from Berlin as my partner isn’t too hot on flying.

The city is ridiculously pretty and we arrived on first of May which is the day of work in Europe. We ended up looking for a first of May celebration and ended up stumbling on one of the communist party of Austria, which was a massive surprise until I learned that the mayor of Graz is also a member of this party.

Anyways, I am spending my days now in the recording booth and I am confident that the material will be done by the end of the week. Here’s the demo pages in English, in case you are wondering what it all will be about.

I also really appreciated the swipe-in gadget at the office:

My personal highlight so far was getting continually stuck calling “Main Tools” (Hauptwerkzeuge) “Crown dwarf witness” (Hauptzwergzeuge). I guess it is a wrap for today.