91–100 of 251 posts
Alternatively, just use JSON as a low-level data interchange much like a CSV file. Put all your human-managed content in a configuration language that emits JSON, like jsonnet, cue, dahl, etc. These languages add comments, function, variables, and much, much more (like fancy data cascades, validation, schemas, imports, etc.) to make managing configuration at scale easy.
Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag. As a case in point, th…
Earlier quoted context omitted.
I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together. I don’t know whether the right trade-offs were made between interoperability and other features, but I’d say it’s very clear that if interoperability was a chief design goal, it was executed extremely well.
I don't understand why you keep making the same circular arguments. If the lowest-level standard for JSON-encoded data also included comments and trailing commas, than I have no doubt that every combination of JSON-encoded data and JSON parser would be able to parse that. Instead, it wasn't put in the lowest level spec, so instead what you have are lots of individual parsers with non-compatible custom flags. If Crock…
No, because his goal was to make JSON a highly-compatible interchange format, which it is! There are roughly zero incompatible preprocessor directives, and roughly zero problems using JSON to exchange data between parties. Seriously, when have you received JSON that you couldn’t immediately parse with your standard JSON parser of preference? The fact that some people might devise their own tools to store incompatible JSON on their end with things like comments, and strip those things out when transmitting them in order to make them compatible JSON, does not qualify as an incompatible preprocessor directive. On the contrary, thats precisely the intent of the choice to not have comments in JSON.
Just use YAML. JSON is valid YAML.
Why can't these no-brainer features just be added to browsers without a new standard!!
That would mean your API would need to serve different variants based on the Accept header, and your backend code would need to generate the two different variants.
And then you'd have to question if sending API responses with unused things like comments is actually a good idea given it's entirely wasted data in a production environment.
I suspect few people would use a newer JSON format until it's been available for a long time, and even then they wouldn't use it on big sites.
Earlier quoted context omitted.
ISO-8601 not good enough for you? It’s a standard, human readable, has every datetime detail, every language that supports JSON can read it. What’s missing?
Be careful ever saying “every datetime detail”! An obvious one is that ISO 8601 can’t represent the location of the local time with enough information to know the current (or historical) daylight saving time rules for that location. You might not need that now, but you might if you’re building a calendar app! ISO 8601 can represent a simple offset from UTC, but it can’t do a lot of the things that the IANA time zone…
Adding an IANA library to the ISO8601 library (often part of the same lib) has so far solved that problem for me. I’m sure it starts struggling with dates before the early 1800’s though.
Also doesn’t work well if you’re dealing with relativistic effects I think.
Earlier quoted context omitted.
I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together. I don’t know whether the right trade-offs were made between interoperability and other features, but I’d say it’s very clear that if interoperability was a chief design goal, it was executed extremely well.
> I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together. As recently as 2017, the Google Translate API used to return completely invalid JSON with empty array indices instead of nulls ([,,,] instead of [null,null,null,null]). This broke several JSON parsers until they patched around Google's cavalier abuse of the language. Your experience of everyth…
Just use YAML. JSON is valid YAML.
Problem is... YAML sucks, as human readable format
Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag. As a case in point, th…
I think the most correct way to deal with this problem is to get IETF and ECMA to update the JSON standard first. Honestly, comma-after-final-element and comments are such important quality-of-life features that I never understood why they weren't part of the original spec.
On the other hand, it might be easier to just adopt TOML and forget about JSON.