Non-constructive criticism is extremely easy to produce and can make the author of it feel smart for a second. Doing it in a place where folks share their creative works is like shooting fish in a barrel.
There may be a tiny bit of signal in such comments but it's mostly just noise. I try to just ignore any comment that looks like the commenter just wrote whatever came to their mind, they're gonna forget about it in 10 seconds too when they're off to the next thing to react to.
Many of those original comments were pretty spot on though. Maybe the constructive criticism you need sometimes is “don’t do this”
JSON is useful partially because it’s easy to parse, so parsers already exist in every language. Extending the syntax is undoing all the communal work, and encroaching on grounds that YAML and other languages already cover.
I think the real lesson is that popularity is a poor way of understanding whether something is actually useful or good, it can indicate those qualities but meaningless without also applying our reasoning faculties too. The author appears to remain oblivious to any of the very good reasons why people don’t like alternative json formats and incapable of incorporating that into their understanding of people’s reaction. Citing market mechanics as a justification of “popularity = value” is blowing past the many examples of where free markets produce terrible approximations of value.
Also, I think it’s very poor character to say on one hand that people’s reaction doesn’t bother them and dedicate a third to a half of the article to Mitchell’s criticism specifically. I think Mitchell’s criticism is completely reasonable (I remember this as an era of “solving json” through multiple alternative formats) and drawing attention to what seems in retrospect as a mean-spirited act is actually quite a cynical attempt to strip the context of it and deliberately cast Mitchell in a poor light. Mitchell’s intention is very clearly a technically minded one to nudge people away from trying to massage long term, durable standards in often trivial, subjective ways with an end goal that can only result in format thrashing that doesn’t ever address anything substantial.
Except Mitchell explicitly called the author out in his satire and the author was right that Mitchell thought in retrospect it was a mistake to do so. Why is it in poor character if he’s expressing a view Mitchell agrees with.
Additionally in terms of the criticism, I observe the inverse phenomena to what you describe. You say that popularity isn’t a good indicator of goodness, but I think the inverse is goodness isn’t an indicator of eventual popularity. Some very elegant solutions just aren’t flexible enough for the real world. It is short sighted to try to argue some objective definition of badness because it doesn’t solve a problem you have or doesn’t fit your version of what a product like that should be. Sometimes in the absence of perfection people just have to get work done and want tools that make that easier.
The only 2 things I'd like to add in JSON are trailing commas and comments, and this is already supported in most JSON configs (.eslintrc, .babelrc, ..), it's called JSONC I believe
I think the only valid objection here is that calling it json5 implies that it is an offical new version of json by the same people who brought you json. That's misleading and bordering on unethical in my opinion.
Everything else is a matter of taste, and who really cares.
Whenever I need to use JSON in my projects I always check if I can use JSON5 instead. It really makes a difference to have a more user friendly format. My only gripe is when I use Python, the official JSON5 module is much, much slower than Python's JSON parser. I frequently end up translating the development JSON5 files to JSON files that go into the final runtime because of this.
As much as the spec for this looks like a list of features that one hardly believes are absent from the original JSON, this just makes things worse as you now have to check which type you're working with, as if there are already not enough places for things to break.
Honestly I don't understand why JSON should be human-readable. It is a data serialization format intended to be read by software.
Just adding comments and multi-line strings doesn't make it human-readable, it is still too bloated and I don't like writing it manually. If you want a human-readable format, try at least to remove unnecessary quotes, brackets and commas and make it look similar to YAML.
JSON is not intended to be used in configs and other user-editable files.
The first two sentences of the text on http://json.org are "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write."
It's a primary goal of JSON, it's fair to question whether it's successful at it. Personally, I'd much rather write TOML or S expressions. I don't like YAML at all, the whitespace sensitivity drives me nuts.
> JSON is not intended to be used in configs and other user-editable files.
Yes, but it’s a bit late for that.
It sounds like you’re advocating for a configuration format somewhere in the space between JSON and YAML. Not JSON, because it’s annoying to write by hand, no comments, no trailing commas. Not YAML, because of all those unintuitive edge cases like “no” (unquoted) being a Boolean.
It sounds like the primary disagreement here is where in the design space between JSON and YAML is the right syntax for configuration files.
I read and write json manually almost every day. I haven't bothered to insert json5 in our pipelines for various reasons, but I sure wish it was the default.
The interesting question I think is, why do you think json is so used in that capacity despite not being meant for it? Why YAML, despite being so widespread, hasn't swept json away for those purposes? (let's for a moment ignore that YAML can go REALLY nuts, and think only of the simplest version of it)
Also, "human-readable" is somewhat of a relative term. I can read a hexdump of many binary protocols as easily as I can English, and over a billion humans can read a language that seems impenetrable to the other several billion on this planet.
> It is a data serialization format intended to be read by software.
This really... doesn't matter. Humans read and write it all the time. If everybody is getting annoyed at it because they're reading it, they have every right to wish it was more human-readable, hence trying to make it so. There's nothing wrong with that.
Programmer readable, not user readable. It's far easier to learn what it means by just looking at an example than by reading some abstract documentation as you would have to with binary data or some home-made format.
I enjoy using json5. I solves a real problem imo..
Regarding the criticism, I get the same bad energy when people get a kick out of fixing someone’s grammar, and then do not even comprehend what is being complicated.
Well done on the lib and thanks for building something useful! Good writeup also! Think I’m going to give the commit access trick a shot.
Perhaps the fact that it's popular is exactly what those nay-sayers were worried about. They didn't want a more fragmented world of incompatible standards.
Some appealed to unrealistic things though, like “all decent text editors should help to make json typing/formatting bearable instead”. Yeah, that totally worked before and will work this time too. We’d all do much better if our standard formats weren’t such an annoyance to work with in the name of something that computers wouldn’t even notice eventually. If there is a void inside a busy place, it will be filled regardless. With that in mind, think what would happen if something much less adequate filled that void. They didn’t want world which couldn’t care less about how anyone wanted it to be. But that’s what we can only have.
I don't think ignore the haters is sage advice in this context. What was directed at this project in the original HN thread was not hate, it was criticism. These are very different things. People were not abusing the author. Some of the original commenters had very salient critiques, and questions.
"Ignore the haters" reads like: "I ignored all criticism of my idea, and some other people like it anyway.".
There's already so many terrible technologies in the web programming domain that have plowed onwards in the face of so much criticism, and now we're stuck with them. Part of being a good programmer is being humble, and accepting that you might not have all the answers, the best ideas, or see the bigger picture.
Does ‘downloads per day’ actually mean anything? It could be someone large company’s CI system building on every commit.
I don’t think I’ve ever seen a JSON5 file in the wild.
I’ve always wanted comments in JSON, but the other issues highlighted are not things I care about. The ‘be lenient in what you accept’ philosophy is a disaster, just look at HTTP… stricter is better IMO.
Although I cannot assume, I'd at least hope that a "large company’s CI system" would cache the frequently encountered version(s) of a certain dependency :/
"The ‘be lenient in what you accept’ philosophy is a disaster" - I've seen that stated before, and I don't think I quite agree. It depends on how much market power you have - if you're Chrome or Safari, I agree, you should display non-compliant pages in a way that makes it obvious that they're broken.
But if you're just developing a backend component that happens to consume data in a particular format and it's not part of a system that millions depend on daily, ensuring it can handle non-strictly-conforming input well usually pays off (but by all means, do what you can to warn relevant users).
CI like that can give you some boost, but if the project is building many times a day, the dependencies are cached somewhere. Otherwise people get too annoyed with delays. There may be a phase of lots of downloads, but then it gets fixed.
On the other side of this, it's fascinating how often people fall susceptible to arguing why something should or shouldn't exist for someone else, rather than just making a limited statement about utility for themselves. Something to stay cognizant of, this article is a good lesson on empathy!
Json comments is something I always wanted, for json files with data that you need. I even use regexp to remove them in some cases (where I know it won't conflict with the strings themselves).
Didn't knew about this json5 thing but I'll try to use it instead.
Phew, when I read these posts, I often wonder if I said something dumb in the past and I think I can easily be proud of my comments there, though I missed the JSON5 thing[0]. Fortunately, the thing that keeps me from saying dumb shit about other peoples' tech is:
* my belief that people who execute on some project are inherently superior - they made a thing to solve a problem! Automatically superior to people who didn't make a thing
* the Blub Paradox http://paulgraham.com/avg.html I can only judge projects accurately where I am operating at a higher-level of thought. If I don't get the need, then I am probably not operating at a higher-level than the author. I prefer to be able to have sufficient Theory of Mind thinking that I can inhabit the author's mind to see why they need something, make the best case for it, and then reject/accept it if I have to. There are many places where I can't. The most trivial example which everyone grasped before I got there is GraphQL as an API specification and IDL, which I only recently really grokked.
In any case, I had a figment of the idea that you talk about which is the "people who won't be your users". Thanks for citing the thought around that.
Regardless of JSON5, I realized it's just not constructive to tell someone why something they made will fail. It would be great if you could tell them how to prevent failure, but just portenting it serves nothing.
I'll take any feedback. If someone tells me I'm dumb and have it wrong, I thank them and fix it. Now they can't complain about it, I learned something, and someone spent their time giving me free advice.
But if they don't convince me I'm wrong, then I ignore them. :)
I can really relate to this. I posted something earlier this year about how a number of file system problems are directly related to an archaic architecture that was designed when hard drive capacities were measure in MBs. I offered a possible solution in a hobby project that I have been working on for years.
While there were some really good comments, the vast majority were very negative and critical. (BTW: the comments on HN were much more civil than on Slashdot where the story also got picked up) Still, I didn't ignore the criticism but tried to learn from it and there were some encouraging comments mixed in as well.
I read through most of those comments and while a lot of them are critical or negative I would still say most of them are "good" as in that they are constructive and give feedback on the idea or it's execution.
When you say "While there were some really good comments, the vast majority were very negative and critical" it sounds like you think that negative or critical comments cannot be good.
>(BTW: the comments on HN were much more civil than on Slashdot where the story also got picked up)
Slashdot stopped being a worthwhile place to frequent at least 10 years ago. It's devolved into an utter cesspool, since all the quality people fled for greener pastures ages ago. I recommend ignoring its existence altogether at this point, along with any comments from that site.
JSON5 isn’t a crazy language. Just used some productions from ECMAScript spec that is already part of JS. Anyone familiar with JS should pick up JSON5 quite easily.
I believe VSCode uses json5 with .json extension for a whole bunch of their configs.
In videogames, "If there are enemies ahead of you, then you are going the right now."
I have long held the belief that if the audience of Reddit or Twitter or Slashdot or Hackernews universally hates something with such vehemance that you doubt your own thoughts then you are probably doing the right thing.
In the words of Casey Neistat, in his video "Do what you can't." - "To the haters, the doubters, my 7th grade vice principal, to everyoneone who has ever anyone with a dream they can't..."
"Horrible. There's a reason JSON is homoiconic with valid javascript." is a weird comment to read about something that takes JSON closer to javascript.
I remember the original thread and agreeing about the comments addition. I still think it's a poor addition. That said the meanness is disappointing. Congrats to the author for persevering.
Glad to see basic common sense winning out. Crockford was too strident about defending his spec. These are minimal changes that sensible developers find useful in their daily work.
I integrated json5 into a project I regularly use. JSON5 saved a significant amount of ongoing debugging. I appreciate the efforts that went into the project. Thank you.
I really like json5’s comments support, especially when json is used for configuration files so you can explain specific confit without needing to do it in a separate file
I don't think writing an article about hackernews comments from two years ago is exactly what I'd call a lesson in ignoring the haters, but this reads a little bit like someone writing an article about the roaring success of null references after their adoption.
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
From my experience, the current generation of programmers value convenience beyond everything else, with a great margin.
This is not wrong per se, but it calls for much more complex code which handles all the edge cases, and hurts performance at the end of the day.
Then, this small performance penalties pile-up and the same developers ask why their code is not working as fast as it should.
I don't call for very pedantic formats, and extremely hand-optimized systems. I just wish there was some more awareness of the trade-off they're making and making small inconvenient, but technically lighter trade-offs, these codebases can obtain very dramatic speedups.
He is ignoring the haters. He continued despite their comments. He is mindful that the haters exist (which you have to be, in order to ignore them), but is ignoring them with respect to the advice they offer.
The haters were also wrong. They completely misunderstood the needs of the target audience for JSON5. They forgot the world is a messy place, no matter how clean and clear the JSON spec may be, the input from random users may well be messy...
I'm guessing even you simplify your life by using autocorrect and spell check from time to time. Autocorrect has its issues too, it probably makes us lazy and sloppy, but on the whole, it improves the input experience for a lot of users, so on balance, people choose to keep it around.
I'm kind of appalled that the Hashicorp guy went that far to put someone down for just building something they found useful to themselves. What a great way to discourage someone from expressing themselves creatively. Glad Aseem carried on regardless.
I regret it! As Aseem said, I admitted fault and apologized for this. Here is an excerpt from an email I sent Aseem when he approached me about it (as he noted in his post).
> I’m sorry about it, I’m sure it was offensive in many ways. But while clear in hindsight, I certainly didn’t realize it at the time. Its not an excuse, but I was 21 years old at the time and my EQ was well… under-developed. I didn’t mean any harm, I was mostly having fun with it, and I’m happy to hear your project is doing well. Anyways, congrats on the success, sorry for the unkind gesture, I would never do such a thing anymore.
Aseem accepted my apology, and I'm very happy to see his project succeed the way it has! I obviously disregarded the project and he proved me (and many others) wrong!
Umm you can find burning trash in your backyard useful to yourself - but it's still polluting the neighborhood (eg. people using this crap in APIs or pulling down useless dependencies to get this). It's especially bad if you start promoting your practices and get your neighbors start doing this as well.
I completely understand the reaction and find his repo a very appropriate response.
I'm pretty sure the reaction was caused by project's name and had nothing to do with discouraging creativity. If it actually presented itself as "something someone build because they found it useful to themselves", the HTML7 joke wouldn't make any sense at all.
Let me give you a data point from a neutral perspective (I have never heard of you or JSON5).
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.
The kind of people who leave criticism on HN are not worth listening to anyway. Most of the users of this site have no taste and think they're more brilliant / important than they actually are.
I think you will find that a great diversity of minds are attracted to this site, and for reasons you may not have considered. Curiosity is a giddy thing, and it is a fundamental part of what draws me here. If you read this site and see only the occasional jerk rather than the experience-driven insights, that is your misfortune. Maybe instagram is your thing. I hear they have a lot of cat pictures.
I'm really puzzled by "JSON is for machines, not for humans" types of comments here. FFS, JSON has whitespaces, that alone should answer who it was made for. And making human-readable formats more human-readable is a good thing. JSON5 is awesome.
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.
Here's the old (2012) HN thread with the haters in it: https://news.ycombinator.com/item?id=4031699 . Happy to see an old (positive) comment of my own that I had forgotten about, which I think sums the whole thing up quite well. It still applies, so I'll repost it here:
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.
the general attitude of the critics is correct. the name you chose has implications that are not true - JSON5 has nothing to do with JSON and you have nothing to do with the people who came up with JSON. have you named it something else, you'd receive far less (if any) negative comments.
I still don't get what the point of json is. If you want to dump raw JS data structures as text just do. You don't need a spec or special tools. If you want human readable XML just use s-expressions. Something that's so easy to parse you can roll your own in an afternoon.
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.
"s-expressions" is vaporware. Everyone who says it has a slightly different format in mind. It's easy to be all things to all people when you don't have to actually implement anything.
No, these goals aren't mutually exclusive and I am not sure where "shoot myself in the foot" fits here. It's a serialization format and has many practical use cases. At least back your claims with concrete examples.
There's only a single JSON ISO standard (21778:2017). Why do you feel compelled to comment on topics you don't have knowledge about?
If I wanted to dump raw JS data structures as text the most straightforward way I can think of is `JSON.stringify` and `JSON.parse`. No need to roll your own S-expression parser.
furyofantares|3 years ago
There may be a tiny bit of signal in such comments but it's mostly just noise. I try to just ignore any comment that looks like the commenter just wrote whatever came to their mind, they're gonna forget about it in 10 seconds too when they're off to the next thing to react to.
vlunkr|3 years ago
JSON is useful partially because it’s easy to parse, so parsers already exist in every language. Extending the syntax is undoing all the communal work, and encroaching on grounds that YAML and other languages already cover.
leaflets2|3 years ago
Since this behavior is so common, apparently it works, evolutionary:
It makes others think your are smart, for a long while
And not much effort required, on your part. So, a great opportunity?
And the more popular the project you start bashing is, the smarter you'll seem? Corollary: If one builds something great, one will get dissed by some.
wildwildtest|3 years ago
Also, I think it’s very poor character to say on one hand that people’s reaction doesn’t bother them and dedicate a third to a half of the article to Mitchell’s criticism specifically. I think Mitchell’s criticism is completely reasonable (I remember this as an era of “solving json” through multiple alternative formats) and drawing attention to what seems in retrospect as a mean-spirited act is actually quite a cynical attempt to strip the context of it and deliberately cast Mitchell in a poor light. Mitchell’s intention is very clearly a technically minded one to nudge people away from trying to massage long term, durable standards in often trivial, subjective ways with an end goal that can only result in format thrashing that doesn’t ever address anything substantial.
mikkergp|3 years ago
Additionally in terms of the criticism, I observe the inverse phenomena to what you describe. You say that popularity isn’t a good indicator of goodness, but I think the inverse is goodness isn’t an indicator of eventual popularity. Some very elegant solutions just aren’t flexible enough for the real world. It is short sighted to try to argue some objective definition of badness because it doesn’t solve a problem you have or doesn’t fit your version of what a product like that should be. Sometimes in the absence of perfection people just have to get work done and want tools that make that easier.
11235813213455|3 years ago
Dylan16807|3 years ago
aseemk|3 years ago
https://github.com/babel/babel/blob/b1e73d6f961065c56427ffa8...
ttiurani|3 years ago
https://nigeltao.github.io/blog/2021/json-with-commas-commen...
mikepurvis|3 years ago
Xenoamorphous|3 years ago
bawolff|3 years ago
Everything else is a matter of taste, and who really cares.
unknown|3 years ago
[deleted]
pjbk|3 years ago
smitty1e|3 years ago
As long as we're clear that JSON5 never gets a .json extension, what is the problem?
moffkalast|3 years ago
https://xkcd.com/927/
codedokode|3 years ago
Just adding comments and multi-line strings doesn't make it human-readable, it is still too bloated and I don't like writing it manually. If you want a human-readable format, try at least to remove unnecessary quotes, brackets and commas and make it look similar to YAML.
JSON is not intended to be used in configs and other user-editable files.
kryptiskt|3 years ago
It's a primary goal of JSON, it's fair to question whether it's successful at it. Personally, I'd much rather write TOML or S expressions. I don't like YAML at all, the whitespace sensitivity drives me nuts.
dietrichepp|3 years ago
Yes, but it’s a bit late for that.
It sounds like you’re advocating for a configuration format somewhere in the space between JSON and YAML. Not JSON, because it’s annoying to write by hand, no comments, no trailing commas. Not YAML, because of all those unintuitive edge cases like “no” (unquoted) being a Boolean.
It sounds like the primary disagreement here is where in the design space between JSON and YAML is the right syntax for configuration files.
Jare|3 years ago
The interesting question I think is, why do you think json is so used in that capacity despite not being meant for it? Why YAML, despite being so widespread, hasn't swept json away for those purposes? (let's for a moment ignore that YAML can go REALLY nuts, and think only of the simplest version of it)
userbinator|3 years ago
cgrealy|3 years ago
ajkjk|3 years ago
This really... doesn't matter. Humans read and write it all the time. If everybody is getting annoyed at it because they're reading it, they have every right to wish it was more human-readable, hence trying to make it so. There's nothing wrong with that.
sacrosancty|3 years ago
orthoxerox|3 years ago
bobbylarrybobby|3 years ago
gervwyk|3 years ago
Regarding the criticism, I get the same bad energy when people get a kick out of fixing someone’s grammar, and then do not even comprehend what is being complicated.
Well done on the lib and thanks for building something useful! Good writeup also! Think I’m going to give the commit access trick a shot.
arinlen|3 years ago
And what problem would that be?
sacrosancty|3 years ago
wruza|3 years ago
livinginfear|3 years ago
"Ignore the haters" reads like: "I ignored all criticism of my idea, and some other people like it anyway.".
There's already so many terrible technologies in the web programming domain that have plowed onwards in the face of so much criticism, and now we're stuck with them. Part of being a good programmer is being humble, and accepting that you might not have all the answers, the best ideas, or see the bigger picture.
dietrichepp|3 years ago
secondcoming|3 years ago
I’ve always wanted comments in JSON, but the other issues highlighted are not things I care about. The ‘be lenient in what you accept’ philosophy is a disaster, just look at HTTP… stricter is better IMO.
snookerdooker|3 years ago
onion2k|3 years ago
I don't think you understand quite how many 60,000,000 downloads per week is if you think a big company's CI pipeline might account for that.
wizofaus|3 years ago
viraptor|3 years ago
kag0|3 years ago
> JSON5 is in the top 500 by both dependents and PageRank
that probably confirms the project is significant but doesn't answer your question.
abirch|3 years ago
ryscheng|3 years ago
LtWorf|3 years ago
TrianguloY|3 years ago
Didn't knew about this json5 thing but I'll try to use it instead.
JoshuaEN|3 years ago
yawnxyz|3 years ago
cbarrick|3 years ago
renewiltord|3 years ago
* my belief that people who execute on some project are inherently superior - they made a thing to solve a problem! Automatically superior to people who didn't make a thing
* the Blub Paradox http://paulgraham.com/avg.html I can only judge projects accurately where I am operating at a higher-level of thought. If I don't get the need, then I am probably not operating at a higher-level than the author. I prefer to be able to have sufficient Theory of Mind thinking that I can inhabit the author's mind to see why they need something, make the best case for it, and then reject/accept it if I have to. There are many places where I can't. The most trivial example which everyone grasped before I got there is GraphQL as an API specification and IDL, which I only recently really grokked.
In any case, I had a figment of the idea that you talk about which is the "people who won't be your users". Thanks for citing the thought around that.
Congrats and good luck!
0: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
stavros|3 years ago
beej71|3 years ago
But if they don't convince me I'm wrong, then I ignore them. :)
leaflets2|3 years ago
What if, though, they convince others that you're wrong -- so no one wants to use your software?
(although it would have been helpful to many)
didgetmaster|3 years ago
https://news.ycombinator.com/item?id=30449263
While there were some really good comments, the vast majority were very negative and critical. (BTW: the comments on HN were much more civil than on Slashdot where the story also got picked up) Still, I didn't ignore the criticism but tried to learn from it and there were some encouraging comments mixed in as well.
SahAssar|3 years ago
When you say "While there were some really good comments, the vast majority were very negative and critical" it sounds like you think that negative or critical comments cannot be good.
midoridensha|3 years ago
Slashdot stopped being a worthwhile place to frequent at least 10 years ago. It's devolved into an utter cesspool, since all the quality people fled for greener pastures ages ago. I recommend ignoring its existence altogether at this point, along with any comments from that site.
nojvek|3 years ago
I believe VSCode uses json5 with .json extension for a whole bunch of their configs.
It would be a slower parser than JSON though.
justinlloyd|3 years ago
I have long held the belief that if the audience of Reddit or Twitter or Slashdot or Hackernews universally hates something with such vehemance that you doubt your own thoughts then you are probably doing the right thing.
In the words of Casey Neistat, in his video "Do what you can't." - "To the haters, the doubters, my 7th grade vice principal, to everyoneone who has ever anyone with a dream they can't..."
remram|3 years ago
Dylan16807|3 years ago
stickfigure|3 years ago
Dylan16807|3 years ago
jaimex2|3 years ago
Keep it simple.
smrtinsert|3 years ago
keithalewis|3 years ago
hsbauauvhabzb|3 years ago
wdb|3 years ago
unknown|3 years ago
[deleted]
Barrin92|3 years ago
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
bayindirh|3 years ago
This is not wrong per se, but it calls for much more complex code which handles all the edge cases, and hurts performance at the end of the day.
Then, this small performance penalties pile-up and the same developers ask why their code is not working as fast as it should.
I don't call for very pedantic formats, and extremely hand-optimized systems. I just wish there was some more awareness of the trade-off they're making and making small inconvenient, but technically lighter trade-offs, these codebases can obtain very dramatic speedups.
Aperocky|3 years ago
is-odd
pledg|3 years ago
osrec|3 years ago
The haters were also wrong. They completely misunderstood the needs of the target audience for JSON5. They forgot the world is a messy place, no matter how clean and clear the JSON spec may be, the input from random users may well be messy...
I'm guessing even you simplify your life by using autocorrect and spell check from time to time. Autocorrect has its issues too, it probably makes us lazy and sloppy, but on the whole, it improves the input experience for a lot of users, so on balance, people choose to keep it around.
unknown|3 years ago
[deleted]
dejawu|3 years ago
mitchellh|3 years ago
> I’m sorry about it, I’m sure it was offensive in many ways. But while clear in hindsight, I certainly didn’t realize it at the time. Its not an excuse, but I was 21 years old at the time and my EQ was well… under-developed. I didn’t mean any harm, I was mostly having fun with it, and I’m happy to hear your project is doing well. Anyways, congrats on the success, sorry for the unkind gesture, I would never do such a thing anymore.
Aseem accepted my apology, and I'm very happy to see his project succeed the way it has! I obviously disregarded the project and he proved me (and many others) wrong!
okanat|3 years ago
moonchrome|3 years ago
I completely understand the reaction and find his repo a very appropriate response.
seba_dos1|3 years ago
cmdialog|3 years ago
[deleted]
unknown|3 years ago
[deleted]
fefe23|3 years ago
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.
LtWorf|3 years ago
Someone online told me another library (released after mine) was doing the same thing.
Turns out other library has very obvious bugs, is 20x times slower, but it has 8x more downloads.
Yep downloads are not a metric of quality.
Tainnor|3 years ago
Can't say for sure about Mozart, although I really would not put it past him to do so.
But here's Beethoven doing the same thing: https://quotepark.com/quotes/2122354-ludwig-van-beethoven-o-...
unknown|3 years ago
[deleted]
hnusersarelame|3 years ago
pestaa|3 years ago
froderick|3 years ago
livinginfear|3 years ago
> ...Most of the users of this site...
> ...think they're more brilliant...
I suppose the above critiques are not directed at yourself?
cassianoleal|3 years ago
jackblemming|3 years ago
politelemon|3 years ago
zaat|3 years ago
yetanotherloser|3 years ago
AndriyKunitsyn|3 years ago
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.
unknown|3 years ago
[deleted]
jimrandomh|3 years ago
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.
pvg|3 years ago
unknown|3 years ago
[deleted]
throwaway0x7E6|3 years ago
unknown|3 years ago
[deleted]
thrown_22|3 years ago
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.
lmm|3 years ago
TylerE|3 years ago
halayli|3 years ago
There's only a single JSON ISO standard (21778:2017). Why do you feel compelled to comment on topics you don't have knowledge about?
t0astbread|3 years ago