Forem: Shaquille Niekerk

Comms Under Fire - Update 01

Shaquille Niekerk — Fri, 16 Jan 2026 13:27:50 +0000

This is a major update that I've done on my game.
From a shift in the overall purpose of the game, to the mechanics, down to how things look. Below I will go over everything that I've done and try and explain why I've done it.

Purpose

Originally I wanted to create a web demo of a game I've wanted to create for PC, a game where you're in the drivers seat of a propaganda machine, and the middle man between soldiers on the ground and the powers that decide the fate of the nation. Oh, and this takes place during a war...
Once I created the demo I realised that the tools I had to create this proved to be more difficult, so I stripped back on some functionalities and in doing so I realised I was working toward a different idea. a classic competitive typing game.
This will have leader boards, with those who have the highest WPM sitting at the top, challenge modes where you can challenge other users to see who types the fastest, and a story mode, if you just want to improve in a relatively stress free mode, while getting the gist of what the story would be in this world.

Mechanics

The mechanics have not changed that much, the major change is that I am trying to remove any mouse input. Having the main element of the game be controlled solely by keyboard inputs.

Looks

Originally I had two monitors on screen. One that displayed the text you needed to type, and the other displaying the text that you were typing.
This approach brought a few issues. Firstly people kept getting lost where they were in the text because they had to move their eyes between two monitors. The fix for this was to show a cursor of where you were as you typed, but this just made people only focus on that one monitor, making the two monitor approach seem redundant... Now I think I will still keep the two monitor approach for the main game I plan on creating, but for now one monitor seems to do the job just fine.

Update 01

So here we are with the first update.
A whole new game mode, from a story driven typing game to a ranked typing game. A whole new look, from a two monitor setup to a single monitor setup that can be controlled entirely with the keyboard.

For Update 01 I've only included the story mode. But rest assured that I am working on many updates to get this thing having all game modes I've mentioned, and any new ones that come to mind as I go.

Thank you for reading,
And please check out the game here.
And leave a comment on what you think, or let me know if you have any issues

How One Game Made Me a Gamer Again

Shaquille Niekerk — Tue, 13 Jan 2026 14:56:04 +0000

Lately, games have started to feel less like an escape and more like a chore.

Every new release seems to come with a trade-off. Battle passes, cosmetic shops, seasonal content, daily logins. The message feels clear: the more money you spend and the more time you sink, the more fun you’re allowed to have. Microtransactions are “optional,” of course. Just like breathing.

I started wondering if the problem was me.

Maybe I’ve just lost the patience to really get into games. Maybe adulthood hollowed out that part of my brain. I’d watch reviews where someone confidently stamped an “8/10” on a game, boot it up myself, and immediately feel like I’d played it already. Same mechanics, different coat of paint. Or worse, a game that felt unfinished unless I paid to fill in the gaps.

Then, almost by accident, I played Dispatch.

For those who don’t know it, you’re in charge of a superhero group, managing crises and sending heroes out to fight crime. No endless progression systems. No dangling carrots. Just a focused idea, executed well.

I finished it in one sitting. And immediately wanted to replay it to see the other outcomes.

That hasn’t happened to me in years. I still haven’t finished The Sims 2, and I started that around 2007.

That experience made me pause. Maybe I wasn’t burnt out on games. Maybe I was just burnt out on the kinds of games I’d been choosing.

So I tested that idea.

Instead of relying on reviews and scores, I went back to how I picked what game I play back in the day, so I started watching trailers and forming my own opinion about whether a game actually looked fun to me. Not “content-rich” not “worth the grind” just fun.

That’s how I landed on High on Life.

On my first play, I went for four uninterrupted hours.

That might not sound impressive, but for me, that’s huge. Four hours without checking the time. Four hours without feeling guilty. Four hours without that nagging sense that I should be doing something more “productive.”

And when I stopped playing, I didn’t feel like I’d wasted my time.

So now I’m left with a burning question.

Is it just me, or have a lot of modern games become either souls like pits that require time and dedication just to master one move, or carefully engineered money machines designed to drip-feed dopamine? Games that don’t respect your time unless you give them your wallet too?

So great games are still out there, and I’ve just been looking in all the wrong places.

What game(s) have you been playing lately that was just an absolute blast?

My PC melted while making this game...

Shaquille Niekerk — Thu, 11 Dec 2025 14:57:37 +0000

So I've been watching a lot of MoistCr1TiKaL Gaming and Jacksepticeye videos lately. And I've seen these guys play some games that look like a student project. And as someone who has always wanted to get into the Game Dev space, but never found that golden idea or hasn't found a team to work with, I finally decided to give it a go myself... This was after watching the Potrick Snap
video that I just thought, "Hey if this horror Spongebob game can get some love, I'm sure I can create something that someone will enjoy too."

Well, fast forward a few days and I have everything set up. My game idea: a typing game that takes place during a war between two nations where your job is to relay comms between the frontline and HQ. And every now and then hack into the enemy’s comms and extract classified data. It's all time-based and you've got to be quick with your fingers. And I've downloaded Unity and bought some assets off the asset store. I haven't really used Unity before, but I was willing to learn. And one of the rules I set out for my game was that it would take place in one location, so it wouldn't be a high curve to get this thing started.

Okay, so I've got my game idea, I've got Unity, and I've got my assets to build this world out. Well, here's where the issue comes in... I load this asset into Unity, which on a blank slate is already running at a snail's pace, but it all comes together when I load up the assets. Complete meltdown, everything comes to a halt and I cannot provide any inputs. This is when I realised maybe my PC needs retirement...

Well, I still want to make this game. Do something. So I do the only thing I know what to do... a Web App. Sure, it'll only be a static screen for now, and I can't implement most of the features I had in mind for this game. But hey, it's better than nothing. And while I build up the funds to upgrade my PC, maybe this will get some eyes on the game. Build an audience, hopefully. And let me play around with some ideas I had for the game.

Anyway, here is a link to a Work-In-Progress version 0 of the game titled Comms Under Fire.

Hope you enjoy, and please feel free to let me know what you think.
And note, I will be playing around with things, so apologies if you open it up and it's just a dumpster fire.

My First game - Comms Under Fire

Shaquille Niekerk — Thu, 11 Dec 2025 14:57:28 +0000

A game set in an alternate world where two nations are locked in a brutal war. You’ve been assigned to man the comms, where you’ll find yourself drafting Propaganda to keep your fellow citizens calm, hacking into enemy communication channels to leak sensitive state secrets, and planting destabilizing messages to push the enemy’s civilians into panic.

All of this while staying alive during active invasions, relaying time-sensitive comms from the frontline to HQ, and doing whatever it takes to help win this war.

The Comms Under Fire mini-demo has just gone live, and you can play-test it right now. It’s the tiniest snippet of the full idea — a small taste of what the final game will become. I’ll be releasing the full version on Steam once I’ve got the proper tools to build it out.

For now, enjoy the free online mini-demo. Updates will be rolling in, so keep an eye out!

Authentication & Security: Keeping Bad Guys Out Without Annoying Users

Shaquille Niekerk — Mon, 20 Oct 2025 00:53:40 +0000

Hey folks, welcome back to another episode of The Stack Unpacked. I’m Shaq-Attack, your friendly neighborhood developer, still trying not to lock myself out of my own Gmail.

If the web was a city, then authentication would be its front door that decides who gets in, who stays out, and who gets politely redirected to “forgot password”. It’s something we deal with in almost every app we build yet somehow it always feels slightly broken.

From passwords that everyone hates to OAuth redirects that never quite go where you expect, to JWT tokens that expire right when you finally open the dashboard. Authentication is one of those areas where complexity hides in plain sight.

And yet, we rely on it completely. Without it every system would be wide open to chaos. With too much of it users give up before even signing in.

This post is about finding that balance, the fine line between keeping bad guys out and keeping users sane.
We’ll explore where authentication came from, why it evolved the way it did, and how we got from shared passwords on Databases to OAuth flows that make you question your career choices.

By the end you’ll have a better grasp of how authentication actually works, why security often feels like an unsolvable puzzle, and maybe just maybe, a little more appreciation for those tiny login forms we take for granted.

So unlock your screen, grab a coffee, and let’s step through the front door... carefully.

Excellent — here’s Chunk 1, written in the same narrative rhythm as your previous Stack Unpacked episodes. It’s clear, researched, and flows like you’re walking the reader through your findings, not lecturing them.

Passwords: Humanity’s Oldest Security Bug

Before OAuth tokens and biometric logins there was the humble password, humanity’s oldest and most recycled security measure.

The idea is simple just prove you are who you say you are by knowing something only you should know. It’s the same principle as a secret handshake, just with fewer handshakes and more “forgot password” emails.

Passwords have been around since the early days of computing. Back in the 1960s, mainframe systems at places like MIT used shared terminals. Each user had a password to keep their files private. The problem though was that those passwords were stored in plain text which meant if you could read the system logs, you could read everyone’s password too.

Not much has changed. We’ve just gotten better at hiding our mistakes behind encryption.

Despite endless frustration passwords persist because they’re easy to implement, require no extra hardware, and work almost anywhere. The problem isn’t that passwords don’t work, it’s that people do.

Humans reuse them, forget them, write them on sticky notes, or pick ones that could be guessed by anyone with basic context and two brain cells.
Studies have shown that “123456” and “password” are still among the most common credentials in the wild, even in 2025.

Developers have tried to make them safer through password strength requirements, but those often backfire. A user faced with “Must contain one uppercase, one number, one special symbol, and a haiku” usually just adds an exclamation mark at the end of their old password and calls it a day.

Under the hood, though password handling has improved.
Modern systems don’t store raw passwords anymore, or at least they shouldn’t. Instead, they hash them using one-way cryptographic algorithms.

Hashing transforms a password into a long string of gibberish. Even if someone steals the database they shouldn’t be able to reverse the process.
To make things safer developers add a salt which is a random string attached to each password before hashing so that even identical passwords result in different hashes.

Algorithms like bcrypt, scrypt, and Argon2 are commonly used because they’re intentionally slow, making brute-force attacks impractical. It’s a small but powerful defense against the reality that not everyone picks strong passwords.

But even with hashing and salting, the password model has its limits.
If an attacker tricks a user into revealing their credentials (say, through phishing) all that backend protection becomes irrelevant.

And on the other end of the spectrum users are so fatigued by logins and password resets that security often loses to convenience. That’s why newer systems are shifting toward passwordless authentication like using email links, phone codes, or biometrics.

Tokens, Sessions, and the Rise of Stateless Login

If passwords are about proving who you are, sessions and tokens are about remembering that proof without forcing you to log in every five minutes.

In the early days of web applications, authentication worked through sessions. When you logged in, the server created a little record in its memory saying, “Yep, this person’s legit” and handed you a session ID in the form of a tiny string stored in your browser as a cookie. Every time you made a new request that cookie tagged along, reminding the server who you were.

It worked beautifully, until the web stopped being simple.

As applications grew and servers multiplied, this session-based model started to crack. Imagine millions of users logging in, each with their own active session stored in memory. Then imagine trying to scale that across multiple servers without losing track of anyone.

The web had outgrown its one-server mindset. It needed a way to remember users without depending on a single machine’s memory.

Enter tokens they're small, self-contained chunks of information that could prove identity without requiring the server to remember anything at all.

The most famous of these tokens is the JWT, or JSON Web Token. Think of a JWT as a digital ID card. It contains a payload (like your user ID and permissions) and a signature that verifies it hasn’t been tampered with.

A JWT has three parts:

Header: tells you the algorithm used for signing.
Payload: carries the user data (usually in JSON format).
Signature: ensures the token wasn’t modified.

When you log in, the server generates this token and signs it with a secret key. From then on each time you make a request, you just include the token instead of relying on a stored session.
If the signature checks out, the server trusts you no memory required.

It’s a clever system, and it scales beautifully in distributed environments.

JWTs solve a lot of problems, they’re stateless, portable, and easy to use across multiple servers or microservices. But, like most “clever” ideas in software, they come with trade-offs.

Because tokens are self-contained once issued, they can’t be easily revoked. If a user logs out or a token leaks, that token might remain valid until it expires. You can reduce the risk by making tokens short-lived and issuing refresh tokens, but the complexity grows fast.

There’s also the matter of size, JWTs carry data and if they’re passed in every request, they can start to bloat network traffic. Storing them incorrectly (like in localStorage) can also make them targets for attacks.

So while tokens fixed the scaling problem, they introduced new ones: revocation, security, and management overhead.

In practice, modern apps often use a hybrid approach short-lived tokens with backend session validation, or JWTs combined with secure cookies.
It’s not as elegant as the theoretical models promise, but it’s what works in the real world.

The evolution from sessions to tokens wasn’t about finding perfection, it was about finding something that could survive in the chaos of modern, distributed architecture.
Excellent — here’s Chunk 3: OAuth — Delegated Trust and the Endless Redirects, continuing the clear, research-based tone of your series, with subtle humor to keep it engaging but never over the top.

OAuth: Delegated Trust and the Endless Redirects

At some point, developers collectively realized that managing passwords for every single app on the internet wasn’t just tedious it was dangerous. People were reusing passwords across sites, companies were getting hacked, and every “Sign up” button felt like another invitation to identity theft.

That’s when OAuth stepped in but not to replace passwords and rahter to make them someone else’s problem.

OAuth short for Open Authorization was designed to let users give one application permission to act on their behalf in another without ever sharing their password directly. In other words, it’s how you can log into a random website using your Google account without Google having to hand over your credentials.

The key concept behind OAuth is delegation of access.
Instead of saying, “Here’s my username and password, please behave” you’re saying “I’m giving you a temporary key that lets you access only what’s necessary”

The flow usually looks something like this:

You click “Log in with Google.”
You get redirected to Google, where you log in securely.
Google asks if you’re okay with giving the other app certain permissions (like your email address).
If you agree, Google sends the app a special authorization code which it can exchange for an access token.

The app uses that token to prove it has permission not to log in as you directly, but to act on your behalf in limited ways.

While OAuth handles authorization, it doesn’t handle authentication. That’s where OpenID Connect (OIDC) comes in. It’s a thin layer built on top of OAuth 2.0 that adds identity to confirm who the user is, not just what they’re allowed to do.

In simpler terms:

OAuth says, “This app can act on your behalf”
OpenID Connect says, “This app knows who you are”

That’s why most modern “Sign in with Google” buttons actually use both OAuth for permission and OIDC for authentication.

OAuth became the backbone of modern web authentication because it solved a critical trust issue... it allowed users to connect services securely without handing over their keys.
Here’s the Outro — The Art of Trust, written to wrap up the episode in your trademark Stack Unpacked voice: insightful, clean, and slightly witty without overdoing it. It ties everything together — from passwords to OAuth — and closes with a meaningful call to action.

The Art of Trust

When it comes down to it, authentication is really about trust not just between a user and a system, but between people and the technology that guards their information.

We’ve seen how passwords became the web’s first gatekeepers, how tokens helped scale identity across the cloud, and how OAuth turned “sign in” into an act of delegated permission. Each one tried to solve the same problem from a different angle proving identity without losing sanity.

And yet, despite decades of progress authentication still feels like a compromise. Every solution fixes something and breaks something else.
Passwords are simple but insecure.
Tokens are efficient but fragile.
OAuth is powerful but complicated.

Security isn’t a final product, it’s a moving target. The real goal isn’t to build a perfect wall but to build a smarter one, one that learns and adapts without exhausting the people who use it.

As developers our job isn’t just to lock things down, it’s to design systems that feel safe and usable.
Audit your app’s login flow.
Check your password storage.
Add MFA if you haven’t already.
Because security doesn’t start with policies or frameworks it starts with the choices you make right now, in your code.

“Security isn’t about keeping everyone out — it’s about letting the right people in, without making them wish they’d stayed out.”

Containers Made Simple: No more ‘It Works on My Machine’

Shaquille Niekerk — Thu, 09 Oct 2025 12:25:23 +0000

Hey there, welcome! I’m Shaq-Attack, a developer who firmly believes that “it works on my machine” should never be anyone’s famous last words. Today we’re diving into the magical world of containers like Docker, Kubernetes, and why every dev seems to be talking about them like they’re the eighth wonder of the software world.

If you have ever asked yourself “When should I containerize my app?” or “Why even bother with containers at all?” you are in the right place. Let’s grab our digital toolbox and take a look under the hood to see what containers can actually do.

Why Containerization Exists

Containers were not invented simply for fun they were born out of necessity.

If you have ever built an application that ran perfectly on your laptop but failed spectacularly on someone else’s machine, you have encountered environment drift. This is caused by tiny differences in operating systems, dependency versions, missing packages, or conflicting ports. These small issues can turn a perfectly working project into a troubleshooting nightmare.

Containerization solves this problem by packaging everything your application needs like code, libraries, runtimes, and configuration files into a portable box called a container image.
You can run that image anywhere and it will behave exactly the same way.

Docker: The household name

Containers existed before Docker, but they were complicated and mostly the domain of experienced system administrators. Then Docker came along in 2013 and asked: “What if containerization could be easy enough for every developer to use?”

Docker takes your application and all its dependencies and packages them into a single, portable image. You can run this image anywhere, on your own laptop, a coworker’s computer, or a production server in the cloud.

A simple Node.js Dockerfile might look like this:

FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install
CMD ["npm", "start"]

When you run docker build ., Docker follows the recipe and creates an image or a snapshot of your application’s environment frozen in time. Running docker run starts a live instance of that image in an isolated container.

Docker makes onboarding new developers fast, ensures consistency across CI/CD pipelines, and simplifies rollbacks. However, Docker is focused on managing containers on a single machine. Once your application grows to hundreds of containers across multiple servers you will need something more powerful.

Kubernetes: Managing Containers at Scale

Docker solved one major problem, it made running your application anywhere easy. But what happens when your application grows?

Imagine starting with a single container then adding another for a database, another for caching, and another for an API gateway. Suddenly, you have a mini container city running and something is bound to go wrong.

Enter Kubernetes, the ultimate container orchestrator. Originally built by Google and released as open source in 2014, Kubernetes automatically manages complex containerized systems. It schedules containers to run where there is available capacity, balances load to prevent servers from being overwhelmed, restarts failed containers, scales applications up or down, and rolls out updates safely.

Here are the key components to know:

Pod: The smallest deployable unit, usually containing one or more containers.
Node: A machine, physical or virtual, that runs pods.
Cluster: A collection of nodes managed by Kubernetes.
Deployment: Rules specifying how many pods you want running and how to update them.
Service: Ensures traffic reaches the correct pods, even as containers restart or move.

Think of it this way Docker gives you shipping containers, while Kubernetes acts as a global logistics system, tracking every container, knowing where it should go and rerouting when necessary.

Where Containerization Fits

Now that we understand Docker and Kubernetes, the next question is: where does containerization make sense?

The short answer is almost anywhere modern applications live. The longer answer depends on your project’s size, your team, and your goals.

Local Development: Developers often first encounter Docker here. You can spin up the exact production environment on your laptop, including databases and APIs, with a single command. No more environment setup headaches.
Cloud Deployments: Containers shine in the cloud. Managed services like AWS ECS, Google GKE, and Azure AKS allow you to deploy and scale applications efficiently.
Microservices: If your application is made up of multiple smaller services, containers allow each service to run in its own isolated environment. Your frontend can run in Node.js, your backend in Go, and your analytics in Python, all without dependency conflicts.
CI/CD Pipelines: Containers make testing, building, and deploying code predictable and fast, ensuring the exact same image runs in every stage.
Edge & Hybrid Environments: Containers can run on everything from Raspberry Pis to IoT gateways to hybrid on-prem setups, providing consistent behavior across devices and data centers.

While containers are versatile, it is important to remember that just because you can use them everywhere does not mean you always should.

Why Containerization Matters

You might be asking: why go through the effort of learning Docker commands, writing YAML files, and understanding pods?

Here are the main benefits:

Consistency Everywhere: Containers bundle your application, dependencies, and environment, ensuring it behaves the same in development, staging, or production.
Easier Scaling: As your user base grows, containers make scaling simple. Kubernetes can automatically add or remove containers based on demand.
Isolation and Flexibility: Containers isolate processes, preventing one service from breaking another. You can mix different languages, libraries, and versions without conflicts.
Faster Deployments and Rollbacks: Containers are immutable. Each deployment is predictable, and rolling back to a previous version is simple.
Collaboration and Onboarding: With tools like Docker Compose, a single command can spin up an entire development environment for new team members.
Portability Across Platforms: Containers run anywhere a compatible runtime exists, allowing seamless movement from local development to the cloud or between cloud providers.
Reliability and Recovery: Containers can automatically restart after a crash, and orchestrators like Kubernetes handle failover, resulting in higher uptime.

In short, containerization makes applications predictable, portable, and production ready no matter where they run or how large they grow.

Outro

So here’s the TL;DR: Containers make your app behave everywhere. Docker packages it neatly, and Kubernetes keeps it running when things get big and messy.

Containerization is not magic. It’s consistency, isolation, and sanity-saving all rolled into one.

Thinking About Switching to Omarchy — Is It Worth It?

Shaquille Niekerk — Wed, 08 Oct 2025 01:24:41 +0000

Lately, I’ve been hearing about Omarchy, the workspace designed around using the keyboard as much as possible, minimizing the need for a mouse. As someone who’s always curious about more efficient ways to work this really caught my eye.

But here’s my question... is it worth the switch? or is it just another hype tool that’ll fade away? The idea of navigating an entire OS without reaching for the mouse sounds appealing but I can’t help but wonder about the learning curve. How much time and effort does it really take to become productive?

If you’ve tried Omarchy, I’d love to hear your take. Did it actually boost your workflow? or did it end up being more trouble than it’s worth?

SQL vs NoSQL: The Data War That Never Really Ended

Shaquille Niekerk — Mon, 06 Oct 2025 12:15:58 +0000

Welcome back to another episode of The Stack Unpacked. I'm Shaq-Attack, your friendly neighborhood developer, part-time bug hunter, and full time protector of production.

Today we will be talking about databases, the heart, brain, and occasionally the heartbeat of every software system.

They quietly hold everything together, until one day they don't. And when that day comes, you'll learn the real meaning of "why your choice will haunt you forever".

Our goal today isn't just to list the pros and cons of SQL vs NoSQL. Google can tell you that.
Rather, we will go into understanding why these two database worlds exist, how they think differently, and when each one makes sense. Because once you understand their logic you'll stop fearing databases, and maybe even start respecting them.

So grab your digital shovel, because we're about to dig deep, right into the foundations of data.

SQL: The Structured OG

Before the world went wild with JSON and felxibility, there was SQL the database equivalent of that one guy wearing a pressed shirt, balancing the books, and reminding everyone to commit their transactions before leaving the office.

At it's core, SQL (Structured Query Language) is built on the idea that data should live in relations, or what we usually call tables. These tables are made of rows and columns. They connect to each other through relationships. You might have a users table and a posts table, and the relationship between them says, "Hey, each post belongs to a user."

This structure makes SQL databases feel predictable. You know exactly what your data looks like, how it connects, and what happens when you update it. That predictability comes from something known as Schemas these are the blueprints that define what data can, and can't, exist in a table.

If you try to insert text where a number should go, SQL says "Nope". If you try and delete a user that still has posts linked to them, SQL says "Think again".

It's strict, sometimes annoyingly so, but that's the point. It prevents chaos before it starts.

The ACID Test

SQL databases live by a sacred code knows as ACID. It's not a new programming language, it's a set of rules that keep your data safe and consistent.

Atomicity: All or nothing. A transaction either happens completely or not at all.
Consistency: Data must follow the rules, the schema, at all times.
Isolation: Transactions don't step on each others toes.
Durability: Once somethings saved, it stays saved. Even if the server crashes.

You could think of ACID like an insurance policy for your data. It makes sure you don't end up with a half-processed payment or an order that doesn't exist.

The Strength of Structure

The real magic of SQL isn't just its reliability, it's how it makes data relational. With a few well written joins, you can connect data across multiple tables in milliseconds. Need to know how many posts a user has? One query. Need to see which users bought somethings in the last 30 days? One query.

It's elegant, clean, and honestly an ease to work with, when it works right.

And that structure doesn't just make things consistent, it makes them understandable. Your database becomes self-documenting. Anyone can open your schema and see exactly what's going on.

The Usual Suspects

A few of the most popular SQL databases have been around long enough to earn their grey hairs:

PostgreSQL: The open source powerhouse, famous for reliability and standards compliance. It's a go-to if you want serious features without vendor lock-in.
MySQL: The crowd favorite for web apps, known for being lightweight and everywhere.
SQLite: The embedded, no server needed hero that lives inside mobile apps and small projects.
Microsoft SQL Server and Oracle Database: The enterprise veterans, still running mission-critical systems in giant corporations. Each of these speak SQL, but with slightly different dialects. It's like English accents, you'll understand most of it but some words might sound funny, and take a minute to click.

The Price of Order

This structure comers with trade-offs. SQL databases scale vertically meaning if you need more performance, you usually need a bigger machine, not more machines. They're excellent for consistency, but not so great when you suddenly go viral and your app starts handling millions of requests.

Sharding, which means splitting data across multiple servers, is technically possible in SQL databases, but it seems like it's no walk in the park to manage. Schema migrations have a reputation for being nerve wracking and changing a column on a production database has caused more late night rollbacks than most would like to admit.

Still SQL remains the foundation of most serious applications today. Even with newer tech trends, the structured, predictable world of relational databases continues to thrive. Because once you understand it, it just makes sense.

NoSQL: The Rebel with Many Causes

If SQL is the organized, rule following engineer of the database world, then NoSQL is the creative rebel who dropped out of schema school and build a data model in their garage.

NoSQL, short for Not Only SQL emerged from a growing need to handle larger, messier, and faster changing data than traditional relational databases were designed for. Around the late 2000s, as web apps started scaling to millions of users and cloud computing became mainstream, developers realized that the one size fits all model of relational databases couldn't keep up.

The Rise of the Schemaless Mindset

NoSQL databases were designed to store and retrieve data in ways that break free from the table based model. Instead of everything living in neatly defined rows and columns, data could be saved as documents, key-value pairs, wide columns, or even graphs.

There are several main types:

Document databases: MongoDB, and CouchDB are some examples. These store data in JSON like documents, easy to read, easy to nest, and easy to change on the fly.
Key-value stores: Redis, and DynamoDB represent these. They are lightning fast for lookups, perfect for caching or session data.
Column-family stores: Cassandra, and HBase seem most popular. These organize data for high scalability across distributed systems.
Graph databases: Neo4j focus on relationships, ideal for things like social networks of recommendation engines.

Document databases became especially popular among web developers because they worked naturally with JSON, which is already everywhere in modern programming. Storing data as JSON documents felt intuitive, quick, and familiar. A huge departure from the rigid schema requirements of SQL.

Trade-offs and the "Eventually Consistent" Reality

NoSQL's biggest strength is its flexibility and this is also its biggest trade-off.
Without a strict schema, data structures can evolve as the app grows. You can add new fields, drop old ones, and experiment freely. The catch is, if you're not careful, that same flexibility can lead to inconsistency.

Many NoSQL systems also follow something called eventual consistency. It means that, in a distributed environment, data might not be instantly synchronized everywhere. It'll get there eventually, once all replicas have caught up. That's usually fine for social apps or analytics dashboards, not so much for things like banking systems.

From a research standpoint, this trade-off was a conscious design choice. NoSQL systems prioritized availability and scalability over immediate consistency. They were built for the modern web, where speed and uptime often matter more than having every copy of the data match perfectly at all times.

My first job had me working with a SQL database, full of tables, relationships, and carefully defined rules. Then, in my second job I moved onto a document store, MongoDB, a NoSQL database. That's when I got a taste of freedom.

Transforming documents was easy, almost fun. I could add new fields, change structures, and adapt the data as the app evolved. But that same freedom came with a few headaches. A single type in a field name could make records disappear quietly, no trace, and no error thrown back at you to help find the problem.

It was liberating, but also a reminder. Flexibility without guardrails is powerful, but dangerous.

Structure vs Flexibility

At its heart, the difference between SQL and NoSQL is a difference in philosophy.

SQL believes in order, every piece of data neatly defined, validated, and cross-referenced before it earns its place in the table. It's like a well run library where every book has a catalog number and a precise location.

NoSQL believes in freedom, data can take any form it needs to, as long as it works for the application. It's more like a collection of notebooks scattered across a desk, a little messy, but much easier to jot new ideas into.

Neither is wrong. The choice depends on what kind of world your data lives in. Structured environments thrive on SQL. Dynamic, ever changing systems thrive on NoSQL.

The CAP Theorem: You Can’t Have It All

To understand why these trade-offs exist, we need to mention something called the CAP Theorem, a concept that shows up often in distributed systems research.

It says that a distributed database can only guarantee two out of three of the following:

Consistency: Every node sees the same data at the same time.
Availability: The system always responds, even if some nodes fail.
Partition tolerance: The system keeps working even when parts of the network can’t communicate.

In practice, this means you can’t have perfect consistency, perfect availability, and perfect fault tolerance all at once. You pick two, and you live with the consequences.

SQL databases traditionally lean toward Consistency and Availability, prioritizing correctness.
NoSQL databases lean toward Availability and Partition tolerance, prioritizing resilience and scalability.

Neither side is wrong. They’re just optimizing for different realities.

The Modern Middle Ground

Interestingly, modern database systems have started blurring the lines between SQL and NoSQL.
For instance, PostgreSQL now supports JSONB columns, allowing you to store flexible, document style data without abandoning relational structure.
And on the flip side, MongoDB and Cassandra have introduced stronger consistency models and transactional features.

The industry seems to be quietly converging, not because one side “won,” but because developers demanded both structure and freedom.

Databases today are less about picking a side and more about understanding your trade-offs. It’s no longer a battle it’s a balancing act.

Down the Web3 Rabbit Hole: A Dive Into Blockchain, Crypto & NFTs

Shaquille Niekerk — Wed, 01 Oct 2025 13:40:41 +0000

Intro: Trying to Make Sense of the Buzz

Everywhere I look, people are talking about blockchain, crypto, NFTs, and Web3. To me, it feels like they're talking a different language. I’ve seen friends showing off their crypto wallets, heard people say “I staked this” or “I minted that,” and nodded politely even though I had no clue what they were talking about.

So I decided to actually sit down and unpack it. Not from the perspective of an expert, because I’m definitely not, but as someone curious and maybe a little overwhelmed. This is me doing the research, connecting the dots, and reporting back. Piece by piece, let’s try to figure out what this whole world really is.

Blockchain: The Foundation Layer

The word blockchain gets thrown around like it’s self-explanatory, but once I dug in, I realized it’s less mysterious and more… clever. At its core, a blockchain is just a ledger like the record book an accountant might keep, except instead of one person controlling it everyone can see and verify it.

Instead of a single database, the blockchain is distributed across thousands of computers.
Transactions are grouped into blocks, which get chained together in order.
Because the chain is cryptographically locked, you can’t just go back and fudge the numbers.

This means trust doesn’t come from a bank or an authority, but from the math and the network itself.

Consensus Mechanisms (a new word I had to Google)

The system still needs a way to agree on what’s valid, so that’s where things like Proof of Work (PoW) and Proof of Stake (PoS) comes in.

PoW (used by Bitcoin) makes miners solve complex math problems to add new blocks. Energy intensive, but secure.
PoS (used by Ethereum now) has validators “stake” coins to prove they’re trustworthy. More eco-friendly, but introduces different dynamics.

Once I got this part, the other concepts started clicking. Blockchain is basically the foundation. Crypto, NFTs, DeFi, and everything else I’ll cover later are all built on top of this trustless, shared ledger idea.

Cryptocurrency: More Than Digital Money?

When most people say “crypto,” they mean cryptocurrency which is digital money that runs on top of a blockchain. That much I knew. But what I didn’t realize is how different variants of crypto exist, and how wildly different their purposes can be.

The obvious starting point is Bitcoin. It was the first, launched back in 2009, and it still acts like digital gold: scarce, mined, and valuable because people believe it is. What surprised me, though, is that Bitcoin isn’t really designed to do much beyond being a store of value and a way to transfer money securely.

Then comes Ethereum, which changed the game. Instead of just transferring coins, Ethereum let developers build programs called smart contracts directly on the blockchain. That means you can set rules like:

“If Alice sends 1 ETH, automatically mint her a token.”
“If a loan isn’t repaid in 30 days, return the collateral.”

It’s programmable money that feels both futuristic and a little dangerous.

The Many Faces of Crypto

Altcoins: Pretty much every coin that isn’t Bitcoin. Some are serious (Cardano, Solana), others are memes (Dogecoin, Shiba Inu).
Stablecoins: Tokens tied to “real” money like the US dollar (USDC, USDT). These exist so you can use crypto without the price rollercoaster.
Utility & Governance Tokens: Coins that give you perks in certain apps, or even voting power in communities (we’ll come back to this with DAOs).

And here’s the part that really clicked for me: crypto isn’t just “money” in the way I thought. A token might represent currency, but it could also be your membership pass, your voting share, or your access key to a platform.

So while Bitcoin is digital cash, Ethereum and beyond start to feel like the foundation of an entire alternative economy.

NFTs: Beyond the JPEG Hype

If crypto is about money, then NFTs are about ownership. The acronym stands for Non-Fungible Token. Which, translated into human language, means: a digital thing that’s unique and can’t be swapped 1:1 for something else.

I remember the 2021 explosion, Bored Ape Yacht Club, pixelated punks, people buying virtual land on virtual Earths. Headlines about JPEGs selling for millions left me baffled. Like, couldn’t you just screenshot the image and save it? Why would anyone pay for it?

Here’s what I learned: the picture itself isn’t the NFT. The NFT is more like a certificate of authenticity stored on the blockchain. Anyone can copy the Mona Lisa, but there’s only one hanging in the Louvre. With NFTs, the blockchain acts as the Louvre proving which copy is “the real one.”

Where NFTs Are Used

Art & Collectibles: The most famous use case, from Apes to Beeple’s $69M digital artwork.
Gaming: In-game items (weapons, skins, characters) you can own and even trade outside the game.
Music & Media: Artists selling albums or special editions directly to fans.
Tickets & Identity: NFTs that prove you went to an event or belong to a community.

And then there’s the stranger side: people buying plots of land in the metaverse. At first glance, it feels wild, like paying real money for imaginary dirt. But in these digital worlds, ownership actually matters if the world itself becomes a place people live and do business in.

My Takeaway

NFTs aren’t about the file. They’re about ownership records in a digital economy. It’s less “buying a JPEG” and more “holding a verified spot in a club, game, or cultural moment.”

Whether that’s worth millions is another debate entirely... but it did shift my view from “that’s dumb” to “okay, I see why people value it.”

DeFi: Banks Without Banks?

Some time after NFTs started making headlines, I began hearing another buzzword: DeFi, short for Decentralized Finance. Companies were saying they were “disrupting the financial ecosystem,” investors were hyping it, and honestly, I had no idea what any of it meant. Was this the future of money, or just marketing spin?

Here’s what I found: DeFi is basically an attempt to rebuild the traditional financial system through savings, loans, trading, and even insurance, all without banks or middlemen. Instead, it all runs on smart contracts living on a blockchain (usually Ethereum).

How It Works

Decentralized Exchanges (DEXs): Places like Uniswap where you can swap tokens instantly, without a broker or exchange in the middle.
Lending & Borrowing: Platforms like Aave let you put up crypto as collateral and borrow against it. No paperwork, no banker, just code.
Liquidity Pools & Yield Farming: Users “lock up” tokens to provide liquidity for trades, and in return they earn fees or extra tokens. It’s like putting your money to work in a strange, blockchain-native way.
Staking: Another form of earning, where you lock up coins to help secure a network (common in Proof of Stake blockchains).

On paper, it sounds incredible: 24/7 markets, no gatekeepers, anyone in the world with internet access can participate. That’s the “bright future” side.

But then I discovered the flip side.

Smart contracts can be buggy, and when code manages billions of dollars, bugs = hacks.
Scams and “rug pulls” (where project creators vanish with investor money) have been rampant.
Prices swing wildly, which makes “decentralized loans” sound less stable and more… terrifying.

The Big Question

So is DeFi a glimpse into a new financial era, or a bubble waiting to burst? From what I’ve read, it’s both. The technology is undeniably disruptive, software engineers are literally coding banks into existence, but it’s also risky and a really new space.

For me, the takeaway is this: DeFi isn’t going away, it’s evolving. Whether it becomes mainstream banking or stays a crypto niche depends on if it can grow past its wild-west phase.

DAOs: Wait, What Are These?

When I first came across the term DAO, my reaction was pretty much: “Okay, another acronym. What now?” Turns out it stands for Decentralized Autonomous Organization, which, honestly, didn’t make it much clearer at first.

Here’s what I eventually pieced together: a DAO is like an online organization or community that runs on code instead of managers. Instead of a CEO or a board making decisions, DAOs use smart contracts and tokens to let members collectively govern how things work.

How It Works (in simple terms)

A group launches a DAO on a blockchain.
People who hold the DAO’s token get voting rights.
Rules like how funds are spent or what the project builds next are enforced by smart contracts, not just people.

So, if you want to propose something (say, funding a new project), you submit it, token holders vote, and if it passes, the smart contract automatically carries it out. No middle management, no “trust me bro” just code + consensus.

Examples That Blew My Mind

MakerDAO: Manages a stablecoin called DAI. The entire system is governed by token holders deciding parameters like interest rates.
Uniswap DAO: Governs one of the biggest decentralized exchanges in crypto. Users literally steer how a multi-billion dollar protocol evolves.
Investment DAOs: Groups that pool funds and vote on what startups or NFTs to invest in. Kind of like a venture capital firm, but run by a global internet community.

Why It’s Interesting

To me, DAOs feel like a mashup of a company, a co-op, and a Discord server. They’re still clunky, and participation can be low (not everyone with a token votes), but the idea is radical: organizations without traditional hierarchies, managed by code, where ownership and governance are shared.

Before this, I had never heard of DAOs, and I’m still wrapping my head around them. But they hint at a future where communities online can own and run the things they care about, instead of just consuming them.

Web3 & The Future: All the Pieces Coming Together

After diving into blockchains, crypto, NFTs, DeFi, and DAOs, I started to see the bigger picture. Individually, each concept feels niche or confusing. But together, they form what people are calling Web3, a vision for a new internet that’s built on ownership, decentralization, and participation.

The Core Idea of Web3

Right now (Web2), most of what we do online is controlled by big platforms like social media companies, cloud providers, banks, app stores. We create, share, and spend, but the platforms own the infrastructure and often the profits.

Web3 flips that by saying:

Data and assets should live on blockchains, not private servers.
Users should own their digital identities and creations (via NFTs, tokens, wallets).
Communities should have a say in how platforms evolve (via DAOs).
Money should flow natively through the internet (via crypto and DeFi), without middlemen.

It’s a shift from platform-owned to user-owned.

Where It’s Heading

Metaverse: Virtual worlds where NFTs = your land, clothes, or identity.
Tokenization: Real world assets (stocks, real estate, even music royalties) represented as blockchain tokens.
Layer 2 Scaling: Networks like Polygon or Arbitrum making blockchains faster and cheaper to use.
Interoperability: Bridges that let assets move across chains, like transferring money between banks.
Privacy Coins & Identity: Balancing openness with personal security (think Monero, Zcash, or zero-knowledge proofs).

My Takeaway

The more I read, the more I realized Web3 isn’t a single technology, it’s a philosophy. It’s about imagining an internet where the rules are baked into code, ownership is transparent, and participation is rewarded.

It’s still early days. The tech has big problems (scalability, scams, complexity), regulators are circling, and not every grand idea will survive. Some parts might fade out as fads, others might become the backbone of how we use the internet in ten years.

For me, the biggest shift was seeing Web3 less as hype and more as an experiment in rethinking the internet itself. Whether it succeeds or not, it’s already shaping the conversation about what comes next.

Conclusion: Reflections from the Rabbit Hole

When I first started digging into all of this, I honestly just wanted to understand what people were talking about when they showed off their wallets or dropped words like “mint,” “staking,” and “DAO.” It felt like an exclusive club with its own vocabulary.

Now, after unpacking blockchains, cryptocurrencies, NFTs, DeFi, DAOs, and the wider Web3 vision, I feel like I’ve at least learned the language, even if I’m still a beginner in the conversation.

Here’s where I landed:

Blockchain is the foundation.
Crypto is more than money. It’s programmable assets.
NFTs are about ownership, not just pictures.
DeFi is financial services without banks, both exciting and risky.
DAOs are internet-native organizations experimenting with shared governance.
Web3 is the big-picture philosophy tying it all together.

Do I think this is the inevitable future? I’m not sure. Some of it still feels experimental, messy, or maybe even faddish. But other parts like the idea of user owned platforms, global access to finance, and digital ownership feel too important to ignore.

And that’s the fascinating part: even if half of today’s projects collapse tomorrow, the concepts have already shifted how we think about the internet.

I’d love to hear from you:

If you’re deep into this space, what did you wish someone had told you when you were first learning?
If you’re like me and just starting to explore, what’s the most confusing or intriguing part so far?

Drop your thoughts in the comments, your insights could make this journey less overwhelming for the next curious mind wandering into Web3.

TypeScript: The Safety Net JavaScript Didn’t Know It Needed

Shaquille Niekerk — Mon, 29 Sep 2025 08:05:04 +0000

Welcome back to The Stack Unpacked. If JavaScript is the language that runs the web, TypeScript is the pair of safety goggles you put on when you start cutting metal with it.

Why are we talking about TypeScript? Because JavaScript grew up. Small scripts and prototypes are blissfully flexible and great for experimenting. But once an app balloons to dozens of contributors, hundreds of modules, and a CI pipeline, tiny mismatches become expensive bugs. TypeScript’s job is simple (and huge) catch a whole class of those mistakes earlier, at compile time, instead of at 5 p.m. on a Friday when a customer files a ticket titled “Your app made my money disappear.”

TypeScript doesn’t replace JavaScript it just amplifies it. It adds a static type system on top of JavaScript so editors and compilers can give you smarter feedback, better autocompletion, safer refactors, and clearer contracts between modules. The trick is incremental adoption. You don’t have to rewrite everything overnight. Just Rename a file to .ts, add types where they matter, and let the compiler help you move forward.

Type System Basics

At its heart, TypeScript is a static, structural, gradual type system layered on top of JavaScript.

Static: checks happen before runtime (at compile time).
Structural: compatibility is based on the shape of values, not class names. If two objects share compatible properties, they’re compatible. “duck typing” for the compiler.
Gradual: TypeScript figures out many types for you, and you only add annotations when it can’t.

Tiny type examples

Primitives & annotation

let name: string = "Sam";
let count: number = 0;

Union & narrowing

type ID = string | number;
function print(id: ID) {
  if (typeof id === "string") console.log(id.toUpperCase()); // narrowed to string
}

Interface vs type alias

interface User { id: number; name: string }
type MaybeUser = User | null;

Generics (tiny example)

function identity<T>(v: T): T { return v }
const n = identity<number>(42);

any vs unknown

any disables checking (use sparingly).
unknown forces you to narrow before use and is safer than any.

Important note: TypeScript is compile-time only, so your runtime is still plain JavaScript. For untrusted external inputs (JSON, network payloads), you still need runtime validation.

What TypeScript actually buys you (developer workflows)

TypeScript changes how you work, not just what you write:

Editor feedback that matters. Autocomplete, jump-to-definition, inline docs, these are sharper because the editor knows shapes.
Safer refactors. Rename a function, and the compiler flags missed call sites. You stop guessing where that utility is used.
Living contracts. Types become documentation. A function signature that clearly says “returns Promise<User[]>” communicates intent immediately.
Incremental safety. Start with allowJs or add --checkJs later. Tighten rules over time (enable strict when ready).
Team confidence. Teams ship changes faster when they trust the compiler to catch accidental breakage.

Real moment: I once jumped into a weekend challenge thinking TypeScript would be a nice-to-have. Two hours later I was neck-deep deciding whether a function should return string, Promise<string>, or some awkward union type. TypeScript compiled, but the iteration felt heavier — a useful reminder that the trade-off exists, especially for small prototypes.

The double-edged sword: when TS gets in the way

TypeScript isn't free ergonomically. Trade offs include:

Slower prototyping: For quick hacks, adding and managing types can slow you down.
Build/compile step: Tooling needs configuration, CI must compile. Modern toolchains mitigate this, but it’s still a step.
Learning curve: Generics, conditional types, mapped types, they're powerful, but initially daunting.
Over-annotation: It’s possible to turn a codebase into a sea of redundant annotations. Rather use inference where it’s clear.

Pragmatic rule: use TypeScript where the long-term value of safer changes and clearer contracts outweighs the upfront friction.

Interop & the ecosystem

Any valid JavaScript is valid TypeScript. That’s by design. Incremental migration is possible file-by-file.
Declaration files (.d.ts) describe JS libs for the compiler. Many popular packages bundle types. Others are available via DefinitelyTyped (@types/…).
Tooling: Most major editors (VS Code, JetBrains IDEs) provide outstanding TS support out of the box. Bundlers and runtimes (Vite, Webpack, Bun, Node) all have robust TS integrations.

Migration strategies: practical steps

If you’re evaluating adoption, here’s a safe, pragmatic path:

Add tsconfig.json with conservative settings (allowJs: true, checkJs: false) to start.
Rename files: Convert a single module from .js → .ts/.tsx and fix the immediate complaints.
Use --noImplicitAny / strict incrementally; enable one flag at a time.
Adopt unknown instead of any for places where you really don’t know the shape. Narrow before use.
Use // @ts-ignore sparingly it’s a bandage, not a pattern.
Write declaration files for critical third-party libs without types, or install @types/….
Automate CI checks so compilation runs in PRs early and catches mistakes before merging.

Simple tsconfig.json starter

{
  "compilerOptions": {
    "target": "es2020",
    "module": "esnext",
    "strict": false,
    "allowJs": true,
    "checkJs": false,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

Practical patterns you’ll use daily

Typing async data

  type User = { id: number; name: string };
  async function fetchUsers(): Promise<User[]> { /* ... */ }

DTOs & validation use runtime validation (zod, yup, io-ts) for external inputs, and map validated results to typed shapes.
Typed hooks (React) annotate return types for custom hooks so consumers get correct autocompletion.
Contract-first APIs share types between backend and frontend with a small types/ package so both sides agree on payload shapes.

Advanced features (when you need them)

Generics for reusable, type-safe utilities.
Conditional & mapped types to compute types from other types (powerful in libraries).
Declaration merging & module augmentation for advanced library integrations. Use these gradually, most apps do fine with interfaces, unions, and a little generics.

Wrap-up: when to reach for TypeScript

Short version:

Use TypeScript when you expect to maintain, refactor, or scale the codebase (multiple contributors, production concerns, shared contracts).
Skip it (or opt for minimal use) for throwaway prototypes, tiny scripts, and when iteration speed beats long-term safety.

Final take: TypeScript is a logical safety net. It won’t make you a better developer on its own, but it will make your codebase communicate better, catch a lot of common mistakes early, and give your team confidence to change things safely.

That’s it from me on this weeks post of The Stack Unpacked. Keep shipping, keep breaking, and remember: sometimes the safety net is what lets you jump.

Choosing a Framework is Hard… Here’s the Shortcut

Shaquille Niekerk — Thu, 25 Sep 2025 11:26:03 +0000

This isn’t our next official episode of The Stack Unpacked (that one’s about TypeScript), but let’s call this a filler episode — the kind that doesn’t quite fit in the timeline, but covers a question I think every dev eventually faces:

“Which framework should I use for my next project?”

If you’ve ever opened VS Code, stared at a blank project folder, and then spent weeks comparing React vs Vue vs Svelte instead of actually coding… well, you’re not alone. (Confession: I’ve been there. More than once.)

So today, we’re unpacking the big players — React, Vue, Angular, Next.js — plus some of the newer kids on the block: Svelte, SolidJS, and Astro.
The goal isn’t to crown a winner, but to help you figure out when each makes sense and whether you should stick to one or keep switching.

Why Frameworks Exist

Before we dive into names and logos, let’s rewind.
Plain JavaScript (a.k.a. Vanilla JS) can build anything. But as apps grew, developers found themselves tangled in state management, DOM updates, and reusable UI logic.

Frameworks were the answer: opinionated tools that provided structure, solved cross-browser headaches, and made big apps maintainable.

Think of them as power tools for the web:

You could build a house with a hammer, nails, and patience.
Or you could grab a nail gun and save yourself weeks of frustration.

The Big Four (and Beyond)

React — The Industry Titan

Created by: Facebook (2013)
Philosophy: UI as a function of state. Build small components, wire them together, and let React handle re-rendering.
Ecosystem: Massive. Tutorials, job listings, libraries — everywhere.

// React Hello World
import { useState } from "react";

function App() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

Strengths:

Dominates the industry → more jobs and community support.
Huge ecosystem (Next.js, React Native, Remix).
Flexible: bring your own tools.

Weaknesses:

“Bring your own tools” can also mean decision fatigue.
Learning curve around hooks, state, and effects.

👉 Anecdote: The first time I discovered useEffect, I thought I’d found a magic wand that could summon components and variables whenever I wanted. Spoiler: if you don’t manage those carefully, you’ll summon endless popups until your browser begs for mercy.

Vue — The Friendly One

Created by: Evan You (2014)
Philosophy: Approachability first. “Progressive framework” — you can sprinkle it into a project or build a full SPA.

<!-- Vue Hello World -->
<template>
  <button @click="count++">Clicked {{ count }} times</button>
</template>

<script setup>
import { ref } from 'vue'
const count = ref(0)
</script>

Strengths:

Beginner-friendly syntax (template + script + style).
Great docs, small learning curve.
Strong adoption in Asia and among indie devs.

Weaknesses:

Smaller job market compared to React.
Ecosystem is growing, but less sprawling than React’s.

Angular — The Enterprise Giant

Created by: Google (2010, rewritten in 2016 as Angular 2+)
Philosophy: Full framework. Batteries included: routing, state, forms, HTTP.

// Angular Hello World Component
@Component({
  selector: 'app-root',
  template: `<button (click)="count++">Clicked {{ count }} times</button>`
})
export class AppComponent {
  count = 0;
}

Strengths:

Complete solution → no need to glue together libraries.
TypeScript-first → safer for big codebases.
Popular in large, enterprise teams.

Weaknesses:

Heavy learning curve.
Verbose compared to others.
Less popular with startups and small teams.

Next.js — React with Superpowers

Created by: Vercel (2016)
Philosophy: Build fast, production-ready apps with React. Provides routing, SSR, API routes.

// Next.js page (pages/index.js)
export default function Home() {
  return <h1>Hello from Next.js</h1>
}

Strengths:

Solves React’s missing pieces (routing, SSR).
SEO-friendly with server-side rendering.
Backed by Vercel, growing fast.

Weaknesses:

Tied to React → inherits React’s quirks.
Can feel “too much” for tiny projects.

Svelte — The Compiler Approach

Created by: Rich Harris (2016)
Philosophy: Write less code. Svelte compiles templates into optimized JS at build time.

<!-- Svelte Hello World -->
<script>
  let count = 0;
</script>

<button on:click={() => count++}>
  Clicked {count} times
</button>

Strengths:

Minimal boilerplate → smaller code.
Fast performance.
Joyful developer experience.

Weaknesses:

Smaller ecosystem than React/Vue.
Still maturing — fewer enterprise adopters.

SolidJS — React, Refined

Created by: Ryan Carniato (2020)
Philosophy: React-like API with fine-grained reactivity (no VDOM overhead).

Strengths:

React familiarity without some of React’s inefficiencies.
Blazing performance benchmarks.

Weaknesses:

Young ecosystem.
Fewer tutorials, smaller community.

Astro — For Content-Heavy Sites

Created by: Fred K. Schott & open-source contributors (2021)
Philosophy: Content-focused, partial hydration (ship less JavaScript). Great for blogs, docs, marketing sites.

Strengths:

Lightning-fast static sites.
Can mix-and-match React/Vue/Svelte components.

Weaknesses:

Not meant for complex apps.
Still finding its place in the ecosystem.

How to Choose — A Use Case Guide

Here’s a way to think about it:

Learning & Jobs: Start with React (industry standard).
Quick Prototypes / Simplicity: Try Vue or Svelte.
Enterprise / Big Teams: Angular (structure + TypeScript).
SEO & Fullstack React: Next.js.
Cutting-Edge / Performance: SolidJS.
Content Sites / Blogs: Astro.

👉 Anecdote: Honestly, I’ve spent weeks choosing a framework before even starting a side project. That’s half the reason I’m writing this: so you can spend less time comparing, and more time actually coding.

Recap

Frameworks exist because vanilla JS gets messy fast. Each framework offers a trade-off: React’s ecosystem, Vue’s simplicity, Angular’s structure, Next.js’s power, Svelte’s joy, Solid’s speed, Astro’s focus.

There isn’t a single right answer. The “best” framework depends on what you’re building, your team, and your goals.

Outro

So here’s the real question:

Should you master one framework deeply, or switch based on the project?

Beginners — what framework are you learning first, and why?
Seasoned devs — what’s your rule of thumb when picking frameworks?

Drop your thoughts below. Your experience could save someone else from framework paralysis.

JavaScript: The Language That Runs the Web

Shaquille Niekerk — Sat, 20 Sep 2025 04:47:25 +0000

Welcome back to The Stack Unpacked. Do you sometimes find yourself spending more time debugging JavaScript state issues than managing your own life state? Then just know you’re not alone and you’re in the right place.

First let’s wind the clock back to the mid 90s, for a quick history lesson. The web was young, browsers were clunky, and most websites were basically static pages. If you wanted interactivity, you had three bad options: slow Java applets, slower server round trips, or plain old HTML with a “mailto” link. Not exactly revolutionary.

Enter Netscape. They pulled in Brendan Eich and gave him a wild assignment: “Create a scripting language for the web. You’ve got ten days.” Ten days! That’s barely enough time for me to create a landing page, let alone design a language. But somehow, he pulled it off. What he built was lightweight, approachable, and just powerful enough to make web pages feel alive.

It bounced through a few names. Mocha, LiveScript, and finally JavaScript (thanks to marketing hype). If you missed the naming saga, check out the previous episode.

The key thing: JavaScript was never meant to carry today’s weight. It was duct tape for static pages. Nobody at Netscape imagined we’d be building banking apps and streaming platforms with it.

And honestly, that’s why my own struggles with JS always make me laugh. Half the time I’ll update some piece of state and the UI just… refuses to budge. Hours later, I discover it was one stubborn useEffect all along. JavaScript: the scrappy ten day experiment that still finds ways to humble us.

The takeaway? JavaScript stuck not because it was perfect but because it was there, it worked, and people never stopped leaning on it.

Language Fundamentals & Unique Design

So what makes JavaScript itself unique? It’s a mix of brilliance and chaos.

Dynamic typing. Variables don’t lock into one type. A number can turn into a string mid flight. Great for experimentation, but also why 2 + 2 = 4 and "2" + 2 = "22". Freedom and chaos in equal measure.
Prototypal inheritance. Instead of rigid class hierarchies, objects inherit directly from other objects. Flexible, but confusing if you’re expecting Java or C++.
First class functions. Functions are Lego bricks you can pass them around, return them, stack them endlessly. That’s what made callbacks, higher order functions, and async code possible.
The event loop. The beating heart of JavaScript. Instead of freezing while waiting for slow tasks, JS queues them up and keeps going. Genius, but also the reason for so many “why isn’t this in order?!” debugging moments.

Altogether, JS is like that one friend who’s fun but reckless. Amazing to hang with, but also the reason you stayed out until 3 AM on a work night. You love it, you hate it, you keep coming back.

The Ecosystem Explosion

If 90s JavaScript was a sidekick, the 2000s turned it into a superhero.

V8 engine (2008). Google compiled JS down to machine code, making it fast. Suddenly, “toy language” apps felt snappy.
Node.js. Someone asked, “What if V8 ran outside the browser?” And boom: JavaScript on the server. Front end and back end in one language. A Swiss Army knife that suddenly chopped wood, lit fires, and maybe fought bears?
npm registry. It exploded. Need to left pad a string? There’s a package. Want a color picker? Package. Need to install one library but accidentally pull in a hundred friends sneaking into the concert? Package.
Frameworks. Angular, React, and Vue are like survival gear for managing growing complexity. They gave us patterns, state management, and structure.
Tooling. Babel let us use shiny new features early. Webpack, Parcel, Rollup bundled our mess for the browser. And TypeScript snuck in with some much needed guardrails (we’ll dive into that next episode).

The ecosystem grew so fast it was overwhelming. Today, you can spin up a project in minutes with powerful tooling, but also feel like you need a PhD just to pick a starter template.

The Weird Bits

And now… the quirks. Because no JavaScript story is complete without them.

Type coercion. JS wants to be “helpful,” so it converts things on the fly. Zero equals false? Sure. Empty array equals false? Yep.
Hoisting. Functions can run before they’re declared, and variables sort of exist before they exist. Every new dev hits the “why does my variable exist but not exist?” moment.
The wandering this. In most languages, this points to the current object. In JavaScript, it’s a free spirit. Sometimes with you, sometimes global, sometimes undefined unless you wrangle it with .bind().
Async chaos. NonBlocking is genius, but it gave us callback hell: code nested so deep your editor begged for a second monitor. Promises and async/await cleaned it up, but async still surprises you with “undefined” returns that just haven’t resolved yet.

And the kicker? None of this is a bug. It’s all by design. Remember that ten day deadline. It’s duct tape in the wiring.

Like the time I discovered that adding an empty array to another empty array doesn’t throw an error it just returns an empty string. Why? Because JavaScript.

Where JavaScript Fits Today

So where does JS sit now?

Browsers. Still the backbone. HTML and CSS handle structure and style, but JS makes pages do things.
Servers. Node.js turned JS into a backend player. Teams could now code front and back in one language, giving rise to the “fullstack JS dev.”
Frameworks. Vanilla JS is the foundation, but frameworks (React, Angular, Vue) scale apps without descending into spaghetti. Each has trade offs. React gives freedom, Angular gives structure, Vue tries to balance both.
Beyond the web. React Native powers mobile apps. Electron builds desktop apps. JS even sneaks into IoT and cloud functions.

The key? Just because JS can run everywhere doesn’t mean it always should. Sometimes a strongly typed backend makes more sense. Sometimes plain HTML/CSS is enough. JS is versatile, not universal.

For beginners: don’t panic. Start with vanilla JS and DOM, events, async. Once you get the fundamentals, frameworks and Node won’t feel overwhelming.

The Future & Ecosystem Trends

Where’s JavaScript heading?

Language upgrades. Annual ECMAScript updates (optional chaining, nullish coalescing, destructuring) keep smoothing rough edges.
WebAssembly (WASM). Lets browsers run Rust, C, or C++ alongside JS at near native speeds. JS becomes the manager, delegating heavy lifting while keeping the glue role.
New runtimes. Deno and Bun are rethinking Node’s foundations with better security and blazing speed. Whether they dethrone Node is TBD, but the competition shows JS isn’t slowing down.
Tooling evolution. After years of Babel, Webpack, and Vite, the trend is simplification. Future tools will focus on reducing boilerplate so devs can build instead of configure.
TypeScript. It’s not replacing JS, it’s reinforcing it. Strong typing is becoming survival gear for scaling apps.

Big picture: JavaScript isn’t going anywhere. It’ll keep evolving, branching, and surprising us, which is very on brand for a language hacked together in ten days that somehow ended up running the internet.

Wrap Up

Today we unpacked JavaScript, the scrappy little language that was supposed to validate forms but ended up powering the modern web.

We traced it from its ten day birth at Netscape, through fundamentals like dynamic typing and the event loop, to the V8/Node/npm boom that turned it fullstack. We wrestled with quirks like coercion and this, explored where it fits today, and peeked into a future with WASM, Bun, Deno, and TypeScript.

The truth? JavaScript isn’t just the language of the web. It’s the glue, the connective tissue of modern development. Love it or hate it, it’s here to stay.

Outro

If you enjoyed this episode of The Stack Unpacked, hit follow so you don’t miss the next one where we dive into TypeScript, JavaScript’s safety net and the reason your future self will thank you.

And hey, if you’ve got a friend just starting in web dev, share this with them. Nobody deserves to face callback hell alone.

At the end of the day, JavaScript is like pizza: even when it’s messy, weird, and makes you uncomfortable… you just keep coming back for more.

And that’s where we’ll pause for today. But before I go, I’d love to hear from you.

If you’re a seasoned developer, what’s one piece of advice you wish you’d known earlier? Something that might help those of us still figuring this out. Drop it in the comments. Your experience could make someone else’s learning curve a little less steep.