Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON vs. XML

corecursive.com

Post reply on HN
Print view View original

191–200 of 252 posts

Re: JSON vs. XML

#191

Post by ryukafalz »

justin66 wrote: post #92
ryukafalz wrote: post #64

Earlier quoted context omitted.

I do wish some more details about his current thoughts on actors had been included, though I can understand if they were hard to tease out. I would guess that may go back to his work on Electric Communities as E was a message passing system. Would be interested in hearing more of where his mind is on actors today. The closest thing we have right now I think is Spritely Goblins, though that is Scheme. (Not coincidenta…

The design of the language he is (was?) working on is here: http://www.crockford.com/misty/ There are a few talks from a few months ago on Youtube that detail some of the rationale behind it.

Oh cool, thanks for the pointers!

Re: JSON vs. XML

#192

Post by hajile »

taeric wrote: post #145
adamgordonbell wrote: post #14

Earlier quoted context omitted.

Scala had XML literals as part of the language! Apparently Philip Wadler was the person who told them needed it, because the future was XML. ( Walder is big Haskell/PL person)

The irony, to me, is how it is viewed as a bit of a mistake that they had XML in Scala. Hard to square that with how instrumental JSX was in getting some of the modern JavaScript frameworks as far as it has.

If the web spec had a JSON analog for HTML, I think you'd see a lot less love for JSX.

Re: JSON vs. XML

#193

Post by datavirtue »

hot_gril wrote: post #142
andyjohnson0 wrote: post #126

Earlier quoted context omitted.

Care to elaborate?

Every key is written twice, for opening and closing. Keys can be duplicated, and in fact that's what you have to do if you want a simple list. There aren't numeric types, so you have to parse strings. It also looks horrible. Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 or Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 vs something like [ {"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},…

And if someone is nice enough to stuff a NUL in the document, it all shatters.

Re: JSON vs. XML

#194

Post by kgwxd »

bambax wrote: post #90
adamgordonbell wrote: post #3

This quote is funny: Douglas: The first time I saw JavaScript when it was first announced in 1995, I thought it was the stupidest thing I’d ever seen. And partly why I thought that was because they were lying about what it was. A bigger more interesting thing though is how his company failed, in part, because they used hand-rolled JSON for messaging. Douglas: And some of our customers were confused and said, “Well, w…

> I had to maintain a system once where a major part of it was XSLT Every time the topic comes up I feel the need to say that I loved XSLT. It was so nice. XML frankly was kind of simple, too. It had elements and attributes and that was it. And it had xpath, which offered, among other things, a parent axis, so you could walk the node tree upwards. In JSON you can't get to the parent from the child. And walking down a…

> In JSON you can't get to the parent from the child. And walking down a tree is unintuitive, because nodes can be of different types

JSON only competes with XML. XSLT, XPath, and XSD are just as much an afterthought in that they are completely separate from XML and are entirely optional. The engines written around those is where the powers to walk the tree and validate come from, not XML itself. There's a wide range of tools to get the same benefits for JSON sources, and they usually handle XML and other data sources too, because it shouldn't matter. The reason the X* tools have fallen out of favor is because they're unnecessarily tied to a single type of source data.

Re: JSON vs. XML

#195

Post by HideousKojima »

62951413 wrote: post #100
HideousKojima wrote: post #22

What if I hate both formats? XML is overly verbose, while JSON isn't specific enough or precise enough for a lot of my needs. - This message brought to you by TOML gang

I've got yet another markup language for your hate group's target list :) Come join the dark side where we enjoy the wonders of binary formats such as avro and protobuf.

I actually love binary formats, especially for network communication. We probably waste tons of processing power and network bandwidth needlessly sending JSON back and forth everywhere and re-deserializing it. I'm personally a fan of MessagePack.

Though for something where you want human readability it's hard to beat TOML in my opinion.

Re: JSON vs. XML

#196

Post by taeric »

hot_gril wrote: post #184
taeric wrote: post #167

Earlier quoted context omitted.

Not wrong, but also probably not really indicative of problems or actual use. And while I will be manually typing some data to go into an api for testing, I'm far more likely to by typing it in a thing that is was looser in what it accepts than a json document. Literally today just using dicts in python. And even then, my debugging is dominated by mistakes in data entry there. Also, I see you took it to be a full on…

JSON vs XML isn't going to make or break your project. But why would you use XML for data interchange. It makes sense for things like HTML where you're writing a document, but otherwise, it's usually just a needless burden. Like, if I were there when XMPP was created, yes I would have insisted on JSON. XML was a plainly bad choice. Edit: Oh, JSON didn't exist until a little later. Maybe something similar did.

I mostly agree. I do think Jupyter choose wrong by picking JSON for their documents. They are literally marked up source documents.

XML does have the "benefit" of being a bit more extensible than JSON. Specifically, being able to have namespaced elements in there does make some sense on paper. For example, you could have two extensions both add in data using the same keys, but different namespace. Can't really do that with JSON.

In practice, I think it just fell flat due to way too much "forethought" in things they anticipated people wanting.

Re: JSON vs. XML

#197

Post by taeric »

hajile wrote: post #192
taeric wrote: post #145

Earlier quoted context omitted.

The irony, to me, is how it is viewed as a bit of a mistake that they had XML in Scala. Hard to square that with how instrumental JSX was in getting some of the modern JavaScript frameworks as far as it has.

If the web spec had a JSON analog for HTML, I think you'd see a lot less love for JSX.

Maybe? Though, I suspect JSX just got lucky with when it got popular. There were plenty of mixed HTML/Script things in the past. Most of them met a lot of resistance.

Re: JSON vs. XML

#198

Post by mattacular »

bayindirh wrote: post #170
mattacular wrote: post #21

Earlier quoted context omitted.

> Also, it's way better in transferring/storing big, complex intricate data like 3D objects. Curious how come?

I have a project which can work on 3D objects imported from STL files. My file format has more metadata and much more detailed information w.r.t. a standard STL file, and all the data and the metadata can be written in a way which is both readable and modifiable by a human if needed be. Having the same tags many times means the file can be nicely compressed, it's being XML means it can be verified independently with…

Thank you!

Re: JSON vs. XML

#199

Post by hajile »

kitsunesoba wrote: post #77
PurpleRamen wrote: post #44

Earlier quoted context omitted.

With XML, the complexity is the baseline, and it only goes up from there. With JSON, the complexity is just an option, the baseline is pretty simple. Also, good XML-tools are rare or expensive.

Also this may just be the time in which I got into programming showing, but it seems like JSON encoding/decoding has been built into more languages than support for XML ever was. That's one less required dependency and thing to have to think about in many cases, like in Swift projects all I have to do is make sure my model structs/classes conform to Codable and I'm ready to hit endpoints.

That’s because writing a JSON parser is pretty straight forward with just a couple edge cases.

Writing a conformant XML parser is a HUGE undertaking comparison.

I could get most places to give me the time to write a JSON parser in whatever language of it didn’t have one. I couldn’t do that with XML.

Because of this, every common language (and most uncommon ones) has a JSON parser while XML parsers are less common (and fully conformant ones are even more rare).

Re: JSON vs. XML

#200

Post by bambax »

chrismorgan wrote: post #151
bambax wrote: post #90

Earlier quoted context omitted.

> I had to maintain a system once where a major part of it was XSLT Every time the topic comes up I feel the need to say that I loved XSLT. It was so nice. XML frankly was kind of simple, too. It had elements and attributes and that was it. And it had xpath, which offered, among other things, a parent axis, so you could walk the node tree upwards. In JSON you can't get to the parent from the child. And walking down a…

I first touched XSLT in 2010. I appreciated what it could do, but it was painful to work with due to poor documentation and tooling. This has only gotten worse by comparison with alternatives. You can still do XSLT in the browser. You can serve arbitrary XML and transform it. As an example, Atom feeds on my website (such as https://chrismorgan.info/blog/tags/meta/feed.xml >) render just fine in all mainstream browser…

I think out of the box, browsers can only do xslt 1; but Saxon offers a JS version of their engine that does xslt 3.0 and is free (as in beer): https://www.saxonica.com/saxon-js/index.xml
Post reply on HN