Why frontend is hard

Frontend as an industry has been putting the entry threshold lower and lower over the last couple years, yet it is really hard to find a frontend engineer that would display a set of skills and behavioral traits that would suit needs of an average product engineering team. Lamenting isn't helping though. I'm curious what makes this corner of the industry look the way it looks.

I'm not going into the terminology here. It's a completely different topic what makes a frontend engineer different from a frontend developer. At some point it gets so hard to distinguish between them, so I'll use “frontend engineer” as an umbrella term here.

A more interesting scale to put frontend skills on is problem-solving skills scale. Frontend engineers do stuff within a broad range of topics, covering a very long chunk of product development process. In full-cycle, full-stack teams, they are expected to be involved as early as design, and as late as distribution.

Here, I'm trying to look at frontend as design vs. as engineering, and fast vs. slow frontend.

Frontend is for humans, therefore hard

Frontend is tied to design more than any other part of a digital product. This is what the users interact with. Users are mostly humans, and humans are so hard to predict or please. Unlike an API, you can't expect humans to be super chill about whatever happens and to statelessly respond to it or tirelessly retry stuff. That's due to the nature of humans: they don't exist to use a service or an app. Products need to accommodate to humans' needs.

Frontend engineering takes into consideration who the user is. Compared to, say, backend engineering, it takes different skills to do the job. One of these skills is design. A frontend engineer has to be able to talk to designers and understand what they say when they talk back. What might be irrelevant for one, is a necessity for the other.

Frontend is hard not because it has to manage data correctly but because it has to present the data differently. It takes thinking outside the database1 to inform the design process and bring it further into the engineering phase. This is pretty much a skill that each frontend engineer needs in their daily work.

Fast frontend

Frontend is sometimes done in a way that is optimized for being thrown away. Think “fast frontend”: cheap and simple. If successful, it usually gets reengineered in a deliberate, long-lasting way. If not, just throw it away, no hard feelings. Because it was done cheap, because it was specifically done to be an experiment, we win regardless of the outcome, but we only win if we can move on quickly afterwards.

In his book Sprint, Jake Knapp makes a very important statement: solve the surface first. The surface of any solution is only a tip of the iceberg: significantly smaller than the whole thing and is seen first thing by the user. And frontend is the surface of a product! So we can think of fast frontend as the implementation step of the design phase, unless we're going really raw and smash some Airtable with some Intercom and create a truly minimal ready-made product.

This is a skill a frontend engineer can train. Brad Frost calls this “frontend design”. I see it as a role an engineer takes on for short period of time, on a regular basis.

The two tools that I believe picked up the essence of creating fast prototypes are Codepen and CodeSandbox. Codepen's power is in its simplicity (and the network, although sometimes rather dribbblesque). CodeSandbox2 is a fantastic tool that provides a whole development environment in browser3 so you don't have to think about the tooling. It's almost impossible to meet a frontend engineer who has never used either of the two, and so it has become a baseline requirement to consistently present ideas in form of demos.

Frontend engineered right

The engineering part of the frontend is tough. You can see that BrowserStack presents about two thousand environments which are combinations of different platforms and browsers and their versions. That's what almost every frontend engineer works with.4

When I think of engineering, I definitely think full-blown source code quality control, a team of engineers, a dozen pull-requests a day and a good test suite. The main objective of engineering is to ship features, but the primary criterion of success is not getting stuff broken. Engineering in its purest form is defensive: the best code is no code, the best change is no change. This is good for users because they can continue using a product, but also inhibits product development because gradually smaller features are shipped over big, bold bets.

This is by far the most common quality in frontend engineers, probably because it's closest to CS domain and is easily cultivated even in small teams. Comparing to other disciplines, I actually see disproportionately few frontend candidates who display sufficient amount of frontend-as-engineering skills. It's hard to understand why exactly this happens, but low ratio of frontend engineers globally who consistently apply strict engineering practices to frontend is probably what contributes to the picture of a frontend engineer as a person who just smashes bits of jQuery code together to paint stuff in the browser.

Recent emergence (or a comeback?) of the build step is a huge improvement for teamwork and for engineering discipline. Webpack and Grunt have been around since 2012, and people who wrote their frontend code in languages other than Javascript5 are not curious neophytes, but it's now more feasible to write frontend code in one of many languages, not the language, and this diversity in tools surely has to have positive effect on frontend engineering as a discipline.

Frontend also has to perform. JIT optimizations, but also To make a web page accessible but also fit into performance budget.

Javascript has grown up to be one that runs on many platforms, sometimes quite different from browser environment.6 This is absolutely fantastic, in terms of the entry threshold, how many people are now able to begin making things in the digital space. The community of makers got its big bang. The discipline of writing Javascript code has graduated from giggling at WAT remarks to actually appreciating the flexibility and universality of the language.


  1. “Think outside the database” is one of many tips in fantastic collection of web frontend tips “Refactoring UI” produced and maintained by Steve Shoger.

  2. About a year before this post was written, in 2017, CodeSandbox and Codepen looked very much alike. Codepen just shipped their Projects feature for Pro users, and similarities were many. Author believes both Codepen and CodeSandbox are valuable for the global frontend community, and while there might be some clash for the market share, it is not visible at all. In addition, Ives van Hoorne, creator of CodeSandbox, noted that copying Codepen wasn't the goal at all, and wrote an overview of CodeSandbox features.

  3. In the early days of cloud IDEs, there were two that, author believes, blazed the trail for what would come afterwards: Cloud9 and Codebox. The former was independent until mid-2017, when it was acquired by Amazon, and the latter is no longer active. Author believes that both products were way ahead of their time, doing great job at transforming the fast frontend engineering culture nevertheless.

  4. After Microsoft Edge team declared that they no longer want to maintain their own browser engine, “Best viewed in Chrome” browser monoculture is slowly emerging—again. People have been worrying in the past and have been worrying recently about the browser engines taking over one another.

  5. Sure Elm is awesome, but have you written CoffeeScript?

  6. Javascript runs on Arduino and Pebble, and while many software engineers point at a range of issues the language has, from the lack of type safety to how slow and battery-unfriendly it is, it definitely has lowered the entry threshold for programmers and pushed the industry forward.