4 ms·
This essentially amounts to "JSON is slower and more CPU intensive than it absolutely needs to be." I can live with that. Any solution that people come up with
by jfoster 13y ago
This essentially amounts to "JSON is slower and more CPU intensive than it absolutely needs to be."
I can live with that. Any solution that people come up with, there will be folks who can point out some sort of flaw in it. Sometimes the flaws are worth paying some attention to, when fixing them might lead to some tangible benefits. It's difficult to imagine a slightly less CPU intensive replacement for JSON bringing any tangible benefits with it, though.
- strmpnk 13y agoThe note on numbers can be specifically problematic since the format does not specifically restrict numbers to be represented by doubles but many clients will assume so, creating some hard to find bugs (it's bitten me many times). The others seem more minor compared to its lack of things like maps that support non-string keys.
- Turing_Machine 13y agoHmm.... isn't JSON required to be valid Javascript? Javascript assumes all numbers are double-precision FP, yes?
- draegtun 13y ago> isn't JSON required to be valid Javascript? Not necessarily. See JSON: The JavaScript subset that isn't - http://timelessrepo.com/json-isnt-a-javascript-subset http://timelessrepo.com/json-isnt-a-javascript-subset
- icebraining 13y agoThe lack of hypertext is a valid complaint, in my opinion, for a language designed in the web age. Sure, you can build a format on top of JSON that treats certain values as URIs, but that kind of thing should be built-in.
- craigching 13y agoJust curious, but how do you envision hyperlinks working in JSON? And what's a use case for this? Generally I imagine putting "next" sorts of links in a JSON document is the way I resolve this, but I could imagine wanting to put a link directly on the text that would take you to more detail about the text. Is that the use-case? I guess I haven't needed that or I haven't known I've needed it because it isn't there :p
- icebraining 13y agoI'd copy it from the RDF world: { 'author': { 'name': 'Jack', 'homepage': <http://jackshome.com/>, } } As for the use case, the easiest to conceive is JSON-reading search engines. Think about what we could do with all that structured data ;)
- Tobani 13y agoI don't quite follow the whole hypertext problem. I mean URIs can be encoded as strings, there's no problem there. HTML doesn't handle URIs any differently. They're just string attributes on elements(generally). Is the problem that there aren't clients that can generally consume the JSON and find the hyperlinks? Is the idea that the JSON should be able to be rendered as a site kind of like the whole xml/xslt idea? I guess I just don't get what the problem is here? What would built-in uri's look like?
- icebraining 13y agoHTML doesn't handle URIs any differently. They're just string attributes on elements(generally). Sure it does, when it defines the semantics of the elements. HTML says "the 'href' attribute of the 'a' element is the URI of a linked resource". There's no special syntax, because it doesn't need to have; they're identified by their elements. But on a more general format that doesn't define particular semantics to nodes, you have syntax that identifies URLs. For example, in Turtle - which is a format that I quite like - you encode strings using double quotes around the value, but URIs are encoded using angle brackets. Example: dc:title "RDF/XML Syntax Specification (Revised)" ; ex:editor [ ex:fullname "Dave Beckett"; ex:homePage <http://purl.org/net/dajobe/> ] . The advantage is that smart clients can parse that information and crawl the documents, generating useful data even if they don't necessarily understand this particular format. Think search engines, for example - they might not understand that <span id="author"> identifies the author's name, but they can still derive useful information for the web of pages that they crawl.