Handmade Software
Dec. 5, 2021
The web as a platform in 2021 is amazing. Web browsers have native support for everything from notifications, location, history, virtual and augmented reality, device orientation, graphics, local and session storage, networking, web assembly, and more. JavaScript has reached peak levels of popularity and native browser support is strong for most of the language features. CSS has flex, grid, animations, and image filters. HTML has many new semantic tags and support for writing custom tags through web components.
It has been over 10 years since mobile responsiveness came into the web zeitgeist and today over half of all web traffic is mobile. Despite this and all the tools at our disposal, I don't have to look far to see crappy web responsiveness, lack of focus or attention to support on popular browsers, and intentionally self-sabotaging mobile web experiences to push mobile apps that should be classified as spyware. These experiences often come from hugely popular software companies; small businesses tend to use web building tools that actually support mobile pretty nicely.
Additionally, we argue over and jump between large opinionated frameworks. We debate over implementations of reactivity, jsx, packaging, and routing and insist that the corner we've found ourselves in is the right one: the wheel; the thing that should not be reinvented. While we focus on these arguments over the act of web development in general we can lose sight of the products we build.
At some point I started to feel a deep dissatisfaction with the web products I frequently interact with as well as the interactions with the web community. This was happening despite also believing in the web as a platform and seeing its strength. Around this time I discovered a community of software developers that have had a big impact in the way I write and approach software. The community is the Handmade Network and they introduced me to the concept of handmade software.
Handmade history
In 2014 Casey Muratori, a veteran game developer, started a series on YouTube about creating a game from scratch without the use of third party game engines, libraries, or SDKs that weren't provided by the operating system the game was running on. That series is called Handmade Hero and continues to today. As the series progressed Casey shared bits of wisdom about his experience writing software and expressed his frustration with a lot of the software he worked with. He gained a bit of a following and a few years ago a community began to form around taking the approach of writing software "from scratch" or "by hand" without the use of high-level frameworks and with a deeper understanding of what computers are actually doing with the code we write.
What is handmade software?
It's difficult to define. It's not about using any programming language or framework, but it's a state of mind in thinking about the products we build and an emphasis on quality and performance. It's questioning the status quo and focusing on the end-product first. The community questions every assumption we take for granted from applications, libraries, operating systems, even programming languages and software development methodologies. They outline this in their manifesto.
The handmade community hosts conferences and events such as The Wheel Reinvention Jam to discuss and explore building better software. There's a dissatisfaction with the current state of software we have today when our computers are capable of billions of operations per second and a sentiment that we developers are squandering that by ignoring that all of our code ultimately runs on real computers. Understanding a little about that hardware can go a long way.
It's not difficult to find critics online about the Handmade Network and the idea of writing software without using popular frameworks. Often users point to some large problems solved by these frameworks or accuse the community of oversimplifying certain problems. Most often critics accuse the community of reinventing the wheel; a criticism the community affirms that they are actually doing.
Why reinvent the wheel?
There's a fundamental assumption that the wheel is perfect. It's something that has already been invented, optimized, and perfected to fit its need and any attempt to redesign or re-approach the problem is only going to yield a lower-quality result. Even following this analogy, it breaks down really quickly when you look around in the real world and realize we have a variety of different wheels from cars, bicycles, gears, fans, spindles, bearings, etc. These are all specialized wheels that focused on solving a specific problem. The wheel just aims to solve a generic use-case. Many of these use-cases could have used a wagon-wheel to operate, and it could kinda work. It would spin like a wheel, but it would become useless pretty quickly.
Leaving the abstract analogy aside and returning to the world of software we see a variety of frameworks, languages, methodologies, libraries, and applications. We developers constantly fight online and write blog posts about which one is the wheel. We're quick to jump to the next framework or insist that we chose the right one for our use-case. Frameworks exist to solve generic problems, but rarely we face generic products that fit nicely into those generic solutions. If you've ever worked with a framework and knew how to solve a specific problem, but were faced with solving it the idiomatic way for the framework you were using you probably should have asked if you really have the right wheel.
What does this mean as a web developer?
First, there's a lot of criticism about the web in general, especially within the Handmade community, but the web is the most efficient way to deploy software to users. There's virtually no barrier to getting someone to click a link and install your website or web application on their computer or mobile device regardless of their operating system. That is hugely powerful and cannot be ignored.
I don't want to prescribe any one approach or solution here. I'm not going to say don't use any frameworks and write everything from scratch, but I'm also going to warn against reaching for a npm package every time you need a quick solution to something. Pulling in any popular web framework immediately introduces hundreds or thousands of dependencies to your project and makes your project shaped like a React wheel, Angular wheel, or Vue wheel. There's still value in that from time to time; some frameworks let you build once and run anywhere and even just the idea that developers can join your project mostly knowing where things are located and get up to speed quickly has value.
I want us to make these decisions consciously and not fall into the default of being a "framework" developer. In our personal lives we hire professionals based on the service they provide, not the tools they use. How silly would it be if lawyers or accountants sold their services based on using MS Office Suite or Quickbooks? In software, we should be proud of building products, not using frameworks.
Where do we go from here?
The end product needs to matter a lot. Being able to add features quickly also matters, but that must be in close competition with the product and not take precedence. For example: respect your user's mobile data and don't have them download megabytes of files just to visit your site. Respect their experience and don't have them wait multiple seconds to get some feedback from clicking a button. Respect their time and show them a responsive experience on their platform and never intentionally hurt their experience to cross-sell. If you have a premium service or premium payment tiers, offer premium features.
Be cognizant of performance and quality considerations for decisions you make as a programmer. Do some research on the next dependency you pull into your project or consider how long it would really take you to write a specific solution for yourself first and realize that you will have something handmade for your product if you do. Often you can find simpler libraries that give you more flexibility and control while not being hugely opinionated about how you build your product or service. There are also many libraries (many of which built by the handmade community) that offer a specific library of solutions with minimal or no heavy dependencies.
I'd also recommend joining the Handmade Network or at least seeing what they have going on.