JSON: A Web Dev's-eye View | Forte Group

JSON: a Web Dev's-eye view

JSON appeared from nowhere and it was a salvation. JSON was not a standard, neither was it designed by a committee. In fact, it was never designed at all. It just appeared one day as a logical and totally expected result of advances in web development. The truth was, of course, that JSON was not accidental, and its popularity should be credited to the hard work of one very dedicated person. Compared to previous standards such as XML and others, it was simple and elegant.

Since then, JSON took the web by storm. It got standardized as RFC 4627 and RFC 7159. The most modern web applications now use JSON as a communication format. Although very popular, JSON definitely has some shortcomings. Some of those shortcomings are critical to specific areas.

Aiming towards radical simplicity and reducing the amount of data types to numbers, strings, booleans, arrays, and objects, many practical use cases were not covered. For example, JSON lacks specific data types for dates and times. Usually, dates and times are represented as a string in ISO 8601 format (ex. 2016-01-13T19:11:46+03:00), which definitely works, yet creates very unpleasant problems when converting and binding JSON back to programming languages structures and objects.

“created”: “2016-01-13T19:11:46+03:00”

Another problem source in JSON is its inability to describe an object while maintaining the object type/class info in JSON document. The number of data types describable in JSON is strictly limited to six built-in types. You cannot express anything more complex than that. That may pose serious problems when using JSON as a serialization format. Try to describe something as simple as a decimal or collection (try set or queue), and you will soon find that there is no JSON description that is compatible between implementations and that allows serialization/deserialization without losing data.

<code><span style="font-weight: regular; font-family: Poppins;" data-mce-style="font-weight: regular; font-family: Poppins;"><pre>{“price”: “66.66”}</pre></span></code>

Another shortcoming of JSON is its inability to serialize circular references. That may be a serious problem when serializing (very common when trying to serialize DOM or database entities). There is a couple of standard and nonstandard ways to overcome this. Grails serialization of circular references is an example of a nonstandard, ad-hoc approach. While serializing an entity to JSON, Grails marshallers keep a stack of all previously seen objects and wherever it detects a cycle in the dependency graph, a path-like relative reference will be used. It’s worth noting, though, that it is up to client code to parse such kinds of JSON and resolve references.

"class": "domain.Blogpost",
"user": [
"class": "domain.User",
"blogposts": [
"_ref": "..",
"class": "domain. Blogpost"
"comments": [
"class": "domain.Comment",
"id": 13336,
"_ref": "../..",
"class": "domain.Blogpost"

More standards-compliant (and also more intrusive) way to specify circular dependencies is JSON Reference standard (RFC). It allows referencing any property in a current or external JSON file. Unfortunately, the “standard” seems to be non-descriptive and nominative and does not contain any description of how object references should be constructed in a document. JSON references are quite popular, they are used extensively in JSON Schema definitions.

"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {
"address": {}
"type": "object",
"properties": {
"billing_address": { "$ref": "#/definitions/address" },
"shipping_address": { "$ref": "#/definitions/address" }

JSON also carries limitations of its parent language. You cannot really use Unicode to a full extent in JavaScript, you can only use what is called the basic multilingual plane (BMP). Such characters as emoji and extended mathematical symbols are out of BMP and cannot be used in JavaScript without escaping and hence always need to be specially encoded in JSON. That cripples uniformity of syntax and carries an additional burden for parsers.

Finally, JSON does not allow to use comments. As more tools have chosen JSON for storing configuration (say, npm uses package.json for storing project information), inability to comment your configuration is a major source of frustration.

Of course, one may argue that JSON is an acceptable format for specific needs. And JSON is really excellent in specific areas. Working with JSON web API is a true pleasure. However, you may consider other formats for serialization and storing configurations. One of the wide-spread formats for such purposes is YAML.

YAML not only aims to provide an always-readable representation of data, but it also has some advanced features that JSON lacks. For example, you can both serialize custom classes (the class name is preserved in YAML) and use content-references to describe data with circular dependencies. And of course, you can use comments in YAML.

<code> - &id002 !ruby/object:Person # yaml can describe specific class
name: Joe Smith
spouse: &id003 !ruby/object:Person
name: Ann Smith
# This is circular reference. They can be expressed in yaml.
spouse: *id002

Surely, the use of YAML should be justified as the format is not simple. Some users may not like how serialized data looks, its performance may be unacceptable for the user’s needs and ability to describe “any” class and ability to instantiate any class described in user-supplied YAML may pose a security risk (just remember that hilarious vulnerability in Rails). However, it is clear that YAML not only has fancy syntax but also a couple of highly needed features.

Andrew Gurinovich

by Andrew Gurinovich

Andrew is a software engineer with broad frontend and backend experience.

Start a Project

Start here to accelerate or advance your business

Plan a Project

Answer a few questions and find the right software delivery model for you