Hacker News Reader

Comment by larusso | Hacker News Reader

Makes me kind of sad. I started my carrier back in days when XHTML and co were lauded as the next thing. I worked with SOAP and WDSLs. I loved that one can express nearly everything in XML. And namespaces… Then came json and apart from being easier to read for humans I wondered why we switch from this one great exchange format to this half baked one. But maybe I’m just nostalgic. But every time I deal with json parsers for type serialization and the question how to express HashMaps and sets, how to provide type information etc etc I think back to XML and the way that everything was available on board. Looked ugly as hell though :)

View on HN

json is sort of a gresham's law "bad money drives out the good" but for tech: lazy and forgiving technologies drive out the better but stricter ones.

bad technology seems to make life easier at the beginning, but that's why we now have sloppy websites that are an unorganized mess of different libraries, several MB in size without reason, and an absolute usability and accessibility nightmare.

xhtml and xml were better, also the idea separating syntax from presentation, but they were too intelligent for our own good.

> lazy and forgiving technologies drive out the better but stricter ones.

JSON is not "lazy and forgiving" (seriously, go try adding a comment to it).

It was just laser-focused on what the actual problem was that needed to be solved by many devs in day-to-day practice.

Meanwhile XML wanted to be an entire ecosystem, its own XML Cinematic Universe, where you had to adopt it all to really use it.

It's not surprising to me that JSON won out, but it's not because it's worse, it's actually much better than XML for the job it ended up being used for (a generic format to transfer state between running programs supporting common data structures with no extraneous add-ons or requirements).

XML is better for a few other things, but those things are far less commonly needed.

Don’t know if I would describe it as much better. I see it similar to the whole SQL -> NOSQL -> let’s add all the feature and end up with SQL. JSON undergo a similar story with the difference that we didn’t go back to XML. What I mean is to simplify and then realize what was actually missing. But I agree for the smaller services and state transfer especially in web XML was just too damn big and verbose. But conceptually it was great.

For "I need this Python dict to exist in this unrelated JavaScript program's context space" JSON is absolutely much better. If only because you completely sidestep all the various XML foibles, including its very real security foibles.

JSON is so good at this that, like CSV, it does displace better tech for that use case, but the better tech isn't usually XML but rather things like Avro or Protobuf.

For the most part people don't add on XML features to JSON. Comments are a frequent addition, sometimes schemas, but for the most part the attraction of JSON is avoiding features of XML, like external entity validation, namespaces, getting to choose between SAX or DOM styles, or being required to support unrelated XML systems just to use another.

Again, there are problem domains where those are helpful, and XML is a good fit for those. But those problem spaces end up being much smaller in scale than the ones solved by JSON, Avro, Iceberg, etc.

But the whole point to JSON is to be nearly as dumb simple as possible so that the complexity of the problem domain will necessarily be handled in a real programming language, not by the data magically trying to transform itself.

Reply on news.ycombinator.com