Hacker News Reader

Comment by roncohen | Hacker News Reader

Couple of gripes:

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

View on HN

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/... 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.

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.

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.

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]
    }

I think the main difference between my suggestion and yours is that mine has more brackets. I think type hinting and 'constructors' are basically the same thing, but I like the types to be extensible, so even in your version, I'd make the type hints things that could be provided into the NuJSON.parse function.

Obviously, in your version my approach would be

    sounds: Map {
        cow: "moo",
        fox: null
    },
    possibilities: Set ["she loves me", "she loves me not", 42]

I suppose that the idea could be that type hints are entirely ignoreable, and if you strip them the file just becomes normal JSON?

I suppose my point was that you don't have to specify types for maps and sets at all (which I didn't do in my example,) the existing syntax already does that. [] is already a set, {} is already a map. Type hints would just be used for the values.

Sending type definitions seems like a good idea. Although at that point it might as well not even be called any kind of JSON.

I don't agree that you don't have to specify types for maps and sets. For example

    {true: "yes", false: "no"}

Is not valid JSON, but

    Map [[true, "yes"], [false, "no"]]

should be valid 'NuJSON'. Maps and Sets are semantically different to Objects and Arrays, and they are Javascript standard objects that should ideally be supported by the default serialisation. The other alternative of course is to force the deserialisation code to fix them up afterwards, but that is painful.

I want to be able to stringify records with Sets, Maps, Arrays and Objects in, and have that work, even if they have behavior not supported by objects and arrays, and I don't think the user should have to fix up the output after parsing of JSON containing standard javascript objects.

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).

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

I agree about the single quotes, but many use single quotes for strings in JS and so it's understandable to have this consistent.

Because:

  ‘I am “really” angry’

Is much nicer than:

  “I am \”really\” angry”

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.

Nobody's forcing you to use single quotes as delimiters.

"I'm \"really\" angry, don't do it again!"

Json is not meant to be human readable or writeable.

But JSON5 is.

All text based data formats are meant to be human readable and human writable, and humans read and write JSON all the time.

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.

>You wouldn't say that mammals write C all the time, would you?

Yes. Mammals do write C all the time, because humans are mammals. And C is meant to be human readable and writable.

> Front end development would be so much better if you could just spew json at people in a table.

That's literally what a JSON API is, and there are tons of them. And for each of them, a human had to be able to read and comprehend JSON responses and write JSON requests in code. There's a reason JSON is pretty-printed in the debug consoles of browsers.

To say nothing of all of the package definitions or framework configs that are written (by hand) in JSON.

The fact that most JSON is machine generated at present has nothing to do with its original design intent. Most Javascript, CSS and HTML are machine generated nowadays as well, but they were meant to be written by a person using a text editor.

Second sentence from json.org: "It is easy for humans to read and write."

I've worked on 4+ years of technology that was entirely based on humans hand-tweaking, editing, and updating JSON configs. My text editors validate it quickly, and know how to fold, sort, prettify. Based on my experience (and editing it all day long) It's a very human readable and editable configuration.

Single quote strings are useful when the string contains many double quotes (e.g. XML with attributes).

Reply on news.ycombinator.com