Houston, We Have a Braces Problem

Let’s be honest. We’ve all been there. It’s 2 AM, you’re debugging a gnarly issue, your eyes feel like they’ve been sandpapered, and the only thing standing between you and a sweet, sweet victory is a rogue comma in a thousand-line JSON file. In that moment, as you stare at the linter’s unhelpful Unexpected token , in JSON at position 999 error, you can’t help but think: “JSON is evil.”

Now, let me say this: I get it. JSON (JavaScript Object Notation) is the undisputed king of data interchange. It’s lightweight, human-readable (most of the time), and supported by practically every language under the sun. But like that one friend who’s great at parties but terrible at helping you move, JSON has its… quirks.

The Case Against Our Curly-Braced Overlord

My beef with JSON isn’t just about late-night debugging sessions. It’s a collection of small, infuriating papercuts that, over time, have led me to this very public declaration of disapproval.

1. The Great Comment Wasteland

First and foremost: you can’t add comments. I mean, seriously? We’re developers! We’re taught from day one to comment our code, to explain the why behind the what. But JSON? It wants none of that. It’s like it’s daring you to forget why that obscure configuration flag is set to true.

{
  "enableMagic": true, // This enables the highly experimental and probably-will-break-everything feature. Handle with care.
  "retries": 3 // Yeah... this is not allowed. Good luck remembering why you set it to 3 in six months.
}

This “feature” alone feels like a personal attack on my future self.

2. The Tyranny of the Double Quote and the Missing Comma

JSON is a harsh mistress of syntax. Keys must be in double quotes. String values must be in double quotes. Single quotes? Get that weak stuff out of here. And the infamous trailing comma? Don’t even think about it. While a forgiving language might just let it slide, JSON will throw a fit. It’s an unnecessary rigidity that just feels… mean.

3. The Wild West of Data Types

JSON’s type system is what I’d call “aggressively minimalist.” You get strings, numbers, booleans, arrays, objects, and null. That’s it. No native date type, which is why we’re all stuck parsing ISO 8601 strings. And because of its weak typing, a field that was an integer yesterday could suddenly become a string today, and your strongly-typed language will have a meltdown. It’s a recipe for chaos masquerading as “flexibility.”

4. The Verbosity… Oh, the Verbosity

For a “lightweight” format, it can get pretty chunky. Every single key has to be repeated for every object in an array.

[
  { "name": "Sir Reginald Fluffington", "species": "Cat", "disposition": "Grumpy" },
  { "name": "Barnaby Wigglesworth", "species": "Dog", "disposition": "Overly Enthusiastic" },
  { "name": "Professor Feathers", "species": "Parrot", "disposition": "Sarcastic" }
]

It’s not the worst thing in the world, but when you’re dealing with massive datasets, it adds up.

So, What’s a Grumpy Developer to Do?

Am I about to launch a global crusade to dethrone JSON? Probably not. It’s too entrenched, too… useful. Over 90% of web APIs use it for a reason.

But a little part of me will always cheer for the underdogs like YAML, which supports comments and has a cleaner syntax, or even TOML for its straightforward configuration style. They feel like they were designed with a developer’s sanity in mind.

At the end of the day, JSON is a tool. A powerful, ubiquitous, and occasionally infuriating tool. I’ll keep using it, I’ll keep complaining about it, and I’ll keep spending late nights hunting for that one misplaced comma. Because that’s the life we chose. But it doesn’t mean I have to like it.