Frontend is more design than engineering

There are two sides of the frontend: design and engineering. Some people put it together under the term “frontend development”. Sound good to me.

Frontend-as-design

Frontend is tied to design more than any other part of a digital product. We can call it “fast frontend”: cheap, simple, and deliberately made with the intention to be thrown away and—in case of success—refactored, i.e., approached as an engineering problem instead.

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.

Frontend-as-engineering

The engineering part of the frontend is tough. You can see that BrowserStack presents about two thousand environments: the multiple of different platforms and browser versions. That's what we work with when we make frontend. Direct reflection of how complicated the ecosystem is are “Best viewed in Chrome” apps that emerge as a response backed by Pareto principle—and some stay in that category forever.

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 is defensive, slow, and done with the big game in mind. It's very common for an engineer to object against a change that is too local, because local changes pile up over time and depress a carefully developed system.

The difficult part for any frontend engineer is to maintain broad area of impact: think about JIT optimizations, but also think outside the database.1 To make a web page accessible and SEO-friendly but also fit into performance budget.

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, one becoming more popular and the other less hyped, and so transpiling sources for web browsers isn't a new thing. But this is a great leverage and I think it has given confidence to people who wrote their frontend code in languages other than Javascript.2

Javascript has grown up to be one that runs on many platforms, sometimes quite different from browser environment.3 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.

Frontend as an experiment

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). CodeSandbox4 is a fantastic tool that provides a whole development environment in browser5 so you don't have to think about the tooling.

Frontend as a system

This section is in progress


  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. Sure Elm is awesome, but have you written CoffeeScript?

  3. 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.

  4. 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.

  5. 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.