【Programming】Why I Dislike Frameworks and Engines

Before starting this article, a quick announcement.
This article was supposed to be published yesterday, but I was busy porting my game engine to the Nintendo Switch.
This task took two weeks, but I got it running faster than expected.
I also tested and compiled the engine on Windows, macOS, Linux, FreeBSD, OpenBSD, NetBSD, and Haiku, confirming it works on all these OSes.
While the game itself will only be released on the Nintendo Switch and its successor, it's nice to know it works across all environments in case I decide to create a small side project for PC.
Note that this engine does not run on the PlayStation 5 because the PS5 doesn't support Vulkan at all.
My engine uses the Vulkan API.
On macOS and iOS, Vulkan is only supported through MoltenVK.

---

As I wrote in my roadmap two days ago, I don’t like using game engines or web frameworks. (Japanese-only)
Today, I'll explain why.

Abstraction is Complexity, Simplicity is Understanding

I primarily develop in C, C++, PHP, and Go.
I'm also very proficient in MIPS assembly and fairly skilled in RISC-V assembly.
Using these, I can work very productively.
However, I'm completely hopeless with JavaScript or Python, which are always touted as "beginner-friendly languages".
Similarly, I'm far more productive writing plain PHP code in Neovim than writing Symfony or Laravel code in PhpStorm.

At the company I work for, I was told to use PhpStorm because it would supposedly increase productivity.
However, it didn't work at all on my computer, so I ended up using Neovim.
On another computer, I got PhpStorm running, but the IDE kept auto-formatting my code in weird ways, automatically importing unused classes, and adding closing brackets every time I typed an opening one—basically hindering my productivity.
So, I went back to Neovim and have been using it ever since.

The reason comes down to the level of abstraction.
Many people have a religious belief that abstraction improves productivity.
In reality, abstraction hinders productivity.
It adds layers of documentation to read, steepens the learning curve, causes surprising bugs that are hard to fix, and leaves you without a way to understand what's happening.

I'm not entirely against abstraction.
The C standard library (glibc, musl, dietlibc, etc.) is a form of abstraction.
Limited abstraction reduces boilerplate and allows more work with fewer lines of code.
However, too much abstraction forces you to do more work in the end.
I often get angry about this because the current programming field is run by irresponsible jackasses who think they're advancing technology and understanding, when in reality, they're making things worse for veterans and significantly raising the barrier to entry for beginners.
Even new languages like Rust or Zig, which aim to reduce abstraction, have issues.
They aim for complete ecosystems (including package managers), which restricts your freedom to do things your way and puts you at the mercy of egomaniacs at the top who might hate you.

A Different Perspective

In software development, there are two types of programmers.
The first type sees programming as a job, writing code just to get paid, copying code from online search results, generating it with AI, heavily relying on others' dependencies, and hating their work.
The second type sees programming as an art form.
These people care deeply about writing efficient and secure code, enjoy programming in their free time as well as at work, take pleasure in writing as much code as possible themselves, and genuinely want to understand what's happening internally.
Of course, there's a third type for beginners, which is a mix of the first two.

I'm the type that sees programming as an art form, always prioritizing understanding how everything works over rapidly shipping products.
Because of this, I see abstraction as an obstacle, not a productivity tool.
However, most programmers today are the job-oriented type, so for them, abstraction is a tool, and simplicity is an obstacle.

Abstraction Isn't Always Bad

Sometimes, abstraction can be useful.
In November 2024, I started building a game engine using Vulkan that runs on Linux and OpenBSD.
However, since the games I want to make are for the Nintendo Switch and its successor, I needed to port the engine.
For Switch development, Nintendo provides VSI extensions, so you have to use Visual Studio.
During the porting process, I faced problem after problem but got it mostly working.
However, I hit errors that printf debugging couldn't easily resolve.

I hate debugging with GDB, but Visual Studio's debugger was incredibly helpful, allowing me to pinpoint the cause of the issue and fix it.
This is an example of abstraction being useful.

The Problem with Modern Development

The biggest issue with modern development is that beginners are taught to start with JavaScript or Python.
Not only that, they're guided to learn these within massive frameworks, where 80% of the code comes from dependencies written by others, and they're taught to care only about making the product work, not about what the code actually does.
This isn't teaching programming; it's a trap that locks you into a specific ecosystem.
Escaping that ecosystem is extremely difficult.

As a result, people can't understand what their code does, leading to bad code and bug-ridden software.
Since beginners today are taught this way, gaining lower-level understanding becomes very difficult.
Meanwhile, companies prefer hiring cheaper, younger developers over experienced ones.
This has normalized the mindset of using frameworks, downloading all dependencies, and not caring about how the technology works, causing software quality to decline year after year.
As a result, beginners remain at a beginner level forever because employers don't value knowledge or skills.

There are reports that Gen Z doesn't understand what files or directories are.
Many don't realize that an HTTP server simply finds and opens files on a filesystem, reads their contents, converts them for browser display, and sends them over TCP or UDP protocols.
This is extremely serious because it shows that software has reached a stage of collapse.

As baby boomers and Gen X, who built all of today's technology, retire, we're at a crossroads: do we need to drag younger generations out of their comfort zones, or will we plunge society into a dark age in the near future?
Ultimately, all the legacy systems we rely on will collapse, NPM or PIP dependencies will stop working, and a single dependency failure could bring down thousands of major products simultaneously.
This has happened before and is destined to happen again on an even larger scale.

That's all