The Platform
The core languages of the web browser are HTML, CSS and JavaScript: These are the “fundamental” languages that every developer learns before they specialise in a particular set of languages or frameworks. There’s a committee of people who decide what new features get added to these languages, and then those features get added to web browsers like Chrome, Safari and Edge. This is what we call “The Platform”.
In the past, The Platform was not very suited to building really smooth, fast software. So people built frameworks and tooling to do what The Platform couldn’t, and layered them on top of The Platform.
The History of Frameworks, Tooling and Complexity
There is a cycle that happens every 5 to 10 years, where a particular set of Frameworks and Tooling will get extremely popular within the industry and gain widespread adoption. They’ll become mandatory skills and start to appear on every job spec and CV. At some point, these capabilities will get added to The Platform, and the frameworks and tooling will die out.
Despite this trend happening repeatedly, the incentives in the industry are such that the cycles continue. New frameworks and tooling mean ✨new skills✨ that developers can use to show that they are growing and improving their capabilities. And because the internet is still growing, the experience level of the average software developer is still comparatively low (less than 5 years) when compared with the length of these trend cycles.
Complexity Budgeting
In 2024, there are still things that The Platform doesn't support, so there are still requirements for some frameworks and tooling. The challenge is ensuring that the complexity level of your overall code base remains reasonable. “Complexity Management” is, in my opinion, the most neglected part of modern software development, and one of the biggest contributors to ballooning tech costs and low quality software.
Some of the considerations when adding new frameworks and tooling.
- As mentioned, you are adding complexity to your codebase. In software, complexity compounds.
- Most of the time, you are reducing the debuggability of your codebase and software (how easy it is to find, diagnose and fix things when they go wrong).
- All of the time, you are increasing the learning burden of adding new team members and substantially narrowing your hiring pool.
- Most of the time, you are increasing the experience level required of new joiners - i.e the level of complexity in the codebase necessitates hiring people with at least X years of experience.
I have written reasonably extensively about my approach to managing complexity, whilst also being able to build really nice software. You can read more about it on