13 ms·

JSON5 Data Interchange Format

100 points by gjvc 5y ago

develatio 5y ago
IIRC there is a JSON6 format which adds features and improvements on top of JSON5.
- gchq-7703 5y ago
  HJSON [0] is also another format that tries to make it easier for humans to read / write json. [0] https://hjson.github.io/ https://hjson.github.io/
roncohen 5y ago
Couple of gripes: - Still no date type - Why make it more loose? Like "Strings may be single quoted." doesn't bring any value.
- AlfeG 5y ago
  It brings it closer to JavaScript behavior I guess. I guess it's nice to have ability to copy random js object declaration to actual json without editing
- Cthulhu_ 5y ago
  What would a date type look like? An ISO-8601 string is probably as good as it'll get, else you end up with an object containing loads of additional information like timezones, offsets, etc. There's also https://json-schema.org/understanding-json-schema/reference/string.html#dates-and-times https://json-schema.org/understanding-json-schema/reference/... for a formalized date format in JSON. The looseness seems to be aimed at human authors who want to write JSON as if it were JS, so mainly package.json. But, json is not ideal for configuration for multiple reasons.
  - rbut 5y ago
    If you wanted JSON to parse into actual date objects, you could always do: { thisIsADate: new Date('1995-12-17T03:24:00Z') } It would be simple enough for parsers in other languages to parse this into their own date objects. Much simpler than using regexs to find ISO strings.
    - kybernetikos 5y ago
      I think allowing a whitelisted set of constructors (so it's extensible, but with some standard ones) as types in a future JSON-like could be good. e.g. { birthdayParty: Date(1632817436514), sounds: Map([["cow", "moo"], ["fox", "?"]]), possibilities: Set(["she loves me", "she loves me not"]), aSymbol: Symbol("tag"), aBuffer: UInt8Array(ArrayBuffer([104, 101, 108, 108, 111])), } So you'd do something like const serialised = NuJSON.stringify(data) const result = NuJSON.parse(serialised, allowedConstructors, fallbackConstructor) And if allowedConstructors wasn't present, it'd default to including all the standard JS ones (Map,Set,Date,Symbol,ArrayBuffer etc). The fallback constructor would be used if there were data types in the data that didn't have matching allowed constructors. By default it would through an error. Of course, my ideal NuJSON would also include bigints, multiline strings, comments, bare keys (i.e. without having to wrap them in quotes). Stretch nuJSON would also include the ability to serialise circular graph structures, perhaps through the use of a Reference([up, up, "aSymbol"]) data type.
      - krapp 5y ago
        I know this is how Javascript is done nowadays but using constructors for maps and arrays just seems like unnecessary syntax to me. And if you're going to initialize an array buffer too, you might as well just not use JSON at all and send plain Javascript code over the wire. I think all JSON needs in this regard is type hinting. Let everything else be handled by the application: { birthdayParty: Date 1632817436514, sounds: String? { // zomgwtfbbq comments too cow:"moo", fox: null }, possibilities: ["she loves me", "she loves me not", 42], aSymbol: Symbol "tag", aBuffer: Uint8 [104, 101, 108, 108, 111] }
- alpaca128 5y ago
  I agree about the single quotes, but many use single quotes for strings in JS and so it's understandable to have this consistent.
- rbut 5y ago
  Because: ‘I am “really” angry’ Is much nicer than: “I am \”really\” angry”
  - peoplefromibiza 5y ago
    and now you have two problems is this any better? 'I\'m "really" angry, don\'t do it again!' in many languages single quotes are used as apostrophes and are very very common, much more common than double quotes.
    - kangalioo 5y ago
      Nobody's forcing you to use single quotes as delimiters. "I'm \"really\" angry, don't do it again!"
  - eptcyka 5y ago
    Json is not meant to be human readable or writeable.
    - SigmundA 5y ago
      Second sentence from json.org: "It is easy for humans to read and write."
    - jenscow 5y ago
      But JSON5 is.
    - krapp 5y ago
      All text based data formats are meant to be human readable and human writable, and humans read and write JSON all the time.
      - eptcyka 5y ago
        You wouldn't say that mammals write C all the time, would you? Front end development would be so much better if you could just spew json at people in a table.
- The_Colonel 5y ago
  Single quote strings are useful when the string contains many double quotes (e.g. XML with attributes).
- pawelduda 5y ago
  Useful when you need to input already double-quoted value. But it's a matter of taste still and nothing that we couldn't do before. Such changes will lead to meetings where programmers discuss JSON5 quoting choices (yes, it will be a thing).
alpaca128 5y ago
> Strings may include character escapes Wait, that wasn't possible before? I like it, most of the additions seem more like filling gaps in the original version. And the lack of trailing commas & comments have always annoyed me a bit. But as this is a library I'm guessing NPM doesn't support it for the package.json?
Cthulhu_ 5y ago
Is there an official standard body behind this (and json 6 mentioned in another comment), or is it a kind of loose / informal standard left up to libraries to implement? I mean comments and trailing commas will make JSON a bit more human friendly when used in e.g. configuration (package.json), but as a pure data exchange format it doesn't add much. Mind you, there's better data exchange formats than json, like XML (yes I said it) which can be transferred via a binary protocol (https://www.w3.org/TR/exi/ https://www.w3.org/TR/exi/) instead of the, when you think about it, awkward and inefficient data -> text format -> compression -> transfer -> decompress -> text format -> parse cycle of both 'traditional' XML and JSON both. I wouldn't be averse to the idea of browser manufacturers or standards bodies to come up with a more efficient data transfer method that can be human-read with the right tooling like browser development tools, but which is fully compressed binary and efficient on the line. I feel like tools like GRPC are a bit too far out there.
- deepsun 5y ago
  Msgpack and protobuf do that too. I believe the rise of JSON is attributed to that it's easily human-readable, and because Javascript.
  - lucideer 5y ago
    Not sure human-readability was a major consideration of JSON really, but maybe. One of the major considerations that many seem to miss today though was simplicity of parsing: it's a much more strict syntax than actual JS so there's a lot less ambiguity in parsing it. E.g. there's no need to have layered logic for recognizing unquoted identifiers, no need to check for multiple quote types on IDs & strings, consistent comma-ing etc. In general giving the author less options will make your parser simpler. This is notably the exact opposite of YAML's approach. JSON5 is nowhere near as bad as YAML, but it does seem to leaving behind some of the raison d'être of JSON. Like, I hate double-quoting in JS/JSON (personal bike-shed colour preference), but surely variable quoting characters is the worst of both worlds.
    - brundolf 5y ago
leecommamichael 5y ago
While I think this would make JSON more fun to edit by-hand, I don’t feel the breaking changes across the stack, and mixed adoption, are worth the benefits.
dobladov 5y ago
Having comments is probably the functionality I wanted the most.
- rk06 5y ago
  That is why I prefer jsonc. Which is quite sane and most json formatters (that I know of) support it
willvarfar 5y ago
json-ld files (json line delimited, means one json object per line) are used extensively in data processing. A lot of processing of these json-ld files uses normal builtins instead of special libraries eg in python doing a for line in or a stream map and the standard json lib etc. From a glance at this spec, it seems that where an object ends is no longer something that the normal file processing most languages possess work. Which is a problem. I’d be surprised if a extended-json ever got traction because everyone already has code that uses the lowest common denominator json parser and line splitting built into whatever language and libraries they are using and those they interchange with already use. Having said that, the pain points I wrestle with are lack of date types and how to safely pass large integers and currencies etc. Things not addressed in the json5 spec?
- xdfgh1112 5y ago
  I call it JSONL but yeah it's super useful. The ability to split and join using standard Unix tools, or just pipe through GNU parallel for automatic speedup without any boilerplate code
- Symbiote 5y ago
  JSON-LD is JSON Linked Data. What you describe seems to be called line-delimited JSON, LDJSON, NDJSON or JSONL. https://en.wikipedia.org/wiki/JSON_streaming https://en.wikipedia.org/wiki/JSON_streaming
mickael-kerjean 5y ago
> "Strings may be single quoted." What's the point? I cringe every time a project uses both double quote and single quote, a mix of semicolon and no semicolon and a mix of tabs and space, .... Which one to pick isn't relevant as soon as the code base is consistent
- jeppester 5y ago
  Maybe they don't think it should be up to them to decide which one you should go with.
  - selcuka 5y ago
    What's the point of standards then?
    - dane-pgp 5y ago
      To support people's use cases?
    - xboxnolifes 5y ago
      The standard says you can use either. Why do you disagree with the standard?
      - deleted 5y ago
        [deleted]
      - selcuka 5y ago
        I disagree with the OP, not the standard. The standard says you can't use backticks for quoting strings, so it's still "up to them to decide which one you should go with".
- itsibitzi 5y ago
  It allows you to put double quotes in the string without escaping them, which is pretty nice.
q3k 5y ago
… could’ve at least disallowed for one of the most batshit crazy aspects of JSON, the legal but undefined behaviour of duplicate keys in objects. > An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable.
- esnard 5y ago
  It would lose its "backwards compatible" property though.
  - lifthrasiir 5y ago
    This can be solved if you base JSON5 on I-JSON (RFC 7493) instead of JSON (RFC 8259). Many (but not all) JSON implementations actually expect I-JSON, at least for object keys.
  - dane-pgp 5y ago
    Having a defined, predictable behaviour in JSON5 doesn't seem like it would break backwards compatibility with JSON's undefined, unpredictable behaviour. I don't think someone with an existing JSON document would complain that a JSON5 parser behaved "too predictably" when interpreting their document.
    - brundolf 5y ago
      It could change, and therefore break, the real-world behavior of a given parser that some code is knowingly or unknowingly relying on.
      - dane-pgp 5y ago
        So could switching to another JSON parser. The response of the parser writer should be "I detected a bug in your code for you. You're welcome."
bullen 5y ago
I still use the original Java JSON that I compiled from Douglas source back in ~2008 maybe. It hasen't changed since then and it will never need to change ever in the history of mankind. Problem solved! Edit: Maybe this solves another problem though, but I doubt it!
mnd999 5y ago
I know it’s not trendy but consider XML and schema at this point. XML allows all this to be expressed and more and schema allows the creation of integration contracts that can be validated at both ends. Tooling and libraries are mature.
- IshKebab 5y ago
  XML has two big problems: 1. It's super verbose. Everybody hates writing it. And yes, people do write JSON by hand. 2. It has a weird and confusing data model with both attributes and child elements. Do you do <foo a="1"/> or <foo><a>1</a></foo>? In many many cases it's ambiguous and you end up with a weird mix, whereas in JSON it's obvious and easy.
- Deukhoofd 5y ago
  I want to love XML schemas, but to call them mature is a stretch. There's a bunch of important features hidden behind XSD 1.1, which is almost 10 years old by now, yet most software that validates XML on schemas does not support that yet.
  - DonHopkins 5y ago
    The XML Schema standard is terrible, and its mistakes and weaknesses were what drove James Clark and Murata Makoto to develop RELAX NG (REgular LAnguage for XML Next Generation). https://en.wikipedia.org/wiki/RELAX_NG https://en.wikipedia.org/wiki/RELAX_NG RELAX NG has a clearly focused sound mathematical underpinning: regular expressions applied to trees, while XML Schema is an ad-hoc hot mess designed by committee. https://en.wikipedia.org/wiki/XML_schema#RELAX_NG https://en.wikipedia.org/wiki/XML_schema#RELAX_NG Any decent JSON schema language should take its cues and learn from the design of RELAX NG, and not repeat the mistakes of XML Schema. Makoto Murata raised some critical points about XML Schema, which was beyond repair, so they both invented new regexp-based schema languages to address those problems, and combined their respective work into Relax/NG: https://en.wikipedia.org/wiki/Makoto_Murata#RELAX_and_RELAX_NG https://en.wikipedia.org/wiki/Makoto_Murata#RELAX_and_RELAX_... >Some people, including Murata and James Clark, had critical attitudes toward XML Schema. XML Schema is a modern XML schema language designed by W3C XML Schema Working Group. W3C intended XML Schema to supersede traditional DTD (Document Type Definition). XML Schema supports so many features that its specification is large and complex. Murata, James Clark and those who criticised XML Schema, pointed out the following: >It is difficult to implement all features of XML Schema. >It is difficult for engineers to read and write XML Schema definitions. >It does not permit nondeterministic content models. James Clark compared Relax NG to XML Schema and its predecessor, SGML Document Type Definitions, in his paper, "The Design of RELAX NG": https://relaxng.org/jclark/design.html https://relaxng.org/jclark/design.html James Clark has a huge amount of experience designing and implementing SGML and XML standards: https://en.wikipedia.org/wiki/James_Clark_(programmer) https://en.wikipedia.org/wiki/James_Clark_(programmer) I've written about XML Schema, Relax NG, and James Clark eariler: https://news.ycombinator.com/item?id=26122033 https://news.ycombinator.com/item?id=26122033 >Some of the most incredibly awfully bad XML DSLs are official standards, themselves. COUGH XMLSchema COUGH: [...] https://news.ycombinator.com/item?id=22756875 https://news.ycombinator.com/item?id=22756875 >James Clark used Haskell to design and implement an algorithm for validating Relax NG XML schemas (he co-designed Relax NG, and designed its predecessor TREX), to work the ideas out before re-implementing it in (many many more lines of tedious brittle) Java (JING). Haskel works wonderfully as a design and standard definition language, that way. [...] A Triumph of Simplicity: James Clark on Markup Languages and XML https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/184404686 https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-... >If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade. This article "Schema Wars: XML Schema vs. Relax NG (1/2) - exploring XML" enumerates some of James Clark's objections to XML Schema: https://web.archive.org/web/20190403171512/http://webreference.com/xml/column59/index-2.html https://web.archive.org/web/20190403171512/http://webreferen... >James Clark, leader of the technical committee at OASIS for RELAX NG, and author of one of the first XML parsers, recently described the problems of the XML Schema language in a newsgroup posting: >1) XML Schema definitions require considerable expertise to understand and can contain quite a few surprises. >As an example, if you derive a complex type by restriction you have to specify the new restricted content model explicitly. However, attributes are treated in the opposite way: by default you get all the attributes and you have to explicitly rule out the ones you don't want. A similar inconsistency exists in that if you merge two attribute definitions you get the union of the concrete attribute definitions, but the intersection of attribute wildcards (specified by the anyAttribute element). While these might be convenient choices for the specification, it easily creates confusion for the human reader of XML schemas. >2) The XML Schema Recommendation is hard to read and understand. >To avoid the possible misinterpretations mentioned above you might have to reference the specification in order to fully understand a specific schema definition. I have to agree with Clark that the W3C's XML Schema Recommendation is by far the hardest to read and understand, making it even more difficult to make sense of a particular schema presented to you. >3) W3C XML Schema's support for attributes provides no advance over DTDs. >As with DTDs, W3C XML Schema only allows the specification of whether attributes are required or optional. There is no way to specify more complex constraints between attributes or between attributes or elements, for instance that either attribute X or attribute Y is allowed or that either attribute X or element Y is allowed. The mechanism that is used to constrain the co-occurrence of child elements should be extended to attributes and the combinations of attributes and child elements. >4) W3C XML Schema provides very weak support for unordered content. >When the designer of an XML vocabulary does not wish to force child elements to occur in a particular order, it can be impractical to describe the XML vocabulary using XML Schema, because XML Schema imposes such limitations. >5) Datatype handling in W3C XML Schema lacks modularity. >W3C XML Schema is tied to the single collection of datatypes defined in Part 2 of W3C XML Schema. Yet this collection of datatypes is a very ad-hoc collection. It includes datatypes of highly debatable relevance (gYearMonth, gDay etc). Yet it lacks many datatypes that are important for many applications. A modular approach where a schema language can be combined with one or more standard collections of datatypes, some general-purpose and some domain-specific, is called for here. >6) W3C XML Schema does not define a single notion of validity of a document with respect to a schema. >There are different varieties of validation (lax and strict) and many different ways to validate a document against a schema. From a W3C XML Schema alone, it is not possible to know what is a valid document. For instance there is no way to specify what is allowed as the root element. >7) Magic schema attributes in documents >W3C XML Schema provides the xsi:schemaLocation attribute, which allows an XML document instance to indicate the schema that should be used to validate the document. This creates problems with security (the destination might have changed or tampered with), interoperability (use of schemaLocation is optional) and "purity" of schema definition: There is no way to prevent the document containing magic xsi:* attributes, so the use of W3C XML Schema "infects" the grammar you are defining. >8) Another problematic area in W3C XML Schema is the support for infoset augmentation, such as default attributes. >Apart from being a violation of modularity, this tends to cause interoperability problems, because it leads to the possibility of the application getting different information depending on whether or not validation has been performed.
jokoon 5y ago
I have to admit that I once used python repr() as a way to pass json data. It worked. I think.
- eptcyka 5y ago
  I've heard horror stories from a friend who had to fix such code introduced by a contractor. Management didn't want to throw any of it awayz because they paid a lot of money to the contractor. Of course broke in a hard to debug fashion.
- dapids 5y ago
  It will work only as long as the object(s) interpreted by repr are serialzable by JSON, which is not a sound approach, unless you write a any-type serializer.
scanr 5y ago
The syntax for line breaks make it incompatible with JavaScript. Probably not terrible because doing an eval of untrusted json would be a bad idea but they could have used back ticks which would have these useful properties: - still JavaScript - fewer characters
jenscow 5y ago
Killer feature: comments. Sure, for APIs comments are bad. However, for configuration things are so much better when you can document or temporarily remove things, without having hacks which pollute the data. Trailing commas are also nice to have - although we have linters for that, unfortunately some people think they're too good to need a linter.
- wmanley 5y ago
  > Trailing commas are also nice to have - although we have linters for that, unfortunately some people think they're too good to need a linter. IMO the real value in trailing commas is that it's easier to produce simple JSON programmatically.
perfunctory 5y ago
No booleans?
- zkldi 5y ago
  It's a superset of JSON, so it should natively support true and false identifiers.
antihero 5y ago
Why wouldn't they follow ECMA and use backticks for multiline strings? Ah, it's based on ECMAScript 5.1. I guess we can wait for a JSON6, then.
silvestrov 5y ago
I'd love if they added support for dates, e.g. { justDate: @2020-02-08 } { dateAndTime: @2007-03-01T13:00:00Z } { justTime: @@13:00:00 }
- jbverschoor 5y ago
  Well, that has nothing to do with "Javascript" notation So first get that kind of notation into javascript, then wait 15 years
  - deleted 5y ago
    [deleted]
lovasoa 5y ago
A JSON5 parser comes in handy for scraping, when you want to extract data that is embedded directly inside the javascript source of a website. But I wouldn't ever use JSON5 over JSON for serialization, or over YAML for parsing a configuration file.
thefounder 5y ago
>> by expanding its syntax to include some productions from ECMAScript 5.1. I think at this point a new json spec should have little/nothing to do with javascript.
andix 5y ago
Don't we already have Yet Another Markup Language (YAML)? :D
snshn 5y ago
what a piece of shit...
ralfn 5y ago
I like that it has a new name. I've seen too many stupid libraries support their own superset while still calling it JSON (looking at you, Python and .NET ecosystem!) It's a standard. If we change it, it needs a new name.. However, I am worried that this new standard is harder for languages and ecosystems to support consistently, because it requires a much more involved parser. Then again, if YAML can do it.. (and that must be a parser created in the depths of hell).
beardyw 5y ago
"JSON (JavaScript Object Notation) is a lightweight data-interchange format." So says JSON.org for as long as anyone can remember. Why is anyone caring about using single or double quotes, or wanting trailing commas? It solves no problems. It seems to me the only answer is it's for manually created JSON. That is, all of this is for people whose only exposure to JSON is doing some config in vscode. It adds nothing else. Call it JSON-CONFIG and leave well enough alone.
- SigmundA 5y ago
  Keep going, next sentence from JSON.org: "It is easy for humans to read and write. It is easy for machines to parse and generate. " Non-quoted keys is easier to read and write by humans, trailing commas are easier for a machine to write, single quotes can make it easier for a human to read or write. Comments help humans read and write. I remember when it was javascript object notation and that stuff was allowed because thats what javascript allows and felt simple and effective for both human and machine, then it became strict json, what a step backwards.
coolgoose 5y ago
Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.
- spicybright 5y ago
  It's true. I doubt this spec will pick up even a little traction either since it's not backwards compatible. You trade slightly more concrete data structures for hard incompatibility. Maybe an internal api could leverage this in some way? But it really isn't that hard to wrap hex, floating points, etc. in quotes and parse that server side. Any application that's not a pet project should be using json schemas anyways, which is the layer you could put your custom datatypes into.
- snorkel 5y ago
  If I had to pick one feature add, it’d be allow trailing commas. That would make serializing a bit easier and less error prone.
  - colejohnson66 5y ago
    It would also make slightly nicer diffs
- tootie 5y ago
  And XML is a very battle-tested alternative that supports every conceivable edge case and arbitrary depths of strictness and validation. There was soooo much energy poured in to making XML the One Format To Rule Them All. It has so many advanced features like strict definitions, includes syntax, support for mixed content, entities and references, comment syntax. But it turns out that 99% of users never needed any of that and just wanted nested key-value pairs.
  - kevinmgranger 5y ago
    That and any serialization format that has security implications is doomed to fail (or at least be derided).
hakre 5y ago
Previously on HN: The JSON5 Data Interchange Format (https://spec.json5.org/ https://spec.json5.org/) - 2 Years ago - 0 Comments - https://news.ycombinator.com/item?id=21113613 https://news.ycombinator.com/item?id=21113613
deleted 5y ago
[deleted]
udev 5y ago
Should've named it JackSON5.
kybernetikos 5y ago
These days, JS has moved on while JSON has remained stuck in the past. There are some fairly important ones it'd be great to get a standard format for in JSON. e.g. JSON.stringify({z: 1n}) Also, round tripping ArrayBuffers, Maps, Sets, Symbols and Dates would be really useful. Sadly JSON5 doesn't address those. I'd quite like a next gen JSON not to get upset on circular references too, although that would most likely require some sort of link or reference data type.
- pitaj 5y ago
  Bigints, dates, and buffers I can understand to a degree. Sets can easily be serialized as a json array. Maps can be serialized as a json array of arrays or as a single json dictionary if the key types are compatible.
  - kybernetikos 5y ago
    Everything can be serialised as something else with various degress of difficulty, but one of the beauties of JSON was that it had support for most of the native types of javascript. It's nice not to have to write special logic to serialise / deserialise the way you want. In particular, the ability to round trip all the standard types would be really useful.
ltbarcly3 5y ago
If you're going to the trouble of using something not backwards compatible with json, use something that isn't crap.
avgcorrection 5y ago
> Strings may span multiple lines by escaping new line characters. What if the escape character comes before a trailing whitespace? Like this (`_` is whitespace): "hello,\_\n Will that still escape the newline?
filoeleven 5y ago
Some luckier alternate universes have standardized on EDN instead. https://github.com/edn-format/edn https://github.com/edn-format/edn
elcritch 5y ago
Somewhat related, I was toying around with what an html5 based csv alternative could look like and called it hsv5 partly as a play on json5 and hdf5. https://github.com/elcritch/hsv5 https://github.com/elcritch/hsv5
deepsun 5y ago
Why only positive/negative infinity, but not positive/negative zero?
- lamontcg 5y ago
  JSON5 was proposed long before positive/negative zero got trendy on HN
  - deepsun 5y ago
    IEEE 754 had them for longer?
johnthescott 5y ago
"The standard has to be sufficiently simple that it makes sense to have multiple implementations." -James Clark
dang 5y ago
Past related threads: JSON5 – a superset of JSON with comments, multiline string, trailing comma, etc. - https://news.ycombinator.com/item?id=22598401 https://news.ycombinator.com/item?id=22598401 - March 2020 (1 comment) JSON5: JSON for humans - https://news.ycombinator.com/item?id=17375850 https://news.ycombinator.com/item?id=17375850 - June 2018 (3 comments) JSON5 – JSON for the ES5 Era - https://news.ycombinator.com/item?id=10956943 https://news.ycombinator.com/item?id=10956943 - Jan 2016 (8 comments) JSON5 is a proposed extension to JSON - https://news.ycombinator.com/item?id=7325735 https://news.ycombinator.com/item?id=7325735 - March 2014 (246 comments) Show HN: JSON5 — modern JSON - https://news.ycombinator.com/item?id=4031699 https://news.ycombinator.com/item?id=4031699 - May 2012 (84 comments)
mindless_solips 5y ago
These are the monsters who told us "XML is too bloated" and "who'd ever want a self-describing, self-transformable interchange format anyway?" The more I see things like JSONSchema and JSON5 get away from Crockford's original overly simplistic syntax, the more I think we can all agree with Richard Gabriel. Worse Is Better!

100 points by gjvc 5y ago

develatio 5y ago

IIRC there is a JSON6 format which adds features and improvements on top of JSON5.

gchq-7703 5y ago
HJSON [0] is also another format that tries to make it easier for humans to read / write json. [0] https://hjson.github.io/ https://hjson.github.io/

roncohen 5y ago

Couple of gripes: - Still no date type - Why make it more loose? Like "Strings may be single quoted." doesn't bring any value.

AlfeG 5y ago
It brings it closer to JavaScript behavior I guess. I guess it's nice to have ability to copy random js object declaration to actual json without editing
Cthulhu_ 5y ago
What would a date type look like? An ISO-8601 string is probably as good as it'll get, else you end up with an object containing loads of additional information like timezones, offsets, etc. There's also https://json-schema.org/understanding-json-schema/reference/string.html#dates-and-times https://json-schema.org/understanding-json-schema/reference/... for a formalized date format in JSON. The looseness seems to be aimed at human authors who want to write JSON as if it were JS, so mainly package.json. But, json is not ideal for configuration for multiple reasons.
- rbut 5y ago
  If you wanted JSON to parse into actual date objects, you could always do: { thisIsADate: new Date('1995-12-17T03:24:00Z') } It would be simple enough for parsers in other languages to parse this into their own date objects. Much simpler than using regexs to find ISO strings.
  - kybernetikos 5y ago
    I think allowing a whitelisted set of constructors (so it's extensible, but with some standard ones) as types in a future JSON-like could be good. e.g. { birthdayParty: Date(1632817436514), sounds: Map([["cow", "moo"], ["fox", "?"]]), possibilities: Set(["she loves me", "she loves me not"]), aSymbol: Symbol("tag"), aBuffer: UInt8Array(ArrayBuffer([104, 101, 108, 108, 111])), } So you'd do something like const serialised = NuJSON.stringify(data) const result = NuJSON.parse(serialised, allowedConstructors, fallbackConstructor) And if allowedConstructors wasn't present, it'd default to including all the standard JS ones (Map,Set,Date,Symbol,ArrayBuffer etc). The fallback constructor would be used if there were data types in the data that didn't have matching allowed constructors. By default it would through an error. Of course, my ideal NuJSON would also include bigints, multiline strings, comments, bare keys (i.e. without having to wrap them in quotes). Stretch nuJSON would also include the ability to serialise circular graph structures, perhaps through the use of a Reference([up, up, "aSymbol"]) data type.
    - krapp 5y ago
      I know this is how Javascript is done nowadays but using constructors for maps and arrays just seems like unnecessary syntax to me. And if you're going to initialize an array buffer too, you might as well just not use JSON at all and send plain Javascript code over the wire. I think all JSON needs in this regard is type hinting. Let everything else be handled by the application: { birthdayParty: Date 1632817436514, sounds: String? { // zomgwtfbbq comments too cow:"moo", fox: null }, possibilities: ["she loves me", "she loves me not", 42], aSymbol: Symbol "tag", aBuffer: Uint8 [104, 101, 108, 108, 111] }
alpaca128 5y ago
I agree about the single quotes, but many use single quotes for strings in JS and so it's understandable to have this consistent.
rbut 5y ago
Because: ‘I am “really” angry’ Is much nicer than: “I am \”really\” angry”
- peoplefromibiza 5y ago
  and now you have two problems is this any better? 'I\'m "really" angry, don\'t do it again!' in many languages single quotes are used as apostrophes and are very very common, much more common than double quotes.
  - kangalioo 5y ago
    Nobody's forcing you to use single quotes as delimiters. "I'm \"really\" angry, don't do it again!"
- eptcyka 5y ago
  Json is not meant to be human readable or writeable.
  - SigmundA 5y ago
    Second sentence from json.org: "It is easy for humans to read and write."
  - jenscow 5y ago
    But JSON5 is.
  - krapp 5y ago
    All text based data formats are meant to be human readable and human writable, and humans read and write JSON all the time.
    - eptcyka 5y ago
      You wouldn't say that mammals write C all the time, would you? Front end development would be so much better if you could just spew json at people in a table.
The_Colonel 5y ago
Single quote strings are useful when the string contains many double quotes (e.g. XML with attributes).
pawelduda 5y ago
Useful when you need to input already double-quoted value. But it's a matter of taste still and nothing that we couldn't do before. Such changes will lead to meetings where programmers discuss JSON5 quoting choices (yes, it will be a thing).

alpaca128 5y ago

> Strings may include character escapes Wait, that wasn't possible before? I like it, most of the additions seem more like filling gaps in the original version. And the lack of trailing commas & comments have always annoyed me a bit. But as this is a library I'm guessing NPM doesn't support it for the package.json?

Cthulhu_ 5y ago

Is there an official standard body behind this (and json 6 mentioned in another comment), or is it a kind of loose / informal standard left up to libraries to implement? I mean comments and trailing commas will make JSON a bit more human friendly when used in e.g. configuration (package.json), but as a pure data exchange format it doesn't add much. Mind you, there's better data exchange formats than json, like XML (yes I said it) which can be transferred via a binary protocol (https://www.w3.org/TR/exi/ https://www.w3.org/TR/exi/) instead of the, when you think about it, awkward and inefficient data -> text format -> compression -> transfer -> decompress -> text format -> parse cycle of both 'traditional' XML and JSON both. I wouldn't be averse to the idea of browser manufacturers or standards bodies to come up with a more efficient data transfer method that can be human-read with the right tooling like browser development tools, but which is fully compressed binary and efficient on the line. I feel like tools like GRPC are a bit too far out there.

deepsun 5y ago
Msgpack and protobuf do that too. I believe the rise of JSON is attributed to that it's easily human-readable, and because Javascript.
- lucideer 5y ago
  Not sure human-readability was a major consideration of JSON really, but maybe. One of the major considerations that many seem to miss today though was simplicity of parsing: it's a much more strict syntax than actual JS so there's a lot less ambiguity in parsing it. E.g. there's no need to have layered logic for recognizing unquoted identifiers, no need to check for multiple quote types on IDs & strings, consistent comma-ing etc. In general giving the author less options will make your parser simpler. This is notably the exact opposite of YAML's approach. JSON5 is nowhere near as bad as YAML, but it does seem to leaving behind some of the raison d'être of JSON. Like, I hate double-quoting in JS/JSON (personal bike-shed colour preference), but surely variable quoting characters is the worst of both worlds.
  - brundolf 5y ago

leecommamichael 5y ago

While I think this would make JSON more fun to edit by-hand, I don’t feel the breaking changes across the stack, and mixed adoption, are worth the benefits.

dobladov 5y ago

Having comments is probably the functionality I wanted the most.

rk06 5y ago
That is why I prefer jsonc. Which is quite sane and most json formatters (that I know of) support it

willvarfar 5y ago

json-ld files (json line delimited, means one json object per line) are used extensively in data processing. A lot of processing of these json-ld files uses normal builtins instead of special libraries eg in python doing a for line in or a stream map and the standard json lib etc. From a glance at this spec, it seems that where an object ends is no longer something that the normal file processing most languages possess work. Which is a problem. I’d be surprised if a extended-json ever got traction because everyone already has code that uses the lowest common denominator json parser and line splitting built into whatever language and libraries they are using and those they interchange with already use. Having said that, the pain points I wrestle with are lack of date types and how to safely pass large integers and currencies etc. Things not addressed in the json5 spec?

xdfgh1112 5y ago
I call it JSONL but yeah it's super useful. The ability to split and join using standard Unix tools, or just pipe through GNU parallel for automatic speedup without any boilerplate code
Symbiote 5y ago
JSON-LD is JSON Linked Data. What you describe seems to be called line-delimited JSON, LDJSON, NDJSON or JSONL. https://en.wikipedia.org/wiki/JSON_streaming https://en.wikipedia.org/wiki/JSON_streaming

mickael-kerjean 5y ago

> "Strings may be single quoted." What's the point? I cringe every time a project uses both double quote and single quote, a mix of semicolon and no semicolon and a mix of tabs and space, .... Which one to pick isn't relevant as soon as the code base is consistent

jeppester 5y ago
Maybe they don't think it should be up to them to decide which one you should go with.
- selcuka 5y ago
  What's the point of standards then?
  - dane-pgp 5y ago
    To support people's use cases?
  - xboxnolifes 5y ago
    The standard says you can use either. Why do you disagree with the standard?
    - deleted 5y ago
      [deleted]
    - selcuka 5y ago
      I disagree with the OP, not the standard. The standard says you can't use backticks for quoting strings, so it's still "up to them to decide which one you should go with".
itsibitzi 5y ago
It allows you to put double quotes in the string without escaping them, which is pretty nice.

q3k 5y ago

… could’ve at least disallowed for one of the most batshit crazy aspects of JSON, the legal but undefined behaviour of duplicate keys in objects. > An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable.

esnard 5y ago
It would lose its "backwards compatible" property though.
- lifthrasiir 5y ago
  This can be solved if you base JSON5 on I-JSON (RFC 7493) instead of JSON (RFC 8259). Many (but not all) JSON implementations actually expect I-JSON, at least for object keys.
- dane-pgp 5y ago
  Having a defined, predictable behaviour in JSON5 doesn't seem like it would break backwards compatibility with JSON's undefined, unpredictable behaviour. I don't think someone with an existing JSON document would complain that a JSON5 parser behaved "too predictably" when interpreting their document.
  - brundolf 5y ago
    It could change, and therefore break, the real-world behavior of a given parser that some code is knowingly or unknowingly relying on.
    - dane-pgp 5y ago
      So could switching to another JSON parser. The response of the parser writer should be "I detected a bug in your code for you. You're welcome."

bullen 5y ago

I still use the original Java JSON that I compiled from Douglas source back in ~2008 maybe. It hasen't changed since then and it will never need to change ever in the history of mankind. Problem solved! Edit: Maybe this solves another problem though, but I doubt it!

mnd999 5y ago

I know it’s not trendy but consider XML and schema at this point. XML allows all this to be expressed and more and schema allows the creation of integration contracts that can be validated at both ends. Tooling and libraries are mature.

IshKebab 5y ago
XML has two big problems: 1. It's super verbose. Everybody hates writing it. And yes, people do write JSON by hand. 2. It has a weird and confusing data model with both attributes and child elements. Do you do <foo a="1"/> or <foo><a>1</a></foo>? In many many cases it's ambiguous and you end up with a weird mix, whereas in JSON it's obvious and easy.
Deukhoofd 5y ago
I want to love XML schemas, but to call them mature is a stretch. There's a bunch of important features hidden behind XSD 1.1, which is almost 10 years old by now, yet most software that validates XML on schemas does not support that yet.
- DonHopkins 5y ago
  The XML Schema standard is terrible, and its mistakes and weaknesses were what drove James Clark and Murata Makoto to develop RELAX NG (REgular LAnguage for XML Next Generation). https://en.wikipedia.org/wiki/RELAX_NG https://en.wikipedia.org/wiki/RELAX_NG RELAX NG has a clearly focused sound mathematical underpinning: regular expressions applied to trees, while XML Schema is an ad-hoc hot mess designed by committee. https://en.wikipedia.org/wiki/XML_schema#RELAX_NG https://en.wikipedia.org/wiki/XML_schema#RELAX_NG Any decent JSON schema language should take its cues and learn from the design of RELAX NG, and not repeat the mistakes of XML Schema. Makoto Murata raised some critical points about XML Schema, which was beyond repair, so they both invented new regexp-based schema languages to address those problems, and combined their respective work into Relax/NG: https://en.wikipedia.org/wiki/Makoto_Murata#RELAX_and_RELAX_NG https://en.wikipedia.org/wiki/Makoto_Murata#RELAX_and_RELAX_... >Some people, including Murata and James Clark, had critical attitudes toward XML Schema. XML Schema is a modern XML schema language designed by W3C XML Schema Working Group. W3C intended XML Schema to supersede traditional DTD (Document Type Definition). XML Schema supports so many features that its specification is large and complex. Murata, James Clark and those who criticised XML Schema, pointed out the following: >It is difficult to implement all features of XML Schema. >It is difficult for engineers to read and write XML Schema definitions. >It does not permit nondeterministic content models. James Clark compared Relax NG to XML Schema and its predecessor, SGML Document Type Definitions, in his paper, "The Design of RELAX NG": https://relaxng.org/jclark/design.html https://relaxng.org/jclark/design.html James Clark has a huge amount of experience designing and implementing SGML and XML standards: https://en.wikipedia.org/wiki/James_Clark_(programmer) https://en.wikipedia.org/wiki/James_Clark_(programmer) I've written about XML Schema, Relax NG, and James Clark eariler: https://news.ycombinator.com/item?id=26122033 https://news.ycombinator.com/item?id=26122033 >Some of the most incredibly awfully bad XML DSLs are official standards, themselves. COUGH XMLSchema COUGH: [...] https://news.ycombinator.com/item?id=22756875 https://news.ycombinator.com/item?id=22756875 >James Clark used Haskell to design and implement an algorithm for validating Relax NG XML schemas (he co-designed Relax NG, and designed its predecessor TREX), to work the ideas out before re-implementing it in (many many more lines of tedious brittle) Java (JING). Haskel works wonderfully as a design and standard definition language, that way. [...] A Triumph of Simplicity: James Clark on Markup Languages and XML https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/184404686 https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-... >If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade. This article "Schema Wars: XML Schema vs. Relax NG (1/2) - exploring XML" enumerates some of James Clark's objections to XML Schema: https://web.archive.org/web/20190403171512/http://webreference.com/xml/column59/index-2.html https://web.archive.org/web/20190403171512/http://webreferen... >James Clark, leader of the technical committee at OASIS for RELAX NG, and author of one of the first XML parsers, recently described the problems of the XML Schema language in a newsgroup posting: >1) XML Schema definitions require considerable expertise to understand and can contain quite a few surprises. >As an example, if you derive a complex type by restriction you have to specify the new restricted content model explicitly. However, attributes are treated in the opposite way: by default you get all the attributes and you have to explicitly rule out the ones you don't want. A similar inconsistency exists in that if you merge two attribute definitions you get the union of the concrete attribute definitions, but the intersection of attribute wildcards (specified by the anyAttribute element). While these might be convenient choices for the specification, it easily creates confusion for the human reader of XML schemas. >2) The XML Schema Recommendation is hard to read and understand. >To avoid the possible misinterpretations mentioned above you might have to reference the specification in order to fully understand a specific schema definition. I have to agree with Clark that the W3C's XML Schema Recommendation is by far the hardest to read and understand, making it even more difficult to make sense of a particular schema presented to you. >3) W3C XML Schema's support for attributes provides no advance over DTDs. >As with DTDs, W3C XML Schema only allows the specification of whether attributes are required or optional. There is no way to specify more complex constraints between attributes or between attributes or elements, for instance that either attribute X or attribute Y is allowed or that either attribute X or element Y is allowed. The mechanism that is used to constrain the co-occurrence of child elements should be extended to attributes and the combinations of attributes and child elements. >4) W3C XML Schema provides very weak support for unordered content. >When the designer of an XML vocabulary does not wish to force child elements to occur in a particular order, it can be impractical to describe the XML vocabulary using XML Schema, because XML Schema imposes such limitations. >5) Datatype handling in W3C XML Schema lacks modularity. >W3C XML Schema is tied to the single collection of datatypes defined in Part 2 of W3C XML Schema. Yet this collection of datatypes is a very ad-hoc collection. It includes datatypes of highly debatable relevance (gYearMonth, gDay etc). Yet it lacks many datatypes that are important for many applications. A modular approach where a schema language can be combined with one or more standard collections of datatypes, some general-purpose and some domain-specific, is called for here. >6) W3C XML Schema does not define a single notion of validity of a document with respect to a schema. >There are different varieties of validation (lax and strict) and many different ways to validate a document against a schema. From a W3C XML Schema alone, it is not possible to know what is a valid document. For instance there is no way to specify what is allowed as the root element. >7) Magic schema attributes in documents >W3C XML Schema provides the xsi:schemaLocation attribute, which allows an XML document instance to indicate the schema that should be used to validate the document. This creates problems with security (the destination might have changed or tampered with), interoperability (use of schemaLocation is optional) and "purity" of schema definition: There is no way to prevent the document containing magic xsi:* attributes, so the use of W3C XML Schema "infects" the grammar you are defining. >8) Another problematic area in W3C XML Schema is the support for infoset augmentation, such as default attributes. >Apart from being a violation of modularity, this tends to cause interoperability problems, because it leads to the possibility of the application getting different information depending on whether or not validation has been performed.

jokoon 5y ago

I have to admit that I once used python repr() as a way to pass json data. It worked. I think.

eptcyka 5y ago
I've heard horror stories from a friend who had to fix such code introduced by a contractor. Management didn't want to throw any of it awayz because they paid a lot of money to the contractor. Of course broke in a hard to debug fashion.
dapids 5y ago
It will work only as long as the object(s) interpreted by repr are serialzable by JSON, which is not a sound approach, unless you write a any-type serializer.

scanr 5y ago

The syntax for line breaks make it incompatible with JavaScript. Probably not terrible because doing an eval of untrusted json would be a bad idea but they could have used back ticks which would have these useful properties: - still JavaScript - fewer characters

jenscow 5y ago

Killer feature: comments. Sure, for APIs comments are bad. However, for configuration things are so much better when you can document or temporarily remove things, without having hacks which pollute the data. Trailing commas are also nice to have - although we have linters for that, unfortunately some people think they're too good to need a linter.

wmanley 5y ago
> Trailing commas are also nice to have - although we have linters for that, unfortunately some people think they're too good to need a linter. IMO the real value in trailing commas is that it's easier to produce simple JSON programmatically.

perfunctory 5y ago

No booleans?

zkldi 5y ago
It's a superset of JSON, so it should natively support true and false identifiers.

antihero 5y ago

Why wouldn't they follow ECMA and use backticks for multiline strings? Ah, it's based on ECMAScript 5.1. I guess we can wait for a JSON6, then.

silvestrov 5y ago

I'd love if they added support for dates, e.g. { justDate: @2020-02-08 } { dateAndTime: @2007-03-01T13:00:00Z } { justTime: @@13:00:00 }

jbverschoor 5y ago
Well, that has nothing to do with "Javascript" notation So first get that kind of notation into javascript, then wait 15 years
- deleted 5y ago
  [deleted]

lovasoa 5y ago

A JSON5 parser comes in handy for scraping, when you want to extract data that is embedded directly inside the javascript source of a website. But I wouldn't ever use JSON5 over JSON for serialization, or over YAML for parsing a configuration file.

thefounder 5y ago

>> by expanding its syntax to include some productions from ECMAScript 5.1. I think at this point a new json spec should have little/nothing to do with javascript.

andix 5y ago

Don't we already have Yet Another Markup Language (YAML)? :D

snshn 5y ago

what a piece of shit...

ralfn 5y ago

I like that it has a new name. I've seen too many stupid libraries support their own superset while still calling it JSON (looking at you, Python and .NET ecosystem!) It's a standard. If we change it, it needs a new name.. However, I am worried that this new standard is harder for languages and ecosystems to support consistently, because it requires a much more involved parser. Then again, if YAML can do it.. (and that must be a parser created in the depths of hell).

beardyw 5y ago

"JSON (JavaScript Object Notation) is a lightweight data-interchange format." So says JSON.org for as long as anyone can remember. Why is anyone caring about using single or double quotes, or wanting trailing commas? It solves no problems. It seems to me the only answer is it's for manually created JSON. That is, all of this is for people whose only exposure to JSON is doing some config in vscode. It adds nothing else. Call it JSON-CONFIG and leave well enough alone.

SigmundA 5y ago
Keep going, next sentence from JSON.org: "It is easy for humans to read and write. It is easy for machines to parse and generate. " Non-quoted keys is easier to read and write by humans, trailing commas are easier for a machine to write, single quotes can make it easier for a human to read or write. Comments help humans read and write. I remember when it was javascript object notation and that stuff was allowed because thats what javascript allows and felt simple and effective for both human and machine, then it became strict json, what a step backwards.

coolgoose 5y ago

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

spicybright 5y ago
It's true. I doubt this spec will pick up even a little traction either since it's not backwards compatible. You trade slightly more concrete data structures for hard incompatibility. Maybe an internal api could leverage this in some way? But it really isn't that hard to wrap hex, floating points, etc. in quotes and parse that server side. Any application that's not a pet project should be using json schemas anyways, which is the layer you could put your custom datatypes into.
snorkel 5y ago
If I had to pick one feature add, it’d be allow trailing commas. That would make serializing a bit easier and less error prone.
- colejohnson66 5y ago
  It would also make slightly nicer diffs
tootie 5y ago
And XML is a very battle-tested alternative that supports every conceivable edge case and arbitrary depths of strictness and validation. There was soooo much energy poured in to making XML the One Format To Rule Them All. It has so many advanced features like strict definitions, includes syntax, support for mixed content, entities and references, comment syntax. But it turns out that 99% of users never needed any of that and just wanted nested key-value pairs.
- kevinmgranger 5y ago
  That and any serialization format that has security implications is doomed to fail (or at least be derided).

hakre 5y ago

Previously on HN: The JSON5 Data Interchange Format (https://spec.json5.org/ https://spec.json5.org/) - 2 Years ago - 0 Comments - https://news.ycombinator.com/item?id=21113613 https://news.ycombinator.com/item?id=21113613

deleted 5y ago

[deleted]

udev 5y ago

Should've named it JackSON5.

kybernetikos 5y ago

These days, JS has moved on while JSON has remained stuck in the past. There are some fairly important ones it'd be great to get a standard format for in JSON. e.g. JSON.stringify({z: 1n}) Also, round tripping ArrayBuffers, Maps, Sets, Symbols and Dates would be really useful. Sadly JSON5 doesn't address those. I'd quite like a next gen JSON not to get upset on circular references too, although that would most likely require some sort of link or reference data type.

pitaj 5y ago
Bigints, dates, and buffers I can understand to a degree. Sets can easily be serialized as a json array. Maps can be serialized as a json array of arrays or as a single json dictionary if the key types are compatible.
- kybernetikos 5y ago
  Everything can be serialised as something else with various degress of difficulty, but one of the beauties of JSON was that it had support for most of the native types of javascript. It's nice not to have to write special logic to serialise / deserialise the way you want. In particular, the ability to round trip all the standard types would be really useful.

ltbarcly3 5y ago

If you're going to the trouble of using something not backwards compatible with json, use something that isn't crap.

avgcorrection 5y ago

> Strings may span multiple lines by escaping new line characters. What if the escape character comes before a trailing whitespace? Like this (`_` is whitespace): "hello,\_\n Will that still escape the newline?

filoeleven 5y ago

Some luckier alternate universes have standardized on EDN instead. https://github.com/edn-format/edn https://github.com/edn-format/edn

elcritch 5y ago

Somewhat related, I was toying around with what an html5 based csv alternative could look like and called it hsv5 partly as a play on json5 and hdf5. https://github.com/elcritch/hsv5 https://github.com/elcritch/hsv5

deepsun 5y ago

Why only positive/negative infinity, but not positive/negative zero?

lamontcg 5y ago
JSON5 was proposed long before positive/negative zero got trendy on HN
- deepsun 5y ago
  IEEE 754 had them for longer?

johnthescott 5y ago

"The standard has to be sufficiently simple that it makes sense to have multiple implementations." -James Clark

dang 5y ago

Past related threads: JSON5 – a superset of JSON with comments, multiline string, trailing comma, etc. - https://news.ycombinator.com/item?id=22598401 https://news.ycombinator.com/item?id=22598401 - March 2020 (1 comment) JSON5: JSON for humans - https://news.ycombinator.com/item?id=17375850 https://news.ycombinator.com/item?id=17375850 - June 2018 (3 comments) JSON5 – JSON for the ES5 Era - https://news.ycombinator.com/item?id=10956943 https://news.ycombinator.com/item?id=10956943 - Jan 2016 (8 comments) JSON5 is a proposed extension to JSON - https://news.ycombinator.com/item?id=7325735 https://news.ycombinator.com/item?id=7325735 - March 2014 (246 comments) Show HN: JSON5 — modern JSON - https://news.ycombinator.com/item?id=4031699 https://news.ycombinator.com/item?id=4031699 - May 2012 (84 comments)

mindless_solips 5y ago

These are the monsters who told us "XML is too bloated" and "who'd ever want a self-describing, self-transformable interchange format anyway?" The more I see things like JSONSchema and JSON5 get away from Crockford's original overly simplistic syntax, the more I think we can all agree with Richard Gabriel. Worse Is Better!