It's not that JSON itself is bad, but it's obviously for machines to author, not for humans.
- No comment
- No trailing comma
- No multi-line string
It's a terrible format to type manually. However, we just shrugged and said "at least it's not XML" and started writing it manually anyway.
And later we finally realized comments are not optional, so we got JSON5, JSONC, etc...
15 years later and JSON still is still very far from the standardization and tooling that XML had at the time.
It reminds me of the NoSQL thing from back then too, oversimplified it was "what if we chuck JSON blobs in a key/value store?". It took years to realize that relational databases and SQL weren't actually that bad, and / or that NoSQL had a long term cost.
1: Standardization was made by committee lovers and/or architecture astronauts leaving us with overly convoluted (sometimes to fit lacklustre object models in early OO languages) and complex ways of working.
2: Complexity that introduced security vulnerabilities
Sure, there was some great tooling available, but how much of it was needed because all complexity made it hopeless to work with without the tooling?
I used it for configuration and serialization in some projects, and it was actually great but I almost always diverged from the bloated norms and defaults for readability/writeability (that made it a bit annoying to specify serialization rules).
I mean, why did people prefer?
<object><property name="somename"><int32>123</int32></property></object>
<object somename="123"/>
JSON was and is so far the best popular compromise between "just plain data" and "some" structure to make automated processing non-painful.
Also as an improvement over XML collections (do you created a container element to specify container target leading to bloat or just map some of the sub-elements to specific collections and hope you don't run into ambiguities?) is that collections are just specific lists to a property.
The biggest drawback of JSON is that we never had a way to handle type specializations/subtyping but had we done that we might have not gotten the universal acceptance across languages.
Yes, comments but whenever you need that you can make a single-line regexp to strip a useful subset of them without affecting anything by the standard by removing matches of
/^\s*\/\/[^\r\n]*/mgEasier to write than JSON.
But weirdly harder to get right in other ways, especially for nesting things.
Almost made the mistake of becoming simple to parse.
Alas, defeat was again snatched from the jaws of victory on that one…
https://yaml.org/spec/1.2-old/spec.html#id2759572
However, I find the toml language somehow the better tech, while I still think that configuration should not be a "format" but a language.
I think at least the recomposition of values with other values should be possible:
CONFIG_PATH="$MAIN_PATH/config"
DEV_PATH="dev"
PRD_PATH="prod"
MAIN_PATH=env.IS_PROD ? "prod" : "dev"JSON is rediscovering XML Schema, XML DTDs etc, when we had those a quarter century ago already.
It was so good when you could define the structure easily and validate it with standard tooling.
If I have a structure like this JSON:
{
"foo": "bar",
"nested": {
"nested_foo": "nested_bar",
}
}
<foo>
bar
</foo>
<nested>
<nested_foo>
nested_bar
</nested_foo>
</nested>
<foo>
bar
</foo>
<nested nested_foo="nested_bar"/>
To me, JSON is nice because it's essentially the minimum viable way of encoding a C-style struct (floating point behavior notwithstanding.) XML has extras like attributes, schemas, and DTDs, which may be useful, but they come at the cost of having additional syntax (<!DOCTYPE ...>, etc), which is auxiliary to the goal of encoding data structures, and thus makes it no longer as minimal.
To me, JSON's approach of having a separate out-of-band definitions of schema (e.g. JSON schema) is the better approach because it's less opinionated, you only pay for it when you need it, and it doesn't require separate syntax. Leave validation to a validation step, my data is my data.
I see some XML from other sources and it’s just awful. Everything that should be a nested tag is all jammed into an unreadable tag with attributes with no visual structure at all, spilling over the 80th column and word-wrapping in the terminal, it’s just like, what the hell. Why even use XML at that point?
Where you'd do attributes is like this:
<foo type="address">
bar
</foo>
<nested type="resident_list">
<nested_foo type="resident">
nested_bar
</nested_foo>
</nested>
The data is in the tags, attributes are metadata, extra information that's needed during the process.
This is what JSON is lacking, you can't give metadata to data, like defining types. The type definition needs to live NEXT to the data in special keys you need to check every time when parsing.
I had been tasked at least several times in my past jobs to develop XSLT scripts to transform data into user-readable content. I don't know of anyone that uses XSLT today and I have no idea if there is a JSON equivalent.
Though as I understand it it's possible that this might not be the case for much longer: https://github.com/whatwg/html/issues/11523
jq is the closest thing for json, but it’s far messier to write longer filters than XSLT, and that’s saying something!
I was building some kind of parser for them and got confused for a second when my Python script returned bare XML when fetching the front page :D
But we haven't, otherwise we'd use all those better formats instead
Which is a good thing. This makes JSONL possible.
{
"uhh": "nope"
}
except they very much are. the place to explain your payload is in the API documentation, not alongside the payload. It's not code.
I'm more partial to YAML for readability, but I don't think JSON configs are an awful anti pattern.
> It's not code.
package.json has a field literally called 'scripts' where the values are shell one-liners.
Not to be mean, but this has the trifecta of amateur programming:
- JSON - Games - One solution for everything.
Pro tip, you can store variables as they are in memory to disk. Got 1 million 2D points representing units? Each point is a couple of floats? You can store each float as-is, write the amount of floats as an int (4bytes), the first float is the X coord, the second the Y coord, (4 bytes each), then repeat 1M times, boom you just solved that in 8MB, and in a couple of miliseconds of compute. Bonus point, no escaping, no import json, just a programmer programming.
But you are being mean. Also, the guy who wrote the article is no amateur, but a seasoned veteran who's likely been storing floats in files for decades. Check him out, you might be surprised.
Programmers who had to do low level programming due to early hardware restrictions are hereby granted immunity from high-level elitism and gatekeeping, they can vibe code and npm install is-even if they so wish to.