16 ms·

JSON5 is a proposed extension to JSON

• finishingmove 13y ago
  Stopped reading at "can have trailing commas"...
  • lucian1900 13y ago
    They are really useful. The only two good options are allowing trailing commas or considering all commas to be whitespace.
    • finishingmove 13y ago
      They are ugly.
      • mmastrac 13y ago
        They also make JSON generation by machines much easier, and don't complicate the parser. [1] [1] Source: I've written a JSON parser from scratch and think it would be valuable
        • stormbrew 13y ago
          More importantly, they make it possible to have not-ugly documents (commas where they belong, after the clause they extend) work well with version control and merging. - "blah" + "blah", + "blorp" is far uglier than any trailing comma ever has been.
          • finishingmove 13y ago
            Is that a problem that should be solved on a data format level or a version control level?
            • stormbrew 13y ago
              Do you have a proposal to achieve solving it at the version control level that doesn't require either a complete paradigm shift in programming and data formatting langauges to everything being trivially an AST or embedding knowledge of every format ever invented to your version control? 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.
              • TheZenPsycho 13y ago
                if text editors can syntax highlight why can't version control systems syntax version?
            • captainmuon 13y ago
              If you store JSON in a version control system, then it is usually hand-edited JSON. (If it is generated programmatically at runtime, then the data is in a database.) 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.
          • thenerdfiles 13y ago
            require([ - "blah" + "blah", + "blorp" ], function () { AngularJS templates often can involve JSON structures for <select> and other UI junk. 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 () { I added ``blorp`` — I never removed ``blah`` except for some limitation of the language I'm using. Why should that be part of the organic record?
      • derefr 13y ago
        Comma-separated lists are inherently ugly--you're basically using a binary operator to cons values together. I can never understand why more languages don't support either juxtaposition (i.e. Lisp-like list construction) or semantic whitespace with "bulleted" prefixing (i.e. YAML-like list construction.)
        • lmm 13y ago
          Because a comma-separated list is how humans write (and read) lists?
          • deleted 13y ago
            [deleted]
      • Myrmornis 13y ago
        They're very useful to achieve clean diffs in version control. (Fwiw, I find the asymmetry of their absence ugly.)
• drawkbox 13y ago
  JSON really shouldn't change at all that is why it is so great, basic types and very simple and clean. We should build a fortified defense around JSON and keeping it the same. 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!
  • stormbrew 13y ago
    > 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. Someone did, it's called yaml.
    • theg2 13y ago
      And I still don't understand why you'd pick yaml over anything else out there.
      • stormbrew 13y ago
        I pick it for config files humans have to write and read because writing and reading json as a human is tedious and error prone.
        • vertex-four 13y ago
          As someone who has to write yaml... writing yaml is significantly more error-prone than JSON. It has far more edge cases than JSON does.
• rjzzleep 13y ago
  JSON5 == kinda cson? although i think coffeescript object notation was an unfortunate name choice. people averse to coffee will immediately associate bad thoughts with it. https://github.com/bevry/cson https://github.com/bevry/cson
• pfraze 13y ago
  Nice work, aseemk. I put together a quick jsperf [1]. JSON5 code was copy-pasted into setup, since it isn't on a CDN (that I saw). 1 http://jsperf.com/json-vs-json5 http://jsperf.com/json-vs-json5
• leeoniya 13y ago
  a bit OT, but you guys might find this useful. JSONH is json for homogenous collections, read: csv files. https://github.com/WebReflection/JSONH https://github.com/WebReflection/JSONH
• NathanOsullivan 13y ago
  How about defining a format for dates? That would be more helpful than most the proposed changes here.
  • randallsquared 13y ago
    What's wrong with ISO-8601?
    • mmastrac 13y ago
      I'd like to see explicit date types using ISO-8601 format, ie: timestamp: new Date("2007-04-05T14:30Z")
      • tudborg 13y ago
        Your appliation needs to know that "timestamp" is a timestamp anyway. Why would you want to add that to your data as well?
        • azinman2 13y ago
          To make parsing easier? By the same logic why differentiate between numbers, strings, and booleans?
          • randallsquared 13y ago
            But why stop at dates? What about all the other useful things we could put in, DOM elements and and sets and synchronization clocks...
          • tudborg 13y ago
            Because those are javascript primitive types, which json is built around in the first place. Date is not a javascript primitive, and is therefore not included. 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.
• ape4 13y ago
  I would love to not have to quote identifiers!
• mmastrac 13y ago
  I love this concept; my only concern is that by adding comments, it becomes difficult to round-trip a JSON document. XML has the concept of comment nodes that can survive a round-trip, but there's no easy way to do this in JSON. Perhaps you could limit where comments could go (ie: tagging object properties or array items only) and add a "__comments__" property to an object and/or list that contains the matching comments for the items in the object and/or array. Also, please add ISO-8601 dates (repeating my comment below)! { timestamp: new Date("2007-04-05T14:30Z") }
  • ollysb 13y ago
    For the love of god yes! a standardised date format is the only thing that really needs changing in json.
    • TazeTSchnitzel 13y ago
      We already have a standardised date format, as such. A specific subset of ISO 8601: > JSON.stringify(new Date()) "2014-03-02T15:08:55.309Z"
  • hcarvalhoalves 13y ago
    What's the benefit of cluttering JSON with a constructor like new Date(...) when you can just standardize on ISO-8601 strings? JSON is not supposed to be eval'ed anymore.
    • mmastrac 13y ago
      JSON is JS. If I manually create a JSON document, it should also be valid in the context of code. And strings are not dates -- they are strings. That's why we have boolean and number literals.
      • bennyg 13y ago
        So many other languages use JSON as a data format that keeping a weird constructor call in there would do more harm than good. Especially since you can keep the formatting code in your codebase and invoke that when you need to use that property.
• tudborg 13y ago
  As much as i would like to see comments in json: if we start throwing around json files that area not really json, but we call them json, (at least in everyday talk), we will end up breaking more apps then we fix. 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 http://i.imgur.com/kuDsS0i.jpg )
  • derefr 13y ago
    If web browsers had native YAML parsing, we probably wouldn't need JSON5. Web browsers aren't going to get native YAML parsing.
    • drdaeman 13y ago
      > Web browsers aren't going to get native YAML parsing. Because of what?
    • stormbrew 13y ago
      They probably aren't going to get native json5 parsing either (except in the sense that you can do something stupid like eval it). That said, I don't think there's any particular need for yaml in the browser. Browser code is usually dealing with machine-generated data, where even normal json is just fine.
      • derefr 13y ago
        Rich client-side apps need configuration files too.
• codehero 13y ago
  I couldn't tell, does the Numbers support include NaN?
• jaytaylor 13y ago
  It allows trailing commas, and claims IE6 compatibility. I don't understand how both can be true. 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,}; //ERROR
  • russellsprouts 13y ago
    They wrote a custom parser that works in all browsers -- it doesn't use eval. JSON5 is a subset of ES5, not a subset of JavaScript that runs in all browsers. Notice that it also allows reserved words as keys -- an ES5 feature that doesn't work even in IE8.
• raymondh 13y ago
  Disruption for basically zero benefit. The proposed modifications are utterly trivial and don't really make anyone's life better.
  • davvid 13y ago
    Hey now... When we started using JSON as our file format for scene metadata at Disney Animation these were exactly the features people wanted. Hand-hackability and simplicity is why we use JSON. These changes definitely make things better for humans.
    • TheZenPsycho 13y ago
      I like crockford's suggestion. if you need these features, write javascript. (or something akin to json5), and run it through a minified, or eval it in a javascript sandbox to convert it to plain json.
      • MichaelGG 13y ago
        So the suggestion for comments in JSON is "don't use JSON"? That's a dumb suggestion, and defeats the entire point of having JSON in the first place. No common formatting/tooling/parsing library can work with the config file if it has a comment. Every app wanting to allow comments needs to go get a full JavaScript EE and parse them as JS? That's absurd. So this proposal is coming back and fixing that silly limitation.
        • TheZenPsycho 13y ago
          The suggestion for comments was to use JSMin to process them out before handing it over to the json parser. 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.
          • 13y ago
• kenperkins 13y ago
  Good Ol Hacker News, regurgitating something from 2 years ago: https://news.ycombinator.com/item?id=4031699 https://news.ycombinator.com/item?id=4031699 That said, Aseem is very sharp. Nice to see this come up for discussion again.
• davvid 13y ago
  I'm eagerly awaiting the C, C++, and Python implementations. Has anyone started on these? Extending rapidjson, jsoncpp, yajl, and simplejson seems like a natural place to start.
  • captainmuon 13y ago
    I have a python implementation, but haven't found the time to share it yet. 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.
  • deleted 13y ago
    [deleted]
  • deleted 13y ago
    [deleted]
• ChikkaChiChi 13y ago
  This just seems to fix problems for the lazy or those that lack architectural rigidity in their development patterns. 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.
  • derefr 13y ago
    The support for numeric Infinity is basically the one unabashedly-semantic modification; it doesn't go far enough, though, since it should be possible to serialize any float, valid or invalid, in a data-exchange format. I'd think proper support would involve a Rational representation--encoding Infinity as, say, 1/0.
  • MichaelGG 13y ago
    So anyone that picked JSON as a configuration format needs to revisit their architecture? At the moment, yes. But if comments had not been forbidden then things would be just fine.
• al2o3cr 13y ago
  "JSON isn't the friendliest to write and maintain by hand." 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.
  • diydsp 13y ago
    I have a silly question, only having used JSON a precious few times, but if people want comments in JSON, couldn't that be done just by a named field within an object that follows the existing specification, iow an optional property holding a string?
    • MichaelGG 13y ago
      By doing that, you've now added more data to the object. It'd be like doing <tag comment='bar' /> in XML - the actual data has changed. 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.
  • captainmuon 13y ago
    Why shouldn't it be written by hand? 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.
• willvarfar 13y ago
  Comments are not in json for a well understood reason: https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04cipiaorjydfxg5tc0k https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04... I want trailing commas. But the delta confuses me - what is it and how is it used and can it be negative?
  • just2n 13y ago
    Crockford does opinionated wrong. It's fine to be opinionated, but it's not fine to give absurd (often stupid) justifications for actions and beliefs that are wrong: "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/topics/1553 https://groups.yahoo.com/neo/groups/jslint_com/conversations...
    • macspoofing 13y ago
      >It's fine to be opinionated, but it's not fine to give absurd (often stupid) justifications for actions and beliefs that are wrong That's asking Crockford to not be Crockford.
• jonpaul 13y ago
  I honestly thought TOML (https://github.com/mojombo/toml https://github.com/mojombo/toml - created by founder of Github) was a good configuration format. But unfortunately, I'm not sure that Tom has been a good steward of it and most of the interest in the early dies died off because Github issues would go unanswered or unresolved for months.
  • stock_toaster 13y ago
    Same here. I have been keeping an eye on libucl[1] lately. The nginx-like config style seems very nice. I ran across it when looking at FreeBSD's pkg-ng (it uses it). I haven't seen any libs for it in any other languages yet though, so maybe it will end up being just another 'also ran'. [1]: https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl
• meritt 13y ago
  Where do I go to vote against this? Just write a script that just converts your invalid JSON into real JSON.
• naughtysriram 13y ago
  Terrible styling for the website. My eyes started to irritate while I was reading half way through.
• shirro 13y ago
  This brings barely anything useful to JSON and adds processing overhead. Almost all json is produced and consumed but software not people. Adding trailing commas or single quotes or optional quotes is a waste IMO and adds needless complexity for very little gain. Now if they were introducing some useful new types that would be a different matter.
  • callum85 13y ago
    I often use a JSON file containing dummy content when I'm working on a web app, and I manually edit the JSON a lot during development (then, when I've settled on a structure, use the static JSON file as the design for a real API endpoint). Comments and ES5 niceties would be useful for those situations, at least. You could even assign JSON5 to window.JSON in your dev environment only, and still get the performance of real JSON in production.
    • typicalbender 13y ago
      One other thing to consider is that JSON was meant as a replacement to XML to be more concise and easier to use as well as being generally smaller in payload size. Adding comments, while good for people, is not really what it was developed for. It's really for machine to machine communication and adding human readable stuff like comments and dangling commas muddies the protocol.
      • callum85 13y ago
        Your comment doesn't seem to address what I was saying. I just described a situation where you might use JSON5 in development (so you can put comments etc in your dummy data) and JSON in production (so you get native performance).
        • cturner 13y ago
          Here's how I've solved the use-case you talk about. I built my development files in my own format, and then transformed them to JSON for the wire. In my mind, the hassle this involves is a down-payment I gladly make in order to be able to work with sharp tools. 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.
• Thiz 13y ago
  This is what json should have been from day one. 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.
  • TheZenPsycho 13y ago
    the reason the quotes were added to keys is not alphanumeric compliance. It's avoiding javascript reserved words like "do" and "class".
• adrianpike 13y ago
  On the plus side, since it's all optional, we can all start claiming compliance immediately.
• Encosia 13y ago
  A successor, revision, or update to JSON must address Dates to have any hope of displacing JSON 1.0.
  • captainmuon 13y ago
    This is not meant to displace plain JSON! JSON5.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), or whatever the syntax would be and "date": "2010-03-23T23:57Z" ? The irony is that JSON5 without dates is more compatible with JSON, than any JSON implementation with dates. (JSON5.stringify(JSON5.parse(...)) always produces pure JSON without loosing information. I don't know how you would convert a date literal into regular json other than turning it into a string, on the other hand.)
• hyp0 13y ago
  These are all good ideas, but will NOT be adopted. 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.
  • captainmuon 13y ago
    This is not meant to be adopted, as in, replacing JSON everywhere. 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)) This will also remove comments of course, if you are concerned about them eating bandwidth.
• bsimpson 13y ago
  Yes, please.
• quux 13y ago
  The only thing JSON needs is a standard date type. All these JSON5 additions are a waste and in some cases harmful. Example: Comments were taken out of JSON because some parsers started using them to store processing instructions.
• AndyKelley 13y ago
  Most of this is already implemented in my C library called "liblaxjson" [1] 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. [1]: https://github.com/andrewrk/liblaxjson https://github.com/andrewrk/liblaxjson
• aaronsnoswell 13y ago
  The one best thing about this - comments.
• haxander 13y ago
  Want comments and all kinds of other goodies in your config? Why not make a config.js that offers full configuration language flexibility?
  • captainmuon 13y ago
    That is what this is.
• kgabis 13y ago
  This adds too little and too late (not that much should be added to JSON). And parsing some of these features would be a headache and a possible source of bugs (I maintain a JSON parser in C[0]). Keeping it simple is much more important than adding new features. [0] https://github.com/kgabis/parson https://github.com/kgabis/parson
• fisherprice 13y ago
  JSON is perfect as it is, leave it like it is.
• nardi 13y ago
  I love how this proposal "fixes" a bunch of non-issues, while making it much more difficult to write a JSON parser, and then doesn't address the only real problem with JSON: That it doesn't have a date/time type.
  • rwmj 13y ago
    More fundamentally: JSON doesn't have a well-defined integer type. A JSON parser that accepted just 0 and 1 as the only integers would be conforming. And this causes real bugs in real programs: https://lists.gnu.org/archive/html/qemu-devel/2011-05/threads.html#02162 https://lists.gnu.org/archive/html/qemu-devel/2011-05/thread...
    • TazeTSchnitzel 13y ago
      JSON also has no floating-point type. It has a generic number type, and it is up to the parsing application to decide how to handle it. You have complete freedom; There is nothing to stop you treating it like an integer, float, decimal, or bignum.
    • haberman 13y ago
      What would you prefer JSON had done? 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.
      • rwmj 13y ago
        Provided a rich range of integer types, with specifications in the standard. Leaving it unspecified is really the worst choice if you trying to interoperate with real applications and libraries. Supporting "what they can" is great for crappy implementations, and terrible if you're trying to consume this stuff and get work done.
• berdario 13y ago
  Almost all of the issues solved by JSON5, are also solved by EDN: https://github.com/edn-format/edn 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?
  • captainmuon 13y ago
    I can only speak for myself, but I don't want something incompatible with JSON, or completely different. 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.
• angelortega 13y ago
  Commas and colons are unnecessary clutter in JSON, that's what they should change, not adding more complexity in exchange for nothing (dangling commas at the end? please). Quotes inside keys and values should also be optional unless they contain spaces. JSON should be simplified (if any), not made it more complicated.
• jokoon 13y ago
  what about a open binary format ? I don't mean bson.
• rbobby 13y ago
  Dates... where are the dates!
• DrBazza 13y ago
  Obligatory xkcd - https://xkcd.com/927/ https://xkcd.com/927/
• kirkbackus 13y ago
  This is pretty unnecessary. If you need all these things, just use XML.
• northernman 13y ago
  I really hope this idea dies quickly. 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.
• stevoski 13y ago
  We should add namespaces to JSON. And schemas. And schema validation. And stylesheet transformations. Yes, that would all be good... 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...)
  • thousande 13y ago
    we should also have JSON comments
    • alanh 13y ago
      I have no idea why you said this in reply to a sarcastic post, because - 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
  • oever 13y ago
    How could you forget processing instructions and stylesheets?
  • damagednoob 13y ago
    Sarcasm aside, schemas have been implemented for JSON: http://json-schema.org/ http://json-schema.org/
  • coldtea 13y ago
    Sarcasm yes, but mostly a real life exhibit of the slippery slope fallacy. Sure, if we add comments to JSON the next thing it would be transormed into XML, and AJAX would be like SOAP.
  • SimHacker 13y ago
    We should also add an extension to XML that lets you omit the opening tag. </sarcasm>
• MilnerRoute 13y ago
  How hard would it be to just parse JSON5 into JSON? (Strip out the comments, add quotes around keys, eliminate trailing commas from objects and arrays...) Once that's in place, then JSON5 would instantly become much more viable...
• jrochkind1 13y ago
  For what really happens when you add lots of convenience features to something like json -- it's not XML, it's YAML. 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.
• thatthatis 13y ago
  "[objects, arrays, ] can have trailing commas." That's all I needed to hear, I'm on board.
• 005-18 13y ago
  Hexadecimal numbers and object keys without quotes would be useful to me. The rest of it ... meh.
• hydrogen18 13y ago
  I'll propose this: websites should be readable.
• Silhouette 13y ago
  This is a terrible idea. 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.
• Mouq 13y ago
  I agree that JSON5 misses much of the spirit of JSON's simplicity, but I build a Perl 6 JSON5 parser for fun anyway, if anyone is interested: https://github.com/Mouq/json5 https://github.com/Mouq/json5 The actual grammar is here: https://github.com/Mouq/json5/blob/master/lib/JSON5/Tiny/Grammar.pm6 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)
• Raticide 13y ago
  OMFG comments are allowed! Was it so hard to allow those in the first spec?
  • jfischer 13y ago
    I think comments are really a bad idea. If you want comments, either make them explicit properties in your data structures or use something else like YAML or XML. JSON is the most practical language out there for inter-machine and inter-program data representation. 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.