Comment by toyg
6 months ago
Nah, we still have all those issues and more.
The hard truth is that XML lost to the javascript-native format (JSON). Any JavaScript-native format would have won, because "the web" effectively became the world of JavaScript. XML was not js-friendly enough: the parsing infrastructure was largely based on C/C++/Java, and then you'd get back objects with verbose interfaces (again, a c++/java thing) rather than the simple, nested dictionaries that less-skilled "JS-first" developers felt at ease with.
The thing is, JSON is even superior in C++.
It's a dumber format but that makes it a better lingua franca between all sorts of programming languages, not just Javascript, especially if you haven't locked in on a schema.
Once you have locked in on a schema and IDL-style tooling to autogenerate adapter classes/objects, then non-JSON interchange formats become viable (if not superior). But even in that world, I'd rather have something like gRPC over XML.
A dumber format works great for dumber protocols like RPC. When you're trying to represent something complex like a document, JSON is crap. Imagine the JSON equivalent of HTML. Then imagine editing it by hand.
"Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
> When you're trying to represent something complex like a document, JSON is crap.
I agree, but let's be honest, how often does this actually come up for data interchange. Because the situations where you want a human-editable document that is also computer-legible are fairly few in number. Prose in office documents, human-written documentation for code, config files.
For things where computer programs are driving the show (which is most the time, today), you want interchange designed for programming languages, whether that's JSON, CSV, gRPC, or what have you.
This even applies to documents that are completely computer-generated: get the inputs into an appropriate data structure using easy interchange formats, and then render to the output document (HTML, XML, LaTeX, etc.).
> Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
Fully agreed. But even where you do have documents, XML is not always the right thing either, which is why there are other markup formats in wide usage like TeX and Doxygen/Javadoc-style comments. XML seems best aligned to things like office document formats or other rich text where it makes sense to want to wrap some human text inside some computer-visible markers.
1 reply →
that's the thing, XML should have become javascript native so that we could write inline HTML more easily like JSX from react allows us to do.
It did somewhat. It was called E4X.
more like it almost did. bummer. thanks for the pointer. sad to find out that the attempt was made but rejected. i wonder why.
1 reply →