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