root / weblog / bloatware-to-syscalls
In defense of starting with bloatware: my learning journey from Next.js to syscalls
---
Modern software is slow, buggy, bloated and fragile.
Modern software comes with complex build systems and absurd chains of dependencies. [1]
Modern software scales up but overcomplicates how to do simple things.
Still where performance is critical good software gets written as low-level and efficient as needed: see GPU-accelerated ML libraries, llama.cpp, WASM.
So maybe software is only bloated where their optimization is not critical or perceived by average user.
Modern devices are fast enough that the average person doesn't notice the load time of heavy JS. When something breaks you refresh the page and it works as if nothing happened.
Nerds like us may be the only people who notice and care about load time.
We do are taking the joy out of software development by making the software development experience just an act of gluing existing pieces together. [2]
The thing is: writing simple software is harder than writing bloated one.
People who just learned how to code in Python and are building their first web apps in Next.js (or the given framework of the day), may not even be aware or have the taste and understanding necessary to see the difference.
Framerowks and bloatware, as well as vibe coding tools recently, make software development more accessible to non-experts: they can be the missing/hidden "introductions to programming" sometimes.
Don't get me wrong, there's nothing inherently good about the frameworks and the bloatware. The important piece here is 'making sofware development more accessible to beginners', and frameworks just happen to be the thing that worked for me in the past.
Making software development accessible can turn what starts as mere curiosity about 'building products' into a subsequent curiosity about how they actually work. It can spark interest in people who might not have been drawn to hacking initially, effectively tricking people into getting curious about learning how to actually code.
Today, with AI coding tools, there can even exist an equivalent path that doesn't cross frameworks at all. Though, there’s no shortage of Replit and other similar solutions to spoil the party. (I’d argue that Claude Code and other lightweight tools are more than enough even for non-programmers, and that things like Lovable, Replit, etc., introduce even more complexity, unnecessary layers, and more lock-in than needed, but that’s a discussion for another time.)
In the age of the home computers, which produced many of the greatest programmers in history, people used to learn to code in low level languages using raw CPU instructions and manipulating raw memory bytes.
I am too young, I didn't see this with my own eyes, so some of these will just be assumptions. Correct me if you were there.
There wasn't much technology around so seeing a machine do math on its own via a display was as cutting edge as it got.
You felt like you were building the coolest thing possible at the time.
Today we live in a world abundant of apps, websites, social media and all kinds of applications.
Learning C or Assembly as a first programming language can feel distant from building the real world applications to students who are just learning how to code out of the excitement of building systems and apps like the ones they use everyday.
The students may ask themselves "How the heck do we go from pointer arithmetic to building apps?".
Worse of all they may not see how the dots connect and lose interest.
I learned to code in Python, and started building end to end applications using React and Node.js via the Next.js framework, deploying on Vercel.
Even while learning Python, I didn't really see how the heck would I get from computing fibonacci recursively to building real-world applications.
Eventually I got from 0 to building full-stack applications via Next.js (Frontend, Backend), Vercel, Supabase (Database, Authentication), without really understanding the implementation details of anything, without really seeing how bloated everything was. The apps still worked! I felt like I could build anything, I felt like I had finally cracked the code, literally.
Soon the inherent human curiosity kicked in. I started digging deeper into the implementation details. I wasn't happy with just taking Next.js and Supabase for granted. I wanted to understand how everything actually worked.
I started building things from scratch, consider every dependency debt. I started seeing the vendor lock-in mechanisms and developed the ability to stay away from that.
Now all marketing headlines turn me off and hacker news is the only place on the internet I can get through without being disgusted. But those marketing headlines are what got me into the rabbit hole, and I will never deny that. The simplicity of Python and effectiveness of the Next.js/Vercel/Supabase stack are the best thing that could've happened to me.
I used to think C and Assembly were boring. I thought computer architecture and learning assembly would be the most boring part of my bachelor's degree. I wanted to build the real-world applications.
On the "Next.js to syscalls" promise of the title: I recently rewrote my website/blog/public bookmarks page from being a Next.js project full of hrefs to Notion pages to my own lightweight solution. [3] Among other things, I wasn't scared to use kqueue [4] to implement a live preview feature.
Now I think quite the opposite, I'm very grateful to have gotten here, and I will never deny the path that led me here.
Accessibility to coding empowers people and spark curiosity. Things may get bloated until they get beautiful. At a personal level as much as at a societal level.
Human curiosity is unstoppable, no bloated framework can ever change this.
---
[1]: We are destroying software | Hacker News
[3]: prev.py
[4]: kqueue