Since you explicitly mentioned fashion, I assume you read this:
> There is a distinction that the industry refuses to acknowledge: developer convenience and correctness are different concerns. They are not opposed, necessarily, but they are not the same thing. … The rationalization is remarkable. "JSON is simpler", they say, while maintaining thousands of lines of validation code. "JSON is more readable", they claim, while debugging subtle bugs caused by typos in key names that a schema would have caught immediately. "JSON is lightweight", they insist, while transmitting megabytes of redundant field names that binary XML would have compressed away. This is not engineering. This is fashion masquerading as technical judgment.
I feel the same way about RDBMS. Every single time I have found a data integrity issue - which is nearly daily - the fix that is chosen is yet another validation check. When I propose actually creating a proper relational schema, or leaning on guarantees an RDBMS can provide (such as making columns that shouldn’t be NULL non-NULLable, or using foreign key constraints), I’m told that it would “break the developer mental model.”
Apparently, the desired mental model is “make it as simple as possible, but then slowly add layer upon layer of complex logic to handle all of the bugs.”
My zod schemas are 100x simpler than all those SAX parsers I maintained back in the day. Honestly I kinda doubt you've worked with XML a lot. The XML data model is wildly different than that of pretty much every programming language's builtin data structure, and it's a lot of work to cross that bridge.
The article posted here makes a good point actually. XML is a DSL. So working with XML is a bit like working with a custom designed language (just one that's got particularly good tooling). That's where XML shines, but it's also where so much pain comes from. All that effort to design the language, and then to interpret the language, it's much more work than just deserializing and validating a chunk of JSON. So XML is great when you need a cheap DSL. But otherwise it isn't.
But the article you quoted makes the case that XML was good at more stuff than "lightweight DSL", that JSON was somehow a step back. And believe me, it really wasn't. Most APIs are just that.. APIs. Data interchange. JSON is great for this, and for all its warts, it's a vast, vast improvement over XML.
You’re correct that I haven’t worked much with XML. Some light parsing, mostly. When I was a kid in the early 00s, I rewrote my personal website (which wasn’t anything terribly complex, maybe 10-20 pages) into XHTML. I remember thinking that it seemed overly complicated for no clear benefit.
The article resonated with me because it was addressing a fundamental challenge I deal with constantly: watching people make decisions that allow them to ship quickly, at the expense of future problems.
In your situation, I would blame the developers, not the tools (JSON) or fashion.
Even if it's fashionable to do the wrong thing, the developer is at fault for choosing to follow fashion instead of doing the right thing.