Hacker News Reader

Comment by superfist | Hacker News Reader

I have very same impression. XMPP is basing on XML where parsing is order of magniture more complex than JSON. In lot of ways very similar to SOAP mess where you could not comunicate across different software because each of them supportet different set of SOAP extensions and good luck with communicating with web client.

View on HN

> XMPP is basing on XML where parsing is order of magniture more complex than JSON

The last time I heard, there weren’t two JSON parsers that actually accepted the same language, so I’m not sure there’s an existence proof to back this statement up. :-)

XML is more complicated, but if we want to compare apples to apples, it’s only due to the white space sensitivity. (dtd, schema, etc don’t have analogous technologies in the json world, and at least xpath is a standard, unlike jq).

> XML where parsing is order of magniture more complex than JSON

You're supposed to use an off-the-shelf XML/JSON parser, not write it yourself.

Even if you don't parse it yourself, XMLs data model is usually more of a chore to consume.

XML/SGML is highly appropriate for representing rich text, though, which is the purpose of chat apps/logs. Using JSON you'd have to invent ad-hoc markup on top of JSON, loosing any advantage it may have.

Nobody uses rich text formatting, and even if they did, the message body is only a small fraction of the total protocol content.

> Using JSON you'd have to invent ad-hoc markup on top of JSON

That's basically a description of ActivityPub that wraps HTML in JSON!

Will activitypub let me do:

  <body> markdown text </body>

And ship some js to convert to html?

No, each server has their own rules what and how will they present content. Usually they accept limited subset of HTML and filter out everything else.

Where does "order of magnitude" come from? In my experience, XML parsing is about three times slower than JSON and around two or three times the size. For most complex applications, this is not a show-stopper, because the bottleneck is elsewhere.

XML was a hype in 1999, when XMPP has been invented and JSON was a hype fifteen years later. When people invent protocols they just use what is trendy in the moment.

Sure, XMPP has problems, but ZERO of them comes from using XML. Thinking that using JSON will help solve the real problems any federated protocol would face is very naive and will lead to more than a few unpleasant discoveries down the road.

fwiw, nobody on the Matrix team (or that I know in the community) thinks that JSON is somehow fundamentally superior to XML - it’s just a data encoding. More recently we’ve been using CBOR over JSON for instance. Anyone who claims Matrix is about “using JSON rather than XML” to do the same thing is catastrophically missing the point.

https://twitter.com/joepie91/status/1102888957510107136?s=19

Check this active member of the community. Also folks on this very page claim how xml consumes much more resources

XML is not popular because of JavaScript developers.

Coming from .NET, I do not care using JSON or XML, because the APIs System.Xml.Linq, Newtonsoft.Json and the upcoming System.Text.Json are a joy to use. I think the lack of good native representation of XML in JavaScript made it a unwanted choice.

Regards SOAP I tend to agree to you. Beyond the Basic profile it was a hassle to interop.

>XML is not popular because of JavaScript developers.

This could not be more false. JavaScript is built around the DOM. You can parse XML with DOMParser and query it with the same interfaces that you build your UI with. The X in AJAX is XML. The "good native representation" of XML in JavaScript is the very core data structure that JavaScript was designed to interact with.

XML is not popular because it's complex. Escaping is hard. XML bombs make it unusable in its raw form.

Fundamentally, XML doesn't give you data structures that look like the ones you use in your application logic. You have to transform your data into something that makes sense in XML, then transform it back. With JSON (and other formats) the data structures that you're given are present in almost every programming language. You don't need to model your data differently for transit or storage than you do in your application logic.

Good arguments but using DOM Api in JavaScript needs many more lines than JSON parsing and access. jQuery made HTML access bearable for a simple reason: DOM sucks :)

Average Joe Dev does not reach the impedance mismatch you mention correctly.

The DOM interface is roughly the same in almost every language. The JSON interface is almost always simpler. It's no mystery why JSON is more popular. XML never died because of JavaScript developers.

XML is extremely popular with the JS crowd, they just don't know they're using it ;) JSX (React's template language extension to JavaScript) stands for "JavaScript XML" [1], and there was E4X as an official ECMA spec for XML literals before that (though admittedly not as cool as React is, doesn't have vdom and update events, components for MVC, etc). And JavaScript was indeed invented for DOM manipulation, it's just that the DOM API simply sucks.

The whole XML hate thing is symptomatical for the staged this-vs-that discussion we endure in today's forums.

I guess there are those document representation schemes that everybody hates on, and those that nobody uses ;)

[1]: https://en.wikipedia.org/wiki/React_(JavaScript_library)#JSX

E4X was far more powerful than JSX. JSX is just a nice syntax for object construction. E4X could additionally query XML (think XPath but different) not to mention support for XML namespaces, etc.

I agree with the rest though.

I agree.

Reply on news.ycombinator.com