141–150 of 211 posts
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.
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.
> I enjoy using json5. I solves a real problem imo.. And what problem would that be?
Earlier quoted context omitted.
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.
I think most companies do not set up mirrors. There is no way millions of individual companies are downloading daily the same pieces of code. And if they had caching they'd download them only when a new release happens, not daily. There aren't that many companies in the world basically.
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.
Earlier quoted context omitted.
There's a lot of critics, then you look at their accomplishments and it's unsurprisingly sparse.
Some people get paid in money and not exposure.
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 long as we're clear that JSON5 never gets a .json extension, what is the problem?
Earlier quoted context omitted.
> 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?
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 liter…
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.
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. https://news.ycombinator.com/item?id=30449263 While there were some really good comments, the vast majority w…
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.
Earlier quoted context omitted.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Actually, I found this enlightening. It didn’t reduce the signal to noise ratio in any way.
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 intend…
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…
In a small file, semantic indentation is beautiful. In a large file where you have to scroll and scroll to find out where you are, it's a pain. And perhaps importantly - can't be autoformatted. Your IDE doesn't know what indentation level you intended, and without braces/brackets to tell it, it can't detect errors.
There's parsing automagic wackiness if you're not careful (the famous example: country abbreviation NO for Norway becomes FALSE).
The nice feature of references is almost never actually used in practice. An incorrect or circular reference can look fine but badly break things.
Yaml typing is application (and version) dependent so not really useful.
There's more, but basically JSON, though simpler and uglier, prevents all of those. You can, and pretty much have to, use an alternative 'safe YAML' parser, but even that doesn't solve some of the problems.
Earlier quoted context omitted.
> 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 d…
> Yes, but it’s a bit late for that. That just shows poor judgement on behalf of the developer who made that decision, not a failing of the language.
I don’t see how assigning blame is productive here. People choose the wrong language, wrong library, or wrong tool all the time.