13 ms·

JSON5 – JSON for Humans

• righthand 2y ago
  ` leadingDecimalPoint: .8675309, andTrailing: 8675309.,` Sorry but what is the benefit of this? Lazy shorthand? This is too much. Is this a string in other languages? PHP the `.` is a string concat.
• ruuda 2y ago
  If you're looking for a human-friendly json superset (comments, non-quoted keys) that can also abstract away repetitive configuration with variables and list comprehensions, check out https://rcl-lang.org/ https://rcl-lang.org/.
• qwertox 2y ago
  Comments are nice. I wonder if they can also be inserted programmatically.
  • VTimofeenko 2y ago
    It kinda becomes a question of "does this comment annotate the line it's on, the next one, or the arbitrary number of succeeding lines" since the order of the objects is not guaranteed by the standard and when writing comments by hand it's common to say "the next section shall do X".
    • usrusr 2y ago
      When I work on some ad hoc configuration format I usually end up with quite a family of different comment types. Disabled values and prose about values are are the core set, but there might also be different prose types to separate the intention for a certain value (authored by the one setting the value) from documentation about the purpose of the field (authored by the one introducing the option). Also a type for key value pairs that have not been consumed (perhaps because of a typo in the key), and another for pairs that are applied as default, but should not be explicitly in the config if you want to go with the new default of they change in a software update. Yes, this is for situations where the config is two way, e.g. when a GUI can be used to set some values. But I find some of those features so useful that I might sometimes be tempted to write out a processed version of the file parsed even when there isn't anything like a configuration UI.
      • VTimofeenko 2y ago
        I am using nickel[1] myself for writing what basically amounts to a pipeline that ultimately generates a json or toml. It has contracts that can validate a field or an object as well as set a default value if the field is not present. [1]: https://nickel-lang.org/ https://nickel-lang.org/
    • int_19h 2y ago
      I wish languages adopted structured comments (as in, semantically applying to syntax tree nodes rather than lines) more broadly. It used to be a thing in some early PLs but has mostly died out.
• bawolff 2y ago
  As much as i like this (yaml goes way too far, but trailing commas and comments would make json much nicer. I actually think this spec goes too far with single quotes) i hate that it is named json5. I think its unethical to imply you are the next version of something if you don't have the blessing of the original author.
  • j1elo 2y ago
    I always thought that the name JSON5 pretends to be nothing more than a pun on Michael Jackson's original band, The Jackson 5. It sounds too similar! If it didn't originate from that, what else?
    • bawolff 2y ago
      The project description describes it as json plus syntax from emcascript 5.1 (commonly called ES5) [the official name of javascript is emcascript]. I imagine that is where the name comes from. Although it doesn't really make sense since most of the stuff they add predates ES5.
      • Zamicol 2y ago
        Yes, that is where the name comes from.
    • zeven7 2y ago
      I assumed it was a play on HTML5 ¯\_(ツ)_/¯
    • dcre 2y ago
      Ha. There is no way that’s what it means unless you read that somewhere.
    • benkaiser 2y ago
      I agree with the others that ES5 is likely where it came from, but my mind also jumped to The Jackson 5.
  • 2y ago
• yashap 2y ago
  I’m a fan of JSON5. A common criticism is “we’ve already got YAML for human readable config with comments,” but IMO YAML’s readability sucks, it’s too hard to tell what’s an object and what’s an array at a glance (at least, with the way it’s often written). When dealing with large YAML files, I find myself frequently popping them into online “YAML to JSON” tools to actually figure out WTF is going on. JSON5 is much easier to read, at least for me.
  • BurningFrog 2y ago
    If you already have a bunch of JSON documents, you can keep using them with JSON5. That's a big advantage compared to converting to YAML.
    • knowsuchagency 2y ago
      same is true of YAML as a JSON superset
  • stackskipton 2y ago
    Those two criticisms of YAML are at bottom of my list. Space as delimiter and lack of strict typing is what screws me over on daily basis as SRE.
    • yashap 2y ago
      Fair, YAML has a lot of usability warts, and those suck too. Although personally I really do hate how tough it is to tell apart arrays and objects, at least with the most common YAML array/object style.
    • Pxtl 2y ago
      This. I hate how all these serialization/config formats come out of dynamically typed languages. Static typing is a must. Then so many classes of errors go away.
      • lmm 2y ago
• eknkc 2y ago
  I feel like the comments are the only important part. I’d rather not have single quoted strings or unquoted identifiers to be honest. Trailing commas are nice to have though. All I miss in JSON are comments and a native datetime type. Everything else, I’m fine with.
  • BurningFrog 2y ago
    For comments, adding "_comment": "..." fields can work pretty well.
    • viraptor 2y ago
      Not where the reader verifies the schema. And not when you want to write a long multiline comment. (Unless you want _comment1, _comment2, ...)
      • btown 2y ago
        An array of strings works well here! Also, you can always preprocess to remove comments before validating!
        • oneeyedpigeon 2y ago
          If you're preprocessing, you might as well just `grep -v ^#` and support 'real' comments.
          • btown 2y ago
            There's power to it being valid JSON, though; it can be stored in databases optimized for JSON payloads, and edited with JSON editors. There's a real agility to liberally sprinkling JSONFields and JSON code editors across an auto-generated admin interface like the Django admin system, knowing that you can leave breadcrumbs for colleagues, and that anything starting with a `__` is fair game for comments any time you see such a key name.
  • 2y ago
• brap 2y ago
  Would it be correct to say that this is basically any valid JS code that describes an object, excluding the use of references and function definitions? If not, what is the difference, and why was it made to be different?
  • bawolff 2y ago
    Seems like the escapes are slightly different. No astral unicode escapes (e.g. \u{123456} ). No octal escapes \123 No template literals (backticks) No regex literals No octal numbers (0123, 0o123) No boolean numbers (0b1001) No big ints (the "n" suffix)
    • brap 2y ago
      Most of these things seem like missing features that would fit right in. Except for maybe template strings which could contain references to template functions
  • zanecodes 2y ago
    I've always thought it would be nice to have a language whose spec describes a few different "power levels": 1. Literal values only (objects, arrays, strings, numerics, booleans, maybe datetimes), a la JSON, with standardized semantics 2. Literals, variable definitions and references, pure function definitions, and pure function calls, but prohibiting recursion, such that evaluation is not Turing-complete and any value is guaranteed to be able to be evaluated into its literal form in finite time 3. All of the above plus recursion and impure, side-effectful functions, custom type definitions, etc. This way, implementing a literal parser in other languages would be comparatively straightforward (much like JSON), since it wouldn't have to support variables or functions, but it would also be possible to define values using variables and pure functions (much like HCL or Nix) and then use the language's own evaluator binary (or perhaps a wrapped FFI library) to safely convert these into literal values that another language can parse, while guaranteeing that evaluation will not have side-effects. It would also leave open the escape hatch of using a "full" Turing-complete language with side-effects and recursion, while ensuring that using that escape hatch is a deliberate choice and not the default. I'm sure there are a few additional or hybrid levels that could be useful too (2 but with recursion? 1 but with variables?) but this seems like it would be a solid starting point.
• epscylonb 2y ago
  I've always been a big fan of KDL in principle, haven't used it in anger. After that HCL, then YAML, with JSON and others being my least favourite to use. Of course the hard part is gaining enough critical mass to make a significant switch. JSON had AJAX. YAML had Rails. What could make JSON5 or KDL break out?
• sethops1 2y ago
  May I suggest using TOML, which in my experience has been the perfect blend of human readability while having good tooling. https://toml.io/en/ https://toml.io/en/
  • viraptor 2y ago
    Their dictionaries and arrays split into ini-like sections are not very readable though. The double [[ is just nasty and not possible to apply in all situations (array in map in array).
    • zahlman 2y ago
      > not possible to apply in all situations (array in map in array). Yes, that's largely why inline tables and arrays exist: >>> tomllib.loads(""" ... [[outer]] ... first = [1, 2, 3] ... second = [4, 5, 6] ... ... [[outer]] ... third = [7, 8, 9] ... fourth = [10, 11, 12] ... """) {'outer': [{'first': [1, 2, 3], 'second': [4, 5, 6]}, {'third': [7, 8, 9], 'fourth': [10, 11, 12]}]}
      • lifthrasiir 2y ago
        TOML explicitly disallows newlines in inline tables, so that's not a full solution (if you agree that there are some situations where multi-line inline tables are indeed required).
  • hombre_fatal 2y ago
    Like YAML, it's only better in the simple case where everything is top-level and there's only one level of nesting. Once you want to have arrays of nested objects or objects with arrays, I immediately wish I was just reading JSON so I knew where I was in the tree. And for that reason, I don't think it's a full contender. I want an answer for the hard cases like nested data, not just another way to write the simple cases which is what TOML is. For example, [[a.b]] x = 1 [a] y = 2 Versus: { "a": { "b": [ { "x": 1 } ], "y": 2 } } It's easy to complain that the latter is noisier. But that's nothing compared to being clear.
• nikeee 2y ago
  I think it allows for too much. I was glad that JSON only supports double-quoted strings. It is a feature that removes discussions about which quotes to use. Or even whether to use quotes at all (we still need them for keys with colons or minus in it, so what gives?). The only thing that JSON is really missing are comments and trailing commas. I use JSONC for that. It's what VSC uses for the config format and it works.
  • numbsafari 2y ago
    Allowing for leading decimals without a preceding zero also seems like shifting a whole class of errors right.
  • appplication 2y ago
    As a data guy I find myself running into JSONL a fair bit. It was surprising to me that it’s not supported in the vanilla spec.
    • compootr 2y ago
      as a student experimenting with millions of records of data, its pretty nice!
  • nigeltao 2y ago
    JWCC literally stands for JSON With Commas and Comments. JWCC is also what Tailscale call HuJSON, as in "JSON for Humans", which as amusingly also what json5 claims to be. https://github.com/tailscale/hujson https://github.com/tailscale/hujson
    • deleted 2y ago
      [deleted]
    • lioeters 2y ago
      There's also HJSON, which stands for Human JSON. https://hjson.github.io/ https://hjson.github.io/ It has implementations in JavaScript, C#, C++, Go, Java, Lua, PHP, Python, Rust.
• hi_hi 2y ago
  Isn't JSON for humans essentially YAML? (only kinda joking)
  • sevensor 2y ago
    That was the idea, before it all went terribly wrong.
    • Vegenoid 2y ago
      To the reader: if you haven't before, take a stroll through the YAML spec to see what people are talking about when they bemoan its complexity: https://yaml.org/spec/1.2.2/ https://yaml.org/spec/1.2.2/ Then take a look at the JSON spec: https://datatracker.ietf.org/doc/html/rfc7159 https://datatracker.ietf.org/doc/html/rfc7159
      • smarks 2y ago
        Updated RFC for JSON: https://datatracker.ietf.org/doc/html/rfc8259 https://datatracker.ietf.org/doc/html/rfc8259
• gus_leonel 2y ago
  [dead]
• cute_boi 2y ago
  If browser/node etc.. starts to support json5, i am sure it won't take that much time to get adopted.
• sonsonsonsons 2y ago
  [flagged]
• ianbicking 2y ago
  I like JSON5 and have used it some. When GPT was younger and I was parsing its JSON output directly, JSON5 was forgiving in useful ways. The one thing I really wish it had was some form of multi-line string, mostly so I could use it with line diffs. Also sometimes for really simple property editors it's nice to put the serialization in a textarea, and that works fine for everything but multiline strings. (I suppose you can escape newline characters to put a string on multiple lines, but I find that rather inhumane and fragile)
  • kylelahnakoski 2y ago
    Hjson!
    • ianbicking 2y ago
      Oh! Format preserving editing too, very nice... https://github.com/hjson/hjson-js?tab=readme-ov-file#modify--keep-comments https://github.com/hjson/hjson-js?tab=readme-ov-file#modify-...
• magospietato 2y ago
  Why not just not use JSON for config? In a sane world YAML wouldn't even exist and everyone would use something like TOML.
• guilhas 2y ago
  Hjson looks friendlier for direct manipulation, no string quotes What would be the advantages/disadvantages? https://hjson.github.io https://hjson.github.io
  • throwawee 2y ago
    I use it for personal scripts and it's been wonderful. I get to write more beautiful and concise configuration than any other format I've used. If I were doing a professional project, I'd be hesitant to use it over something with more popularity and support. The syntax has so many variations two files can look like two totally different config languages, which is both cool and alarming.
• berdon 2y ago
  Shameless plug for my JSON/5 parser written in zig: https://github.com/berdon/zig-json https://github.com/berdon/zig-json There is a std json library as well but the aesthetics weren’t great imo. The specs are quite pleasant to implement.
• amelius 2y ago
  The only thing I worry about is how do you parse this, then modify some fields and write back the file with all the comments still in place?
• AdieuToLogic 2y ago
  I find HOCON[0] to be great for this need in JVM-based languages. 0 - https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md
• stickfigure 2y ago
  Still no timestamps :-(
  • Zamicol 2y ago
    What's wrong with Unix? Or is the complaint that there's no data type for time stamps specifically? I agree it would be nice to have something with more data types. Binary b64/hex would be nice.
    • eadmund 2y ago
      > What's wrong with Unix? When you read 847548, is that a number or is that Saturday, 10 January 1970? Having a type removes that ambiguity. It would be more JSONish for it to be human readable, maybe @1970-01-10T19:25:48.
      • Zamicol 2y ago
        Or maybe extend this with types for the timestamp, `@ms:1623132000` or `@unix:1623132000`, so in a value: `{"now":@unix:1623132000}` Mongo types the field name, `{"$date":1623132000}`, if I'm not mistaken. Rust style would be `1623132000_unix`. Or with anticipation of a more full typing system, where the time is explicitly named: `{"now": unix:1623132000}` For now, when I need typing, I use https://json-schema.org https://json-schema.org
  • dzsekijo 2y ago
    Yeah. But I think the goal was here to sugar the syntax while keeping semantics intact.
  • Dylan16807 2y ago
    For a basic timestamp use a number. If you need more, you enter territory that is much too complex to build into the "simplest data format" spec.
• teddyh 2y ago
  I always thought that “JSON5” is a deceptive name. It is not the fifth version of JSON; it is an alternative/extension of JSON, of which there are many alternatives, and this one is no more official than any other.
  • Zamicol 2y ago
    JSON5 is from ECMAScript 5.1, which is called ES5. As an (unfortunate) JavaScript developer, it was clear to me the intent was to "update" JSON with ES5 features, and not say ES4 or ES6. Why ES5? ES5 is when trailing commas were introduced. Commas are one of defining features of JSON5. Other languages, like Go, also made this a priority.
    • teddyh 2y ago
      The name may have a logical reason for being what it is. But it is still misleading. I have seen people implicicly assume that JSON5 is what they should be using instead of JSON, just because of the name.
• bearjaws 2y ago
  The whole reason JSON rules the world is because it's brutally simple. We already have 5+ replacements that are far more robust(XML, YML) and IMO they are not great replacements for JSON. Why? Because you can't trust most people with anything more complicated than JSON. I shutter at some of the SOAP / XML I have seen and whenever you enable something more complicated inevitably someone comes up with a "clever" idea that ruins your day.
  • yencabulator 2y ago
    is yaml robust: no
    • Diti 2y ago
      Ever since YAML 1.2, released in 2009(!), your YAML example would parse your input as “is yaml robust” for the key, and “no” for the value.
      • yencabulator 2y ago
        No, it wouldn't ;) Extra hint: scandinavian countries: - dk - no - se Edit: it's extremely unlikely a yaml parser implements that spec; the spec is irrelevant.
        • Dylan16807 2y ago
          Okay, I originally didn't respond, but your comment got upvoted out of gray so I'll put in the effort. Your claim of "No, it wouldn't" is simply wrong. They said "since 1.2" and you can't just ignore that when you're citing a 1.1 problem. The disclaimer that you edited in gets at a relevant point but it's not strong enough to make your claim actually be true. And the winky face and the "hint" just make things worse, since they knew exactly what you meant.
      • Dylan16807 2y ago
        I used to think that fixed things, then I learned how many parsers refuse to update. Like PyYAML.
• Zamicol 2y ago
  I'm a huge fan. We use it for all our configs.
• Pxtl 2y ago
  It's infuriating that we're still struggling with this after so many years. Every time I learn a new format I want to scream "why can't you be normal?"
  • verdverm 2y ago
    Have you looked at CUE? I haven't looked back since discovering it. CUE is a proper language for configuration that two-way integrates with many other config and schema formats. All JSON is valid CUE too https://cuelang.org https://cuelang.org | https://cuetorials.com https://cuetorials.com
  • mifydev 2y ago
    Take a look at https://typeconf.dev https://typeconf.dev We wanted to define configs with types and avoid custom DSLs as much as possible. So we ended up with using Typespec.io for schema and plain Typescript for authoring configs. This should be as normal as possible!
• counterpartyrsk 2y ago
  KISS
• travisgriggs 2y ago
  I wish json had a simple version/convention like elixir sigils so I could pass datetimes around as first class entities instead of always having to [de]stringify them.
• Zamicol 2y ago
  Hijacking for a random concern: I love JSON, but one of the technical problems we've ran into with JSON is that the spec forgot about all special characters. I actually noticed it when reading Douglas Crockford's 2018 book, "How JavaScript Works". The mistake is on page 22.9 where it states that there are 32 control characters. There are not 32 control characters. There are 33 7-bit ASCII control characters and 65 Unicode control characters. When thinking in terms of ASCII, everyone always remembers the first 32 and forgets the 33rd, `del`. I then went back and noticed that it was also wrong in the RFC and subsequent revisions. (JSON is defined to be UTF-8 and is thus Unicode.) Below is a RFC errata report just to point out the error for others. Errata ID: 7673 Date Reported: 2023-10-11 Section 7 says: The representation of strings is similar to conventions used in the C family of programming languages. A string begins and ends with quotation marks. All Unicode characters may be placed within the quotation marks, except for the characters that MUST be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). It should say: The representation of strings is similar to conventions used in the C family of programming languages. A string begins and ends with quotation marks. All Unicode characters may be placed within the quotation marks, except for the characters that MUST be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F, U+007F, and U+0080 through U+009F). Notes: There are 33 7-bit control characters, but the JSON RFC only listed 32 by omitting the inclusion of the last control character in the 7-bit ASCII range, 'del.' However, JSON is not limited to 7-bit ASCII; it is Unicode. Unicode encompasses 65 control characters from U+0080 to U+009F, totaling an additional 32 characters. The section that currently reads "U+0000 through U+001F" should include these additional control characters reading as "U+0000 through U+001F, U+007F, and U+0080 through U+009F" --- I've chosen `del` to be my favorite control character since so many engineers forget it. Someone needs to remember that poor little guy.
  • rswail 2y ago
    Not to mention that it was set to be 127 so that it would be 8 holes punched out on paper tape, so you could use it to correct a paper tape by backspacing the tape by one position and hitting del.
  • jmull 2y ago
    The errata seems like a mistake. Makes more sense to drop the term "control character" and leave the specification of which characters are not allowed as-is. The cat's already out of the bag on this one. Changing the characters now will create a lot of invalid JSON in the world, with more being generated all the time.
• Silphendio 2y ago
  I find json5 much better than json, but it has still many of the same annoyances. - instead of trailing commas, how about making them completely optional? It's not like they are needed in the first place. - curly braces for top-level objects could be optional too. - For a data exchange format, there should really be a standard size for numbers, like i32 for integers and f64 for floats. - parsing an object with duplicate keys is still undefined behavior.
• matt3210 2y ago
  Yaml is for people, json is for machines
• ddgflorida 2y ago
  The "official" JSON should be enhanced to cover a few of the pain points.
• Waterluvian 2y ago
  I think the killer feature of JSON is that there’s one version and that won’t ever change. You don’t have to think about compatibility. All JSON is valid YAML. So you clearly can make yet another one of these and make it support JSON. But JSON doesn’t support the stuff you’re adding, so calling it JSON5 just makes things confusing as if it’s a version and not a whole new thing altogether. The ugliest thing the authors could accomplish is making this sufficiently popular that there’s a ton of .json files out there that aren’t actually valid JSON. I hope they’re being careful about strongly discouraging ever writing these outputs to files with a .json filetype.
• mifydev 2y ago
  I don’t know how to feel about this. Personally I want to write configs like code, and I want to avoid using yet another specific DSL for it. So currently working on a tool that allows you to write configs in Typescript - https://github.com/typeconf/typeconf https://github.com/typeconf/typeconf
• bogota 2y ago
  Just use jsonnet if you want this IMO. No need to change json into yaml.
  • reissbaker 2y ago
    Switching from JSON to Jsonnet to get comments and trailing commas is like switching from a butter knife to a chainsaw because your steak is too tough. Jsonnet is literally Turing-complete!
• lambda 2y ago
  I find that these efforts to make something that is almost but not quite JSON to be counterproductive. It means that something you can't tell if it's JSON or another format. You'll have some tools that can work with it, while other tools will choke because they expect valid JSON. Oh, someone just switched the quoting style so now your jq based automation is all broken. And now you have to figure out which of these not-quite-JSON formats this is. Is it HuJSON/JWCC? Is it JSON5? Does my editor have a mode that supports this particular variant, or am I always going to be fighting with it? And finally, having used HuJSON for Tailscale config: the issue isn't just things like comments and trailing commas, or quoting styles. JSON is just a kind of heavyweight and cumbersome syntax for writing config files. I find that I prefer writing a script to auto-generate my Tailscale config, because editing it by hand is cumbersome. There are a number of other possible config file formats, with varying levels of JSON data model compatibility. YAML has its issues, but we've all learned to live with them by now. TOML isn't bad, though good luck remembering the array of tables syntax. KDL is pretty nice; it has a slightly different data model than JSON, but it's actually one that is somewhat better suited for config files. I'd rather use any of these for config files than something that is almost, but not quite, JSON.
• peterkos 2y ago
  What is the benefit of this over something like Pkl[0]? Pkl compiles down to JSON, YAML, etc., but the language itself is user-friendly. This way you get best of both worlds: readable and editable for humans, and parsable for computers. [0]: https://pkl-lang.org https://pkl-lang.org
• veesahni 2y ago
  This is very close to what the ruby REPL will accept. I tried to paste in the kitchen sink - it didn't like dangling decimals and the comment format, everything else worked as expected.
• c-smile 2y ago
  Eh, if you drink, then drink... 1. Add `;` as a separator of elements, so you may have: { a: "foo"; b:"bar; } 2. Add array tags and space separated value lists so you may have { a: 12 13 14; } to be treated as [12, 13, 14] with the tag " ". Normal arrays are parsed with the tag "," 3. Add "functors" as, again, tagged arrays rgb(128,128,14); will be parsed to an array with the tag "rgb". Also you may have calc(128 + 14); 4. Add tagged numbers so 90deg will be parsed as a number with the tag "deg" And you will get pretty much CSS that is proven to define quite complex constructs with minimal syntax.
• bazzargh 2y ago
  A common thing in JSON/YAML alternatives is to support more types through syntax. I don't think this is a good idea. YAML already did this badly with the Norway problem, but JSON also has issues with eg "is it float or int", what about nulls, what about precision... and so on. There are many, many more types to support and all this does is complicate syntax; the types can be relegated to a schema. For example, where are dates, with or without timezones, what about durations, what about SI units for mass, current, what about currency, what about the positive integers only, numbers as hex, as octal, as base64... One format that _nearly_ gets it is NestedText https://nestedtext.org/en/latest/basic_syntax.html https://nestedtext.org/en/latest/basic_syntax.html ... which means everything gets ingested as strings, dicts or lists, which vastly simplifies things; my quibbles with it would be it still went for multiple syntaxes (for dictionaries, multiline strings, inline vs multiline dicts&lists. And yet, it still didn't make comments part of the data model (which is so useful when processing or refactoring files). While it's not perfect, it does separate the validation of scalars, not stuffing someone's priority list of validations into incomprehensible syntax. YAML's been a decades long mistake and making JSON more like YAML is not the way to fix that.
• morugam 2y ago
  [dead]
• alex-robbins 2y ago
  It's too bad EDN [1] hasn't seen much adoption outside of the biblical paradise that is the Clojure ecosystem. [1]: https://en.m.wikipedia.org/wiki/Clojure#Extensible_Data_Notation https://en.m.wikipedia.org/wiki/Clojure#Extensible_Data_Nota... In fact, there doesn't seem to be a spec or standard for it, outside of the de facto standard used by Clojure and the programs in its orbit. I guess nobody's bothered to write a standard, because the people who are already using EDN are doing fine without one, and the people who aren't either don't know what it is or don't see its value.
  • ledgerdev 2y ago
    https://github.com/edn-format/edn https://github.com/edn-format/edn I too love edn, but unfortunately most other languages lib abandoned (eg. https://github.com/edn-format/edn-dot-net https://github.com/edn-format/edn-dot-net ). Looking around python seems relatively maintained which is great https://github.com/swaroopch/edn_format/issues https://github.com/swaroopch/edn_format/issues
    • sundarurfriend 2y ago
      Is there an example of what it looks like in practice? The Wikipedia link above doesn't have it, its citation http://edn-format.org/ http://edn-format.org/ seems like it doesn't exist anymore, and this github page doesn't show a sample either.
      • ledgerdev 2y ago
        It's plain old clojure, more examples here https://learnxinyminutes.com/edn/ https://learnxinyminutes.com/edn/ { :name "John Doe" :age 30 :languages ["English" "Spanish" "French"] :address {:street "123 Main St" :city "Anytown"} }
      • avodonosov 2y ago
        Hundreds thousand of examples at github, see this comment for an example search link: https://news.ycombinator.com/item?id=42364597 https://news.ycombinator.com/item?id=42364597
• rk06 2y ago
  Now, it would be great if we have parsers, editor plugins and json schema supprot as well. until then, jsonc works for me
• eviks 2y ago
  > JSON for Humans The emoji in the first paragraph seems to convey the understanding that humans like expressiveness, but the format itself doesn't allow Unicode values in keys, which seriously limits said expressiveness...
  • deleted 2y ago
    [deleted]
• efitz 2y ago
  If it’s designed for hand authoring it should support an ISO8601 date format; mere mortals cannot author numeric timestamps without tools.
  • The_Colonel 2y ago
    Just store the ISO9601 date/time in a string. No need for special support on the format level.
    • eadmund 2y ago
      Why have numbers, true, false or null then? Why not only support strings? {"foo": "2", "bar": "null", "baz": "false"} I’m not really being facetious: that’s what canonical s-expressions did: ((foo 2) (bar null) (baz false))
      • efitz 2y ago
        Type declarations can imply syntax, semantics or both. Yes, you could represent everything as a string; in that case, the serialization format is no longer providing any assistance in verifying or enforcing syntax. But it’s often useful to be able to verify syntax independently. And it helps avoid authoring errors (like using “1” instead of “true” etc.) that are ambiguous if your only hint is semantic.
        • eadmund 2y ago
          In that case one should also have a type for dates. What I’m getting that is that a format ought to commit.
      • The_Colonel 2y ago
        It's of course a trade-off in how far you want to go with special types. Booleans and numbers have extremely common use cases, moreso than date/times. But perhaps more importantly, they are quite easy to define. Date/time is a susprisingly complex topic with many variants (date, time, datetime, local/relative date/time, point in time, offset-based, timezone-based...) with all of them being quite important. The spec to define date/time types would likely be longer than for the whole rest of JSON, and you still wouldn't be able to correctly interpret the date/time from the spec alone, since timezone data/designations are dynamic. Now the question is - what value does this extra complexity bring? I'm not saying there isn't any, but it doesn't seem to justify the cost.
• hgs3 2y ago
  I'm looking at the JSON5 spec and it appears it does not introduce a capital \U escape sequence for Unicode characters outside the Basic Multilingual Plane (BMP). It's not brought up often, but in JSON you do need UTF-16 surrogates to write an escape sequence for Unicode characters outside the BMP. Consider the Hamburger Emoji (U+1F354). Instead of escaping it as "\U0001F354", you need to escape it with UTF-16 surrogates "\uD83C\uDF54". This is both cumbersome for humans and not in accordance with the Unicode Standard [1]. It's ironic, but many (most?) of the "JSON for Humans" flavors of JSON tend to overlook this. [1] See Chapter 3.8 "Surrogates" of the Unicode Standard.
  • Dylan16807 2y ago
    How often are humans going to be using unicode escape sequences?
    • maxloh 2y ago
      I believe in most cases, they are generated by programs. Refer to my other comment for real-world examples.
  • maxloh 2y ago
    When you export Instagram data as JSON, the resulting JSON files include encoded strings like "\uD83C\uDF54". Parsing and converting these strings can be cumbersome because a single Unicode character is often represented by a single escape sequence, but sometimes it requires two.
  • fanf2 2y ago
    There’s no \U in JavaScript: it is spelled \u{10ffff}
• ultimoo 2y ago
  can this be used to convert llm output to json?
• up2isomorphism 2y ago
  No I don’t need this thing.
• andy_ppp 2y ago
  Unfortunately this is basically that XKCD cartoon about proliferating standards. I think I’d avoid this additional standard and just use JSON or a JavaScript object if I really need this level of flexibility.
• hoseja 2y ago
  Hey look another xkcd://927
• DrScientist 2y ago
  This may be heretical but surely the problem isn't lack of comments et al in JSON, rather that people try to use JSON for everything, when it was designed to be a text representation of javascript objects?
  • Sankozi 2y ago
    If it was really designed for representing JS objects then it was really bad job. Neither JSON supports JS objects (lack of NaN) nor JS supports JSON (lack of arbitrary precision decimals).
    • DrScientist 2y ago
      Fair enough - perhaps I should have said it was inspired by Javascript literal syntax and simplified to make it a platform independent data exchange format and not a application configuration format. Though I can see how the latter is tempting if your application is in JS.
• rixrax 2y ago
  This should have been named NOTjson-somethingv5. Or similar. Now it is far from obvious for the uninitiated that this might not be the 'latest' version of JSON. And then they end up using this incompatible format by accident, when in all likelihood standard JSON would serve equally well or better in 95% of the use cases.
• lakomen 2y ago
  Oh he'll no not another standard no one needs. JSON is good enough
• jwblackwell 2y ago
  It feels like AI has made this redundant. I honestly cannot imagine hand typing out some JSON now, or most code for that matter. I just write in natural language what I want and the AI will perfectly output valid JSON.
  • solardev 2y ago
    Just being able to add comments to a .JSON5 file is a godsend though, no matter who/what created it. Oh... and TRAILING COMMAS!
  • int_19h 2y ago
    That JSON you get might be syntactically valid, but how do you know that it is accurate wrt your original input? That, for example, no values have a one-character-off misspelling?
• deleted 2y ago
  [deleted]
• sod 2y ago
  When I manage a project and have the freedom to choose my configuration structure, then I always use typescript. I never understood the desire to have configuration be in ini/json/jsonnet/yaml. A strongly typed configuration with code completion seems so much more robust. Except of course your usecase is to load or change the config via an API. I like what apple is doing with https://pkl-lang.org/ https://pkl-lang.org/ though.
  • Dylan16807 2y ago
    You can apply typescript-based strong typing and code completion to JSON and similar. And then you can avoid making arbitrary code execution part of your config format.
• mariocesar 2y ago
  Isn't this simply YAML but with curly braces? Another thing is that It feels wrong to have comments in JSON, like allowing comments in CSV files.
• jillesvangurp 2y ago
  Good API design dictates that you should be flexible as to what you accept and strict about what you serve. Being flexible doesn't really break anything. Elasticsearch and Opensearch both actually have partial support for JSON5 (comments), which is a nice feature if you want to document e.g. a complex query or mapping choice. It won't return any comments in the response. So it won't break other parsers. Implementing JSON 5 support like this is a valid thing to do for any server. More broad support for this in parsers would be nice. I'd probably enable this on my own servers if this was possible. I'd need that to be supported in kotlinx.serialization. See discussion on this here: https://github.com/Kotlin/kotlinx.serialization/issues/797 https://github.com/Kotlin/kotlinx.serialization/issues/797
  • fifilura 2y ago
    > Good API design dictates that you should be flexible as to what you accept and strict about what you serve. Being flexible doesn't really break anything. Do you have a source on that? I am not sure I agree. My gripe is with HOCON that accepts so many formats that after a while you have no idea what it is you are actually writing. You can have a conf file with 5 different formats of the same type of setting. Probably added to by 5 different developers. I'd rather have it throw an error in my face when I don't adhere.
• andreif 2y ago
  I think main problem people trying to solve is treating JSON as computer-human interface. It was not designed for it and I don’t think we need to expand its use-case. You can perfectly use subset of YAML with much better readability for human interactions. I wrote custom parsers for subset I need with like 100 lines of Python code. JSON should stay as a loggable system-to-system format that you can render in a more readable way.
  • andreif 2y ago
    Actually, right this moment I am writing docs for my mini-yaml to generate JSON Schema Draft 4 for our EDA. Easy-peasy
  • pbreit 2y ago
    JSON is pretty close and much more widely used/available. It's fine.
• 65 2y ago
  Why not just use YAML at that point?
• 11235813213455 2y ago
  only needs trailing commas
• peterohler 2y ago
  There are a few more tolerant versions of JSON. In OjG I called the format SEN https://github.com/ohler55/ojg/blob/develop/sen.md https://github.com/ohler55/ojg/blob/develop/sen.md
• lolive 2y ago
  JSON6 will feature triple-quote string quoting. Either made out of “ or ‘. Wake me up when it happens. PS: quoting line returns for multiline sounds weird. But who am I to comment…
• michaelcampbell 2y ago
  Looks very nice, but I feel it's one of those "yeah, it's better, but only useful for personal projects, or until it gets critical mass which won't be until after I'm dead, if at all" projects.
• teilo 2y ago
  Or, just don't use JSON for config files. There are plenty of human-friendly config file options, so there is no reason to frankenstein JSON in this way.