4 ms·
JSON is the version of XML we deserve.
by seanp2k2 3y ago
JSON is the version of XML we deserve.
- guideamigo 3y agoI wish it had comments. And for that reason, I prefer yaml.
- WirelessGigabit 3y agoI prefer JSON's strictness. A Boolean cannot be confused for a string. In yaml: country: no Now your country is Boolean(false) Now, I still prefer yaml overall. Also, I hate that GitHub actions don't support anchors.
- wyldfire 3y agoThat's a false dichotomy. JSON could have comments and not be ambiguous like YAML. In fact: there exists a specification called JSON5 which does include comments. But I agree that it would've been nice if it had comments before it achieved a critical mass of adoption.
- squeaky-clean 3y agoI don't think they were saying that's an issue of comments, just an issue of yaml vs json.
- euroderf 3y agoI've read the opinion that comments were omitted from JSON in order to forestall hacky round-trip conversions to/from other formats (like XML). Can anyone confirm/deny ?
- mediumsmart 3y agoThe primary reason why JSON does not support comments is that its creator, Douglas Crockford, deliberately removed them from the format to prevent misuse and keep it as a pure data-only format. Crockford observed that some people were using comments to store parsing directives, which could break compatibility between different systems. Hence, the decision to remove comments to maintain the simplicity and consistency of the format across various programming languages and environments. https://www.freecodecamp.org/news/comments-in-json/ https://www.freecodecamp.org/news/comments-in-json/ I vote for the minimalist heretic. https://www.infoq.com/presentations/Heretical-Open-Source/ https://www.infoq.com/presentations/Heretical-Open-Source/
- mminer237 3y agoIn YAML 1.2 that gives the string "no".
- 8organicbits 3y agoHuh, that's a breaking change. yes/y/no/n/on/off are no longer boolean. https://perlpunk.github.io/yaml-test-schema/schemas.html https://perlpunk.github.io/yaml-test-schema/schemas.html
- milliams 3y agoYes, it it. However, it's a breaking change that happened 14 years ago.
- masklinn 3y agoExcept for many yaml implementations either not supporting 1.2 at all (pyyaml, ruby stdlib) or being a weird mix (goyaml) so as to keep working with older files. So when you’re dealing with objective reality, this is still an issue today.
- manojlds 3y agoSo that's been the spec since 2009???
- riwsky 3y agocries in TOML
- guideamigo 3y agoThis is the only example everyone points out against yaml. For Json, there are several such syntactic problems. Unnecessary double quotes and only double quotes everywhere. No dangling comma.
- msm_ 3y agoThese are different kinds of problems. JSON is (arguably) too strict. YAML is (arguably) too loose. One is better for machines, the other is (usually) better for writing by humans by hand. There's no perfect compromise for every use case.
- kondro 3y agoThere’s always JSON5
- Defletter 3y agoTrue, but the multi-line comments give me the ick, and there's still no standard for bigints.
- hackerbrother 3y agoYAML is a fine implementation of JSON with comments.
- devjab 3y agoNobody deserves XML! In all seriousness I get the idea behind XML and I have used a couple of SOAP services which were absolutely brilliant, but as someone who has spent a decade “linking” data from various sources in non-tech enterprise… Well… let’s just say that I’m being kind if I say that 5% of the services which used XML were doing it in a way that was nice to work with. Which is why JSON’s simplicity is such a win for our industry. Because it’s always easy to handle. Sure you can build it pretty terrible, but you’re not going to do this: <y value=x> and then later do <y>x</y> which I’m not convinced you didn’t do in XML because you’re chaotic evil. And you’re not going to run into an issue where some Adobe Lifecycle schema doesn’t work with .Net because of reasons I never really found out because why wouldn’t an XML schema work in .Net? Anyway, I’m sure the intentions behind XML were quite brilliant but in my anecdotal experience it just doesn’t work for the Thursday afternoon programmer mindset and JSON does.
- bryanrasmussen 3y ago>In all seriousness I get the idea behind XML followed by >and I have used a couple of SOAP services which were absolutely brilliant makes me doubt the first part of the statement. If I were to guess what it means is you understand the point of SOAP, and also understand the limitations and problems especially as it relates to uses of XSD in SOAP and the various stack of Web Service specs, but you probably have not had much experience with non-XSD based validation of XML, you do not have any experience with document formats as opposed to data formats, you probably are not familiar with larger international standards like UBL, and not familiar with XML formats that are not so much data or document oriented - SVG, XSL-FO (which admittedly sucks more than is reasonable), GraphML and so forth... A lot of the commenters here are standing up for the value of XML, and I'm not actually with this comment, there are a lot of benefits for using JSON especially when you are using JavaScript all over the place. But saying XML sucks because XSD and SOAP sucks indicates a potential lack of knowledge about the whole subject (perhaps only caused by infelicitous phrasing)
- devjab 3y agoI’m simply trying to say that I think XML sucks because the people who implement it suck, and not because of any technical reasons. Hell, I’m saying that I think XML sucks because it allows people to suck when they use it, myself included.
- crabbone 3y agoA catchy but a meaningless phrase. JSON is a dumpster on fire. Probably in even more ways than XML is. Maybe you deserve it... I feel like I'm being punished by the stupid people who make me use it in a way similar to the sham court hearings from The Planet of Apes.
- VoodooJuJu 3y ago>I feel like I'm being punished by the stupid people who make me use it What's the use-case and what alternative would you prefer?
- crabbone 3y agoThere are multiple contradictory requirements to different things you could want from communication formats. Below are some examples: * You could want to have a universal tool that can examine and understand the contents of the message (for debugging purposes), but you could also want not to send meta-information about the message (s.a. types or sizes etc.) that is essential for parsing the message. And you cannot have both at the same time. * You could want a message format that maps onto the primitive types of a particular language well, but at the same time you may want it to be universal and map to many other languages well. But this is impossible because different languages will have different primitive types and the need to be generic will act against the need of being specific. * You may want to be able to stream data, but this works against hierarchic data organization. * You may want to be able to write messages into pre-allocated memory buffers w/o having to re-calculate the amount of memory necessary to encode a message, but this makes it very hard / impossible to add custom fields and types. --- Given all this, I don't think that JSON is a good match for any use-case it's currently commonly used for. If I want data transfer, I'd go for something like SQL. If I want configuration, I'd go for Datalog. But then I see value in optimizing the transfer of multiple similar records, whereas someone else may see value in optimizing transfer of hierarchically structured data, which isn't necessary repeating. I tried many formats of this kind, and am yet to find a good one. I'm inclined to think that maybe trying to arrange hierarchical data with different constraints on its organization is just a bad approach to data transfer, that the organization and constraints of such data shouldn't be encoded as part of the format, but interpreted by the users of the format. But, if I really had to do this the best way I can image, I'd still go for Datalog.
- andyjohnson0 3y agoWhenever two or more are gathered together, they shall argue about JSON vs XML. Personally I like the simplicity of JSON and also the expressive power of XML. But then I tend to only use each for the task it was primarily intended: application data-on-the-wire in JSON and "documents" in XML. It seems like a lot of the recurrent discussion around these technologies happens when they're pushed to do things outside their comfort zone. And I wonder if some of this is down to siloing of developer knowledge. There was a comment on HN a few days ago (not by me, and I can't find it now) to the effect that web development has historically attracted self-taught developers or those who have come to it by routes like bootcamps. It went on to say that they perhaps consequently lack some knowledge of existing techniques and solutions, and therefore tend to recreate solutions that may already exist (and not always well). And this drives the well-known churn in webdev tech: of which bolting schemas onto JSON is arguably an example. I wonder what people think of this? Personally I think it has some merit, but that the "churn" has also generated (along with much wheel-reinvention) some great innovations. And I say that as someone who works mainly on back-end stuff. Thoughts?
- vonwoodson 3y agoI'd extend this "X developers are mostly self-taught" onto all of computer development. They say, "Every developer Of a Certain Age's first programming language was BASIC" and my experience of (eventually) getting a CS degree is that there is the expectation of students to already know how to do the thing that they are trying to teach; a certain level of "self taught" is expected. To that end, I can see how in The Age of Teh Internets that the standard of self taught has moved of from BASIC to HTML/CSS/JS (or Unity or whatever sparked the young mind's attention). --- What I'm not certain of is that "self taught" means that work will be duplicated because the self taught developer doesn't know the technology that exists. I think that someone who is extremely online will very likely be more abreast of what technologies exist. I think that a formal education is better at establishing what the fundamentals underlying a programing method or paradigm... but not necessarily at exposing new programmers to what the state-of-the-art is.