41–50 of 107 posts
So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.
You've got a point. I really like TypeScript but I haven't found a nice way yet to process the results of APIs that return JSON in a type safe manner. I'm surprised there isn't a standard way to do this yet.
If we ignore syntactic aspects then the success of JSON is due to one fundamental reason. JSON relies on two structural elements [] and {}, which have very clear semantics of sets (collections) and tuples (combinations), respectively. It is simple, general, natural and consistent. In comparison, XML also provides two structural elements but they do not have such a nice duality and clarity of interpretation. Here is a…
XML without schema are a mess. XML with schema and validtion can be a joy to use compared to the untyped JSON world, but it's the lack of having to specify type which helps JSON remain popular. Given a choice between strong or weak typing and weakly typed or un-typed systems will prevail in popularity. Looking at javascript itself and the type coercion rules it is easy to dismiss it as unworkable mess which leads to…
-- object or object
-- NOT SUPPORTED
Me
My friend
The success of JSON is due to one thing: Browser support. As soon as it's use on a server, or a mobile device, or practically anywhere else almost all the benefits of JSON go away. Can you inspect the payload easily? Well, yeah, if you unwrap the bytes into a string or open up Wireshark. But on any moderately optimized system, the JSON is going to be gzip encoded and whitespace compressed, making in quite unpleasant…
Why are you using wireshark to inspect json payloads? Your other complaints stem from poor system design and lack of shared data contracts. They could be complaints about any data format.
I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML and it’s often quite terrible. We write a lot of C# but one of our tools is an old adobe lifecycle server, and .Net XML isn’t the same as Adobe XML. I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break…
> Working with JSON never takes longer than it should. This is the key point right here. JSON is a big reason I love groovy so much. No matter what json you have in groovy, you are a couple lines of code and a couple closures away from doing anything. I always use json string payloads on HTTP aswell. It vastly simplifies rest service development. Another thing I love about json is using it with cassandra. So easy to…
JSON is one of the best things to ever come out of the CS disciplines. It is one of the most perfect technologies I deal with.
If we ignore syntactic aspects then the success of JSON is due to one fundamental reason. JSON relies on two structural elements [] and {}, which have very clear semantics of sets (collections) and tuples (combinations), respectively. It is simple, general, natural and consistent. In comparison, XML also provides two structural elements but they do not have such a nice duality and clarity of interpretation. Here is a…
Yes but in XML we view things as trees, not sets, tuples, or the likes. If you consider stuff as trees, there is not anti-pattern and the example is not wrong, it is correct. It is easy. Maybe we can be a little bit dissatisfied with the choice of attributes vs elements. Of course JSON and its small spec is easier than XML and its bunch of complex recommendations.
JSON is one of the best things to ever come out of the CS disciplines. It is one of the most perfect technologies I deal with.
I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML and it’s often quite terrible. We write a lot of C# but one of our tools is an old adobe lifecycle server, and .Net XML isn’t the same as Adobe XML. I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break…
Trailing commas, comments (in large multiline dictionaries) and proper integers are some features I can think of. Small things like those can make a big difference in ease of use for many practical cases.
Earlier quoted context omitted.
XML without schema are a mess. XML with schema and validtion can be a joy to use compared to the untyped JSON world, but it's the lack of having to specify type which helps JSON remain popular. Given a choice between strong or weak typing and weakly typed or un-typed systems will prevail in popularity. Looking at javascript itself and the type coercion rules it is easy to dismiss it as unworkable mess which leads to…
Typing (enforcing constraints) is an important aspect. But even without typing XML has one fundamental flaw. You are not able to (correctly) represent tuples with attributes which are sets. In XML, tuple attributes are properties, for example: -- object or object Now let us assume that I want to have a list of authors as a property: -- NOT SUPPORTED Therefore, we use a workaround (a crime actually): Me My friend Now…
...
...