undefined | Better HN

0 pointsbobthepanda3y ago0 comments

This seems like making a mountain out of a molehill.

> Extending the syntax is undoing all the communal work

JSON5 takes stuff from ES5.1 and adds it to JSON, and ES5 is backwards-compatible with older JS. This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e...). And ES5.1 itself was the product of communal work.

> encroaching on grounds that YAML and other languages already cover.

I don't know that we should really start dividing features into nice little boxes so no one steps on each other's toes. Trying different solutions for the same problem can eventually bring us more optimal solutions than if we just sat around twiddling our thumbs because 'it's been done'. It's not like there's an army knocking on your door going "switch to JSON5 or we'll kick your teeth in." People can stick with what they want to do on the merits, but I don't see that as a reason to shut down others' work.

0 comments

arinlen3y ago

> JSON5 takes stuff from ES5.1 and adds it to JSON, and ES5 is backwards-compatible with older JS. This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines).

This take is disingenuous and horribly uninformed and very shortsighted.

Not every parser out there is JavaScript eval(). Some people actually had to write and maintain a parser in whatever programming language they have to work with.

In the past I wrote a JSON parser for a low-level language, and back then I had to write the letter and parser by hand. Each change to accepted JSON values meant I had to add at least one terminal token, update the grammar to include it, and update the data model to support yet another type.

Adding comments would either require adding a terminal token to be ignored, or rewrite the data model to support positional items that cursors/iterators could or could not skip.

These are not 13LoC changes. At all.

And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5, I would either have to rush a parser to production or remain down.

dietrichepp3y ago

Saying the take is “disingenuous” is certainly a rude and inappropriate response.

You can disagree with someone without accusing them of being insincere or arguing in bad faith (which is what “disingenuous” means).

acedTrex3y ago

It is disingenuous to reply to a comment about "undoing all the json parser work across multiple languages" with "no it hasn't it's just 13 lines in javascript see!"

1 more reply

RobertWHurst3y ago

Comments is clearly for configs, not for server responses, but even if someone did respond with json5, as the previous post said, you don't have to tokenize the json5, you can convert it to json first (since I would imagine you don't need comments). I can imagine how you feel about graphql.

h0l0cube3y ago

I agree with your point here (but I'm not the GP). The main thrust of the article is about finding product/market fit, and it could be said here that the market isn't the parser writers, who would be disrupted, but the developers who want a JSON format with better ergonomics.

> And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5

And such a decision might be the API maintainers not understanding their users.

Brian_K_White3y ago

It's no longer better ergonomics if you can't use it at all because half your endpoints don't support it, and the reason they don't support it is not mere neutral time or popularity but a result of the fact that the new form no longer posesses the qualities that made the original form useful.

This really does look like a case of missing a point and proceeding with a bad idea that results in an all around increase in harm, because no matter the idea, there will always be at least a few adopters and then everyone else has to deal with it.

If it's allowed for anyone to come up with any new idea they want, then it has to be equally allowed for others to criticize. Anything else is literally not sane.

It's perfectly likely the "haters" are right and the idea is bad and should not be adopted or proliferate. It's also possible they are merely unthinking haters.

But calling them "haters" is not a valid defense of the idea.

1 more reply

shellfisher3y ago

If you happened to use an API that switched to XML or whatever other thing you’d be in the same boat. What a ridiculous argument.

jhardy543y ago

> This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e...).

Did you paste the correct link? This just plumbs together an existing JSON 5 parser with a JSON 4 serializer.

How many lines does this take without importing a library the solves this for you?

bobthepandaOP3y ago

JSON5 parse constructs a Javascript object, which can in turn be serialized by JSON 4 into valid plain JSON string. That's not an invalid way of converting the two objects.

JSON.stringify is part of the standard JS spec: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

JSON5.parse() is part of JSON5's API: https://json5.org/#json5parse

So any project that includes both standard JS and JSON5 could literally copy and paste this code. You're still importing JSON5, but you would presumably have to do that anyways to use JSON5.

MauranKilom3y ago

> So any project that includes both standard JS and JSON5 could literally copy and paste this code

is not a convincing reply to

> so parsers already exist in every language

Falkon13133y ago

Personally, I like some of the ideas of JSON5, but it isn't compatible with JSON as implemented. Altering existing systems to use it isn't as trivial as you imply. And requires taking on new dependencies.

You'd have to rewrite anything using json_encode() and json_decode() in PHP, or the equivalent standard functions/methods in Python, C#, etc. And also take on another dependency. And maybe lose performance.

And then you sometimes may have to know whether you're dealing with JSON or JSON5, and what the program on the other end of the line produces or expects and can handle.

For new greenfield projects it might be worthwhile. But most of the world runs on legacy code and many prefer to stick to the standards and minimize dependencies. So it's not that simple.

That doesn't mean it's bad though. Like anything else in software, it's a trade-off.

jhardy543y ago

What about the vast majority of languages that aren’t JavaScript?

j / k navigate · click thread line to collapse

0 comments

arinlen3y ago

> JSON5 takes stuff from ES5.1 and adds it to JSON, and ES5 is backwards-compatible with older JS. This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines).

This take is disingenuous and horribly uninformed and very shortsighted.

Not every parser out there is JavaScript eval(). Some people actually had to write and maintain a parser in whatever programming language they have to work with.

Adding comments would either require adding a terminal token to be ignored, or rewrite the data model to support positional items that cursors/iterators could or could not skip.

These are not 13LoC changes. At all.

And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5, I would either have to rush a parser to production or remain down.

dietrichepp3y ago

Saying the take is “disingenuous” is certainly a rude and inappropriate response.

You can disagree with someone without accusing them of being insincere or arguing in bad faith (which is what “disingenuous” means).

acedTrex3y ago

It is disingenuous to reply to a comment about "undoing all the json parser work across multiple languages" with "no it hasn't it's just 13 lines in javascript see!"

1 more reply

RobertWHurst3y ago

h0l0cube3y ago

> And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5

And such a decision might be the API maintainers not understanding their users.

Brian_K_White3y ago

If it's allowed for anyone to come up with any new idea they want, then it has to be equally allowed for others to criticize. Anything else is literally not sane.

It's perfectly likely the "haters" are right and the idea is bad and should not be adopted or proliferate. It's also possible they are merely unthinking haters.

But calling them "haters" is not a valid defense of the idea.

1 more reply

shellfisher3y ago

If you happened to use an API that switched to XML or whatever other thing you’d be in the same boat. What a ridiculous argument.

jhardy543y ago

> This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e...).

Did you paste the correct link? This just plumbs together an existing JSON 5 parser with a JSON 4 serializer.

How many lines does this take without importing a library the solves this for you?

bobthepandaOP3y ago

JSON5 parse constructs a Javascript object, which can in turn be serialized by JSON 4 into valid plain JSON string. That's not an invalid way of converting the two objects.

JSON.stringify is part of the standard JS spec: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

JSON5.parse() is part of JSON5's API: https://json5.org/#json5parse

So any project that includes both standard JS and JSON5 could literally copy and paste this code. You're still importing JSON5, but you would presumably have to do that anyways to use JSON5.

MauranKilom3y ago

> So any project that includes both standard JS and JSON5 could literally copy and paste this code

is not a convincing reply to

> so parsers already exist in every language

Falkon13133y ago

And then you sometimes may have to know whether you're dealing with JSON or JSON5, and what the program on the other end of the line produces or expects and can handle.

For new greenfield projects it might be worthwhile. But most of the world runs on legacy code and many prefer to stick to the standards and minimize dependencies. So it's not that simple.

That doesn't mean it's bad though. Like anything else in software, it's a trade-off.

jhardy543y ago

What about the vast majority of languages that aren’t JavaScript?

j / k navigate · click thread line to collapse