despite popularity, most of the technical comments in that original thread aren't wrong. 'Popular', 'Easy to adopt' and 'a very bad idea' can be overlapping circles, in particular in the world of javascript and npm

These were not haters. They in fact went our of their way to give arguments supporting their verdict, and in some cases even constructive suggestions like "make that a preprocessor instead".

Your piece does not make you look like the smartest guy in the room, vindicated by success and adoring fans. It makes you look like someone who confuses internet fame points with something that actually means something. Like a sore loser who needed to convince themselves that they really are the smartest person in the room.

The internet is a trap. No matter how bad your idea is, you will always find people who think it's great.

Just look how many people Alex Jones found who agreed with his Sandy Hook ideas.

Don't go looking for fans. Go looking for people who disagree, as they will help you improve your skills and grow as a person.

If you were actually as good as you apparently think you are, you wouldn't be wasting time writing text like this. You wouldn't need to. Your work would speak for itself. I don't remember Mozart or Einstein lament about their haters.

If the performance of your module suffers from parsing its inputs, you are doing some Really Terrible Thing with your inputs. And if the nature of the task really requires you to parse data quickly and on a big scale, it would be better to ditch JSON altogether and switch to a binary format like protobuf instead.

You know that something has gone very deeply wrong somewhere when people oppose your project because they are ideologically opposed to comments. In my own experience, finding out that many JSON parsers reject comments was a real WTF moment, and a deal breaker for my config-file application, so I ended up using JSON-plus-comments for it instead of JSON. At the same time, lack of support for trailing commas and unquoted member names have been a minor but persistent thorn in my side for no good reason. The justification for not having comments in JSON is that in the great disaster that was XML, some projects would parse the comments and take them as semantically significant. However, the real problem there was that parser libraries would expose the comments, and that some generators would put important information only in comments. But I think that these mistakes are unlikely to be repeated, and that the proposed alternative - moving all comments into the markup, or eliminating them entirely - is just obviously worse.

One of the things that ruined the XML ecosystem was a persistent belief that XML was to be read and written by machines, combined with a reality in which it was mostly used for human-written config files, leading to a tolerance for awful syntax (like prefixing every single attribute with a namespace, and the ridiculous CDATA notation). I'm seeing the same thing with JSON: A significant fraction of its use is for human-written and human-read config files (which often desperately need comments) and people are pretending it's strictly a data interchange format that shouldn't be used for that.

It is sometimes said that JSON was discovered, rather than invented - that the syntax was already out there. So it is with JSON5: There is nothing new in this, it is simply return to JavaScript Object Notation and bringing in the rest of what Javascript has.

So, all you pooh-poohing ideologists: please seriously rethink whether disallowing comments, trailing commas, and quoteless member names is actually a good idea. Consider this in light of the fact that JSON is widely used, today, as a config-file language, and that {"--":"This is a comment"} is ridiculous enough that no one does it in practice, can't be inserted on any line, and invites consumers of your data to parse the comments.

Json is trying to square the circle of "I want things to be easy" but also "I want to not shoot myself in the foot", goals which are mutually exclusive. Every new version of json is just gods way of teaching people how XML got to be the mess it is.

More details in this comment: https://news.ycombinator.com/item?id=32380944

It is partly the articles, but more the comments (and careful modding).

HN stands out as a great place to expand my awareness. There are people here with deep technical experience that care about the outcome of their conversations. The flame-bait and regressive behavior isn't the main thing going on, it is a sideshow. If that ever changes for me, I'm out of here.

The article fodder is not as interesting to me as it used to be, but there are gems, and the comments remain engaging.

Who knows, perhaps I'm one of the jerks? Perhaps I'm the dreamer that dreams the dream and am therefore the jerk expert? Hard for me to say, but I welcome your opinion.

Like Hashicorp products or not, the remark seems a bit petty.

Left-pad shitshow showed how relevant NPM dependency chain is as a measure of quality and what it does for the ecosystem. This is left-pad with added complexity to sneak in malicious code.

If C was written like

    {if {x == 1}{
      {return {x + 1};}
    }

I personally prefer to choose a simpler, and a bit more pedantic versions of stuff whenever I develop something, and while it doesn’t break performance records OOTB, the performance is always beyond reasonable at the first iteration.

So with this logic, I’ll just prefer “vanilla json” whenever I need to use it as a data exchange format, or a well established and fast XML parser, and leave at it.

This logic made my life way easier, but it’s just me, and I respect other developers’ choices.

Mine is just an observation rather than a rant.

OTOH, using a simpler set of components will reduce the probability of breakage a lot, too.

That is not the job of the data format, that is the job of the meta data format. That this is still a draft tells you how far behind json is: https://json-schema.org/draft/2020-12/json-schema-core.html

Again, json is gods way of teaching bad devs why xml is such a mess.

In JSON if that's an expression then it's a number. You're the one advocating S-expressions, which is where you'd have to guess the type, so tell me how you'd figure the type out there. Heck, you're complaining about the fact that JSON schema is only a draft, but that's still decades ahead of the state of standardised S-expression formats.

> Thank you, people like you are the reason why I can quit my job and any time and find another one paying mid six figures to fix your messes.

Right back at you lol.

Yes, ... Maybe ... I hope software people do; maybe they pay a bit more attention to logic and reason.

I'm otherwise reading the book "Influence, New and Expanded: The Psychology of Persuasion", and I no longer have such high expectations :-(

> not letting people get you down.

Good point :-) (Thanks for the reply)

We tend to pay more attention to the negative and dangerous -- a survival thing, right (from when we were hunters and gatherers)

"If you've found something that arouses interest and debate, you might be on to something"

And critique, or a gathering of enemies, is interest in something

(interest in the stuff the enemies in the game are guarding)

What is even the point of soliciting feedback if you will take a universally negative response as a positive?

Give me YAML or JSON at least they make sense.

Pray tell, which intolerable experience did you ever had writing JSON by hand?

We can say the underlying idea of taking javascript's object syntax was a discovery, but he refined it between discovery and release.

+1 on those S-expressions.

I don’t see how assigning blame is productive here. People choose the wrong language, wrong library, or wrong tool all the time.

For some companies release just means another merge to master, so they are doing tens/hundreds releases a day.

Once you do enough development that this matters, you're going to be doing caching or you'll be wasting money on waiting and bandwidth.

That's not the problem, is it?

The choice you're faced with is breaking compatibility just to add little to no value.

I'd say if those were your criterias and you still stuck with a JSON-derived language, your decision-making process was a colossal failure in oversight, given the myriad of options around such as TOML or even YAML.

But let's pretend that adding comments and trailing commas to JSON makes any difference regarding those requirements.

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.

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?

Never disputed this.

> It's no longer better ergonomics if you can't use it at all because half your endpoints don't support it

Incompatibility != lack of ergonomics. People use new and incompatible frameworks all the time. It could be argued that JSON had better ergonomics at a time when XML was more popular, in spite of impedance mismatch with other APIs. Similar could be said of what's happening with python 3 vs python 2 the last decade. How do standards improve without breaking anything?

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

From reading the article, it seems like people were particularly cruel, well beyond constructive criticism into straight up ridicule:

> But he went even further: Mitchell took the time to make a parody project of JSON5 [..] even making fun of me by name.

OP was gracious about it however:

> I reached out to Mitchell as part of writing this post [..] I assumed he regretted it in retrospect, and I harbored no grudge or ill will towards him.

> Mitchell confirmed this assumption to be true and offered a genuine, sincere apology. Thank you, Mitchell — I appreciated that a lot.

He doesn't appear to take personal affront, so I think his use of the term 'haters' is playful, but I think also fair when you consider that even those mocking them felt bad about their conduct.

We're supposed to assume best intent.

Accusing someone of being "disingenuous", "horribly uninformed" and "short sighted" for providing an different opinion isn't doing that.

I learned something from the post. I learned that these enhancements are already mostly being codified in the language.

That influenced my opinion on the subject.

I assumed that the 13 lines of code comment was in the context of js, not (for example) a c parser, where it's pretty normal for 13 lines of js to translate to hundreds or potentially thousands of lines of C code.

The post was informative and respectful.

The name-calling response was not.