JSON5 is a proposed extension to JSON
json5.org
json5.org
Maybe the question is instead; why the hell do we need comments (and loosening of t he syntax, etc) in the first place?
Are we seriously going to keep insisting on json as a configuration format?
As Stormbrew already pointed out, we already have a format that is ideal for configurations (and sure, data exchange, why not), and it is called yaml.
yaml have comments
yaml makes it easy to enter multiline strings
and most if all; yaml is very very easy to write!
tl;dr: Just use a format suited for your needs instead of trying to change something that doesn't. Oh, and a couple of smiley faces thrown in there to ensure people don't read this in the wrong tone. People do that.. Like, all the time.. damn, now my tl;dr is too damn long! i have to add another.
tl;dr;tl;dr YAML BITCHES! (╯°□°）╯︵ ┻━┻ (but also, a puppy: http://i.imgur.com/kuDsS0i.jpg )
Because of what?
I used to work on a project which users could edit a configuration file through a web editor and we chose YAML because writing JSON by hand is painful (I hate the comma error!). But we processed this YAML file for the user on the server side, so having a native YAML parser in browser and Javascript wouldn't really help me at all.
For example, a configuration-data file format for specifying a "brush" in a JS-client paint program. That'd obviously be a schema on top of JSON, right? Well, now you've got all of JSON's inherent limitations.
Highly annoying for configuration files.
Are you serious? Would you put tabs in source code too?
> and most yaml parses if they see a tab don't warn you or anything
If they warned you, you still can't use tabs it's just that you're more aware that you can't use them.
It's not entirely clear to me what your point is. Perhaps it's that tabs is your preference. Unfortunately, spaces are the preferred whitespace marker for 99% of programmers.
Also, pulled directly from the YAML FAQ [1]:
Why does YAML forbid tabs?
Tabs have been outlawed since they are treated differently by different editors and tools.
And since indentation is so critical to proper interpretation of YAML, this issue is just too
tricky to even attempt. Indeed Guido van Rossum of Python has acknowledged that allowing TABs
in Python source is a headache for many people and that were he to design Python again, he
would forbid them.
But I am glad that YAML made any choice at all. Allowing mixing is absolutely the worst possible option.
[1] Think in particular of when code moves around. Sometimes it moves to a place where the indent level is different but the total number of expanded spaces is the same. This looks fine until you look in another editor.
No thanks, YAML is a terrible choice for configuration files.
Look at the database.yml files that come with Rails applications, or look at the +MANIFEST file that pkgng requires on FreeBSD.
Those are yaml files, no triple dashes.
Calling me incompetent isn't helping your case either.
This is exactly why Smart Tabs is the only intelligent way to do it - if you change the width of a tab, everything resizes instantly to match the current user's aesthetics, but things that need to be aligned stay aligned. The only case in which it breaks is if you switch to a non-monospaced font, and in that case, God help you.
Spaces just get out of my way.
P.S. I'm undoubtly biased by Python. The community's agreement on spaces and specifically 4 spaces has been a pure blessing.
99% of which programmers?
The Linux Kernel uses tabs for indenting
Of course. Why the fuck wouldn't I put tabs in source code?
We INDENT the code pressing tab. We don't press 4 spaces. Why shouldn't the code reflect that? And tabs are symbolic (logical entities), so they are customizable.
You suggest we'd rather use the elaborate kludges to handle spaces as tabs in the editor? What year is this? 1978?
Most editors have a "tab button prints spaces" option that isn't too difficult to find. (Plenty of them have a format code option as well, so it isn't such a big deal, but overall I find it easier just to switch everything to spaces.)
I never had that experience, and I've used Vim, Eclipse, ST3, TextMate and BBEdit. How does that ever happen?
A tab is a tab, no matter the editor. One might be set to show it as 8 chars wide or 4 chars wide etc (since it's a logical unit), but no indentation gets "messed up".
If by identation you mean: "variables arranged to start at the same point because the programmer has OCD", maybe. But no declarations or indentation that matters, like braces etc ever changes.
>Most editors have a "tab button prints spaces" option
Yes. The back-to-the-seventies elaborate kludge I've already mentioned. It's 2014.
In that case you would have to set your editor to display 8 spaces per tab, or 4 or whatever the code editor where the code was written was using. I don't see that being any less of a kludge than changing it to do spaces when a tab is pressed.
I have given you a reason why I prefer spaces over tabs. Your reasoning seems to be "because I can". Then start harping back to the 70's despite that part of your comment being irrelevant.
Is there an actual reason you prefer tabs over spaces, given that you can't visually tell the difference most of the time?
I for one am looking forward to the time when neural implants will translate my high level programming thoughts into microcode sent directly to the CPU for execution.
They stick the damn tab in, then the program that is parsing said YAML file does the wrong thing and I am confused, annoyed, and most times really pissed off because I will spend hours trying to figure out what went wrong.
YAML is stupid for configuration files.
https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04...
Also "Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser."
Seems like a perfectly fine way to have comments (if you absolutely need them) in a production environment.
function JSON5_to_JSON(str) { return JSON5.parse(str).stringify(); }
This is exactly what is suggested in the Usage section of the linked article.
The point of a standardized serialization format is well-defined parsing semantics and universal interoperability.
That will then be their own bloody problem, not Crockfords.
config = { "version": "1.0", "comment": "JSON has comments too!" }
And since it's a configuration format, you know what keys are accepted and what keys are for the metadata, and thus won't clash.
I don't like JSON either due to the comment issue; simple ad-hoc configuration formats like most C programs seem to have mostly work, but aren't as nice as a standard format. If anything, I like configuration files expressed as scripts in whatever language the program is written in, since they're very flexible (if I want 100 almost-identical entries for whatever reason, I can say so in the file rather than writing a separate generator), and while programming languages are complicated, people tend to already know them; but that does tie you to a specific language.
Anyway, http://ogdl.org/ is one candidate for YTGP (YAML The good parts) but it's comments can carry metadata, which is a huge turn-off, others think TOML (https://github.com/mojombo/toml) is a good replacement, but it has no support for alternate number types. You write in something like
mask = 0xDEADBEEF
mask = 3735928559Unfortunately YAML for untrusted input and data exchange is unsafe by default, depending on the language and implementation. A flag might need to be set, or extra modules included like SafeYAML[1] to keep Yaml from instantiating arbitrary objects.
Why would that be an issue when using it as a configuration format?
There's a interesting format for configuration called TOML[1], you should check it out!
Yes. It has good universal support, often without needing any libraries, it's simple, succint, and has good tooling.
>As Stormbrew already pointed out, we already have a format that is ideal for configurations (and sure, data exchange, why not), and it is called yaml.
Let's just not go there. YAML is a pain in the ass to parse, has different incompatible versions, the libraries are of widely varying quality, is not natively (without third party stuff) supported in most languages, and it's generally a mess.
What I'd keep in YAML is the information model. When we started YAML ~12 years ago, it was obvious that configuration should be in XML, and that XML's information model was the correct way to organize data structures. Part of YAML's work was explaining a different way of doing things to those who'd otherwise use XML. This isn't a concern these days...
That said, the productions look painful because the specification doesn't separate the scanner from the parser. Once you do that, the syntax is quite a bit more sane to grok (see PyYAML source). It's not nearly as bad as what you may think... IF you see it this way.
Besides a few unfortunate syntax structures, YAML's complexity and sharp edges comes from it's venture into typed objects, type-spaces, and implicit typing. Much of this, for configuration files, is unnecessary.
When we wrote YAML, we only had a few years experience with it; and well, it wasn't done as a full time endeavour. It was a guess as to how things should work. It wasn't easy to bootstrap YAML. It's now ten years later... and, well, lots of people have experience with it. It's probably time for the haircut.
I love yaml -- except on the rare by very painful occasions where I get hugely bitten by incredibly weird problems arising from unexpected interplay of yaml features.
Some of the originators of yaml are probably the only people who the social power to promulgate a revision with a haircut. That would be awesome.
I like the promise of YAML, but having tried it a could of projects, found all these issues which prevent it to be a simple, turn-key solution that JSON can be (at least for simple needs).
How do you feel about TOML? I find it a sane compromise, at least for congiguration file needs.
(Certainly I acknowledge that it is not as ubiquitous as JSON or YAML, but I do like TOML better than both of those for configuration.)
Only when somebody pointed out that obvious fact to them, did they come up with a recursive retronym to paper over their initial stupidity: "YAML Ain't Markup Language". How clever by half.
I prefer to use formats that were designed by people who actually knew what they were doing and what it was called and how it was meant to be used.
For your particular scenario, where your file format is similar to json already, it's not a lot of work to parse the file, and remove lines which - when stripped - begin with '#'. That's five minutes' work.
Json is a wire protocol. We had XML before that, but XML tries to compromise between being a wire serialisation format, and lots of other features (e.g. human-editable, file serialisation, schemas).
Crockford's decisions are a picture of minimalism. He wanted to find a way to get a standard wire format, without making any changes to javascript to get it. Json isn't perfect as a wire format, but it remains effective as a balance of those priorities.
The original post says, "JSON's usage has expanded beyond machine-to-machine communication." This is the source of the problem - the author wants to compromise JSON's mission to serve a non-core functions, things that are unrelated to being an available-everywhere wire protocol.
If we do json5, pretty soon someone else will be pointing out that we need to encode json schemas. When we point out that it's a compromise on the mission, they'll say, "that's OK - we've already made the decision to make JSON a general purpose format. Look at the way we added comments, which goes against the mission."
We'll get into hassles with libraries and versions. This is the road to XML. We already have XML, it's a horror to work with, and the reason for that is that it tries to be all things to all people instead of being a sharp tool.
Before XML we had SGML. When XML was young, I was involved with projects that chose it because it was simpler than SGML. XML is now far more complicated than SGML, in different ways of course. Now people overlook XML (it's too damn complicated!) and use json.
Fortunately Crockford seems to have foreseen the problems here, and made hard decisions early (no comments) in order to entrench against a repeat of the pattern.
_dontcare = {es5: syntax, /*with comments*/}
data = JSON.stringify(_dontcare)
?I've used CSON before, main reason being that I wanted a config file with comments plus easy integration with a JS/CS project. YAML also works well.
Except when sketching out a static JSON file that you'll eventually implement as a real API connected to a database, once you've experimented and arrived at a good structure. I do this a lot. I wouldn't output JSON5 from a live API, but I would use it for sample data in development.
I'm not saying JSON is perfect just providing a counter argument and stating a general belief I have about over complicating thing when a simple companion tool or something like CSON works just as well. CSON or CoffeeScript are good examples because they provide a more pleasurable environment for the developer but at the end up the day compile down to their native JSON or JavasScript respectively. I think we are in agreement in that I dont like the JSON5 syntax should necessarily be what's going over the wire.
Literally the only difference between coffeescript.eval and cson.parseSync is that the latter runs in a sandbox. You can't screw up so badly as to cause global side effects, and you can't require modules, but that's where the safety ends.
For example
cson.parseSync("Math.sqrt")(4)
cson.parseSync("1 while true")
That's very powerful for config files; I'd much rather have my config say "y: Math.sqrt 2" than "y: 1.4142135623730951". But it means that you absolutely must not parse CSON that comes from an untrusted source.
Now obviously JSON5 provides very little over JSON as a data-exchange format. In fact, the only practical advantage I see is that you can use Infinity as a value.
I can see two use cases for this:
1. You have a web service for developers, and you want human-editable config files that can be parsed safely on the server side. CSON won't work there, and JSON5 would be nicer to work with than JSON. It's a good thing that JSON5 is a strict superset of JSON, because this is one hell of rare scenario.
2. You want your exchange format to be more human readable for debugging and testing. This use case isn't realistic, however, so long as JSON5.stringify is aliased to JSON.stringify.
Check out their WIP https://github.com/bevry/cson/issues/33
The rest of the changes I'm not so keen on.
Are you generating JSON as freeform text? Because a call to JSON.stringify (or whatever JSON-dumping method exists in your language of choice) would not be "made nicer" by handling trailing commas.
I don't mind the idea of alternate syntaxes that compile to json in the spirit of coffeescript or less/sass/haml etc.
Coffeescript makes it very clear that it is just an alternate syntax for javascript. If that is the aim of json5 that is cool. I just don't want to see public APIs producing and consuming json5 in the wild and breaking stuff.
The proposed modifications are utterly trivial and don't really make anyone's life better.
Hand-hackability and simplicity is why we use JSON. These changes definitely make things better for humans.
So this proposal is coming back and fixing that silly limitation.
That is, if you really want comments, crockford says, go ahead and add them. Just remember to remove them before parsing as JSON. Which is actually not that hard. you can even do it with sed. Just for the love of crock don't put processing directives in the comments.
What?? By that logic, you might as well hand-write x86 assembly, since C requires a "preprocessing" step (some might call that compilation).
Using "JSON5" as a human-writable format for storage and then compiling it to real JSON before going over the wire seems like the best of both worlds to me. The wire format benefits are preserved, the format is validated as a side effect of compilation, and you get to write in a well-defined language with comments and bareword-identifiers. Your objection is that you don't want to run a compiler, so you'd rather send JSON5 over the wire?
> dumb suggestion .. defeats the entire point of having JSON in the first place
As a side note, negativity for the sake of being negative does not help the conversation at all. Please take that kind of attitude somewhere else.
These are poor modifications. Don't modify JSON to be a better configuration format, just use a better format.
Rather hard to do when the rest of the world you need to interact wouldn't necessarily move with you.
Extensible types would be the next thing to add.
Now that'd be a good extension.
And we could call it Extensible JSON language. A good abbreviation would be XJL.
And eventually we'd have a standards-body defined way of querying JSON documents. We could call it JQuery.
(</sarcasm> just in case...)
- we SHOULD have JSON comments. Have you never edited a JSON-based config file?
- No one says that HTML or XML shouldn't have had comments
- JSON5 already suggests adding comments, so your proposed extension to a sarcastic proposed extension to a serious proposed extension is idempotent
Sure, if we add comments to JSON the next thing it would be transormed into XML, and AJAX would be like SOAP.
Of course there is no problem making a new standard, mongo did that with BSON. It is different and should be called different, nothing wrong with abstractions.
The reason we all love JSON is that it has stayed the same. Develop a coffescript like JSON precompiler with comments and trailing commas and all sorts of things like no quoted keys if needed but call it something different. I think the last thing anyone wants to do it shake the JSON standard or have to have multiple parsers try for all the new JSON formats/schemas/namespaces/etc like an XML SOAP nightmare.
EDIT: Ok so it does have compiling to regular JSON but just not a fan of the name.
This file is written in JSON5 syntax, naturally, but npm needs a regular JSON file, so compile via `npm run build`. Be sure to keep both in sync!
Someone did, it's called yaml.
But this is a thing that often gets ignored when talking about what humans are good at reading and writing. We aren't computers (or at least, we aren't as linear of computers). It's obvious enough in the languages that we speak and write every day with each other that we derive from and plant a lot of meaning in the margins of our expression. We tend to understand things quite clearly when noise has been elided out. A lot of JSON becomes pure noise: "{{[[{[{{[".
Really, though, what I'm most in favour of is that now that we've agreed on a basic data model that is less insane than its obvious predecessors (ASN.1 and XML) it would be nice if applications with configuration opened themselves to allowing the user to decide the specific format for their own benefit. If it's TOML or JSON or JSON5 or JSON+comments (Sublime Text) or YAML or whatever, so long as it results in the same structure who cares?
I'd rather that be visible brackets than invisible whitespace.
Assuming 'invisible whitespace' in this context is actually a meaningful thing. I find it hard to miss indentation, if anything, to the point that given a conflict between whitespace and a sea of brackets/braces my first instinct is probably to trust the whitespace. I don't think I'm alone in that.
I just don't know what exactly you YAML guys are smoking that you think it's easy or more humanistic.
So, in YAML you can only use leading spaces. Leading tabs are an error. This confusion of yours is not at all present in the actual thing you're talking about. And if you mix them in json god help you if your editor settings don't match someone else's because you might be looking at something nearly incomprehensible that won't error or warn at all.
I mean, have you ever actually looked at a code file of any sort with mixed tabs and spaces when the person who wrote the file had a different tab stop than you? This is a readability problem no matter what. Forcing you to have sane indentation is a feature of whitespace-sensitivity, not a bug.
What exactly do you think trailing whitespace does?
If I'm smoking something, at least I've used the things I'm talking about instead of spreading weird FUD.
> A lot of JSON becomes pure noise: "{{[[{[{{[".
Pro-tip: if you are going to call someone out for not knowing a format and spreading FUD, don't post things where you do the same exact thing. It pretty much invalidates the criticisms you've been making as it says "I don't know what I'm talking about, here is proof."
Yes, the specific sequence of tokens is not valid because a list obviously can't be a key. The idea is still the same. I'll fix it so it is a valid sequence of tokens that's just as confusing: "}}}]}]}}"
Anyways, invisible syntax errors still suck. At least with json you can (eventually) figure out your braces are unbalanced. Or use a syntax highlighter to spot the problem. No syntax to highlight if you have a problem with yaml.
Crazy, huh?
I've been having to deal with large YAML config files lately, and find it's easy to miss indentation. Even with niceties that add lines to the different indentations, it's hard to keep track of where you are. Beyond a short, simple YAML file, I find it gets confusing really fast to the point of frustration.
I'll take all your suggestions.
Also, please add ISO-8601 dates (repeating my comment below)!
{ timestamp: new Date("2007-04-05T14:30Z") }
> JSON.stringify(new Date())
"2014-03-02T15:08:55.309Z"if you encode TAI in a unix timestamp, this would be a solved problem, but due to the fact that you cannot encode the time zone in the "unix timestamp datatype", you'd also have to handle cases in which people chose another timezone.
This makes it good enough for storing data (it'd be nice if the size of the data type would be explicit) but suboptimal for interoperability with other systems that could be using a different standard
either you encode the timezone in a different field in your JSON, or someone (the JSON5 people?) could define a literal for timestamps like:
t+1393752828Z (this would also eliminate the ambiguity between timestamps and number literals)
That it doesn't have a date/time type.
And this causes real bugs in real programs:
https://lists.gnu.org/archive/html/qemu-devel/2011-05/thread...
Defined numbers as int64? Or arbitrary precision bignums? Then JavaScript would not be able to support JSON without an external bignum library, which many/most applications do not actually need, and JSON would be less convenient to use.
Or would you prefer they had specifically defined IEEE double precision as the numeric representation? Then JSON numbers would be useless for qemu's offsets and other applications that need numbers not representable as IEEE double precision.
Leaving it unspecified means that implementations support what they can. If you end up needing actual int64s in JavaScript, you can drop in a BigNum library and get them. It's true that not all numbers can be represented by all implementations, but that was true already.
Leaving it unspecified means that JSON as a format is capable of arbitrary precision, without requiring that implementations carry around bignum libraries if their particular application doesn't need them.
A lack of a standard date/time type means that some people use UNIX time, others use ISO strings (which you then need to detect, parse and handle errors for), and others are crazy and use their own format, localised just to make it fun (are people writing JSON using Django templates or PHP date formatting - yes, yes they are).
To have one standard way that everyone does dates would be nice.
PS: And the HN measure of "More comments than upvotes?" clearly works as controversial/bad ideas do generally follow that rule.
> JSON.stringify(new Date())
"2014-03-02T15:08:55.309Z" > JSON.parse("{\"date\":\"2014-03-02T16:08:43.444Z\"}")
Object {date: "2014-03-02T16:08:43.444Z"}It's ok if you are expecting a Date. But when you want to write generic code that "discover" the properties, then you have to do dirty things, like trying to parse every single strings as a date.
Example: Comments were taken out of JSON because some parsers started using them to store processing instructions.
JSON has been successful because it found a sweet spot between three factors:
1. It is useful. There is enough flexibility to represent most structured data easily.
2. It is portable. There are libraries to read and write JSON data in every major programming language.
3. It is simple and unambiguous.
Things like allowing keys to be unquoted if they're valid identifiers in JavaScript and as JavaScript happens to be defined by the latest standard save two characters, at the expense of breaking portability and future-proofing, making the specification more complex, and introducing ambiguity. This is not a worthwhile trade-off.
JSON is a data encapsulation format that doesn't care about the data contained within. That is up for your programs to consume and decide.
If you think JSON needs "more" like comments, parsing, multi-line, etc. then perhaps you need to revisit your architecture.
If you disagree I am sure there are plenty of frameworks out there that will babysit your data and document things for you. But upsetting the core apple cart here would be a huge mistake.
Trailing commas are especially appealing: it simplifies outputting JSON from "(A , ) * A" to "(A , ) * ". In fact, in this respect, XML is easier to output than JSON.
But it will not be adopted. Crockford already removed comments from the JSON spec once. Guy knows what's up: it's a standard, keep it simple. If you want the kitchen sink, use XML. JSON5 will achieve about as much adoption as yaml: some. Having json in the name and syntax won't bring massive adoption.
It doesn't make sense for REST APIs. It doesn't make sense for communication between programs. In fact, its basically impossible to use this implementation for that, because (the last time I checked) JSON5 just used the JSON reference serializer. If you create JSON programmatically, it will always be valid vanilla JSON!
The use case is hand-written JSON. Either for configuration files (like Sublime Text). Or if you have hand-written data that you would otherwise put in a object in a .js file. You might want to separate your data from your code, but you can't just dump the javascript object literal into a json file, because it's not valid JSON. And maybe you want to leave comments in there, or trailing commas in lists.
If you send JSON over the wire, its trivial to sanitize it:
JSON5.stringify(JSON5.parse(sloppy_json))
In Internet Explorer 6 and 7, there is an easy to introduce
javascript bug relating to commas. If, when defining an
array or an object, you leave a trailing comma after the
last item in your collection, IE will fail to parse your
javascript file:
var x = [1,2,3,]; //ERROR
var y = {'a': 1, 'b': 2, 'c': 3,}; //ERRORJSON5.stringify(obj) produces plain compliant JSON. Using JSON5, programattically produced JSON will always be JSON 1.0. This is for configuration files, and static (hand-edited) data.
And what is wrong with just using ISO dates in strings? I mean whats the difference between, say:
"date": /2010-03-23T23:57Z/,
"date": Date(2010-03-23T23:57Z),
"date": "2010-03-23T23:57Z"
although i think coffeescript object notation was an unfortunate name choice. people averse to coffee will immediately associate bad thoughts with it.
I did it because I had a use case where the JSON file is for user input, not for computer-to-computer communication. So I wanted it to not be so annoying to edit and more importantly, to allow comments.
How many fields in all json streams ever transmitted aren't alphanum compliant? My bet is 99% of them are simple names, so forcing it to be surrounded by quotes for that 1% is just a waste of chars and shift keys, even if they're mostly automated.
I spend a lot of time designing, testing and validating apis for which I have to read tons of json, and believe me, without quotes my life would be so much easier.
Comments are also important for testing. Trailing commas would save plenty of extra code to remove them from lists.
These improvements would be mostly welcome.
https://github.com/edn-format/edn
I'd like to see a little bit more love for edn... and if you're gonna pick something incompatible with plain old JSON, why not edn?
I want a format that looks like Javascript or Python code, and that is a strict superset of JSON (e.g. can parse all valid JSON). I want to pluck my object or list literal from my Python or JS code, put it into a config file, and have it work, no matter wheter I have final commas in lists or not. I want to be able to insert comments. And I want to be able to describe it as "JSON, but you can use comments", so people will be able to understand it immediately and edit the files. This is similar to what Sublime Text uses for its config files, for example. EDN, or more prominently YAML are just not well-known enough (and the latter is hellishly complicated).
Also, a nicety of JSON5 is that it serializes into plain JSON, so interopability is always ensured.
timestamp: new Date("2007-04-05T14:30Z")
If we need to follow that logic (to include useful non-primitives) we would end up with a clusterfuck of a spec that noone would want to implement.
This hypothetical generic client always comes up in discussions of data formats and RESTful APIs. But I've never understood what use it could be. It seems to me that any meaningful software (i.e., anything beyond a debugging tool) that would consume data or an API would need a more specific UI than a tree view with links.
The actual grammar is here: https://github.com/Mouq/json5/blob/master/lib/JSON5/Tiny/Gra... (it would be nice if Github's syntax highlighting for Perl 6 regexes was more sophisticated than "turn it green," but I'm glad it syntax highlights in the first place)
https://news.ycombinator.com/item?id=4031699
That said, Aseem is very sharp. Nice to see this come up for discussion again.
And it turns out all those extra convenience features in YAML are a mess -- if you haven't discovered that yet, it's becuase you haven't been bitten by a weird edge case related to the complex interplay of features yet.
Of course, this proposal is just a few convenience features, it's not nearly to YAML level. That probably also means it doesn't add enough benefit to any developers pain points to justify anyone using it instead of the more universally recognized plain old json.
Extending rapidjson, jsoncpp, yajl, and simplejson seems like a natural place to start.
Funnily, I independently "invented" this before I found JSON5. I called it "yottson", because that's how JSON would be pronounced in German and what I sometimes call it in my head. Its a fitting name, because it is my ideosyncratic "almost JSON".
Formats like this are mostly meant to be used for configuration files. For example the sublime-text configuration files are JSON + comments. I don't know what all the hate is for, it's clear that you wouldn't send this over a wire to a client expecting pure JSON. In fact, the serializers in JSON5 and in Yottson only ever create standard-compliant JSON. Its a case of "be liberal in what you accept, strict in what you send".
One thing I'd still like to implement though is lossless parsing. The parser would keep track of all the comments and whitespace, so that when you change a value programmattically in the config file, it only modifies the value and preserves all the indentation and comments. Right now, as I mentioned, writing the file programmattically always results in pure compliant JSON, but kills all comments.
JSON should be simplified (if any), not made it more complicated.
And this is a problem why, since it SHOULDN'T BE WRITTEN BY HAND?
This suggestion adds additional complexity to every parser of the "new" format, in exchange for... nothing, apart from a few less syntax errors for sloppy hand-editors. WTF.
So you'd end up defining some well-known comment name. But then you can't serialize arbitrary data structures, because they might conflict. So that gets complicated.
After everything, the JSON spec could have allowed comments to stay in. Instead, the author went off on some nonsense reasoning about incompatibility.
If you have an object or list literal in your JS, it's already "almost-JSON". People write a lot of "almost-JSON". I want to separate data from code and put it into a data file, but then I have to remove final commas, comments, and so on. This is great for static data that would otherwise be in your code.
Also it is great as a config file format. Sublime Text uses JSON+comments, for example. Everybody who knows Python, JS, or JSON knows how to use it immediately.
I don't know where the problem is, since with the current implementation it is not possible to write JSON5 not by hand! JSON5.stringify just calls the reference JSON serializer.
The added complexity is not much, and has already been implemented. You don't need to change every implementation. It's just a drop-in replacement for JSON so you can have comments in your static JSON data files. I think it's extremely convenient. Using JSON as a config file format in Sublime Text for example is only viable since they are heavily commented.
Once that's in place, then JSON5 would instantly become much more viable...
One of the best things about json is its simplicity and rigid syntax.
If we open up this can of worms, we will incur thousands of man-years of future wasted time tracking down incompatibility issues.
JSONH is json for homogenous collections, read: csv files.
That's all I needed to hear, I'm on board.
I want trailing commas.
But the delta confuses me - what is it and how is it used and can it be negative?
"I removed pointers from C because I saw people were using them to manipulate implementation defined details of their environment, a practice which would have destroyed interoperability. I know that the lack of pointers makes some people sad, but it shouldn't."
Another of my favorites is the justification for part of why jslint is unusable in any real environment because Crockford thinks anonymous functions are unprofessional and only used by people who don't know what they're doing:
https://groups.yahoo.com/neo/groups/jslint_com/conversations...
That's asking Crockford to not be Crockford.
JSON has two unique properties among data representation languages that make it useful for certain types of tasks: 1) it is very simple to write conformant parsers and serializers, and 2) the parsed representation contains all the original semantic information in the original document (excluding maybe whitespace). If you have a separate syntax for comments, then parsers must either drop the comments (making transformation tools less powerful) or parser must provide a more complex representation (e.g. like the DOM) and drop the simple map/list/scalar data model.
Please don't make JSON the next XML! Source: I spent about 5 years suffering with XML in the Enterprise Application Integration world.
[1] Source: I've written a JSON parser from scratch and think it would be valuable
- "blah"
+ "blah",
+ "blorp"
Because it seems a lot easier to just design newer languages to be friendlier to version control than either of those. JSON has little excuse here, even when it was 'invented' it was a bad idea to simply run it through eval and pray it had nothing malicious or damaging in it, so compatibility with IE6's stupid parser wasn't really all that special. Never mind that it didn't take off as a really popular format until well after that was a concern.
And if a file is hand-edited, it's format should have niceties that make hand-editing more pleasant, like optional trailing commas, and comments.
By making the format more suited to hand-editing, you also make it better for diffing and VCS.
require([
- "blah"
+ "blah",
+ "blorp"
], function () {
It'd be great if a backend could serve JSON structures directly to the Controller, which would inform the Directive's @attr template. So maybe the problem goes away in this regard, and the build could handle AMD/CommonJS wrappers which is outside of the version control layer to an extent — or at least wrappers do not necessarily have to be.
require([
"blah",
"blorp",
], function () {