One of the most impactful features to be added to ECMAScript in the last few years is template literals. Creating multiline strings before the template literal syntax was done with \n escape codes.
const exampleObject = {
exampleText: 'this text appears on line 0\nthis text appears on line 1'
}
console.log(exampleObject.exampleText)
// this text appears on line 0
// this text appears on line 1
This was not only a pain to write, but also a pain to read - especially when a string contains many line breaks. But with modern JS we can do the following instead:
const exampleObject = {
exampleText: `this text appears on line 0
this text appears on line 1`
}
console.log(exampleObject.exampleText)
// this text appears on line 0
// this text appears on line 1
Note that the output of either method is the same. We can declare a JS Object that contains a string property using template strings with backticks, or we can do it with the \n escape code.
However, this flexibility is not available in JSON. We are able to write these multiline strings in JS, but in JSON the same content would cause a parsing error because JSON doesn't know how to handle strings wrapped with backticks.
But this isn't the first time there was a missing feature in JSON! It is also unable to handle a document if it contains a comment:
{
"org": "polyseam" // this comment would cause JSON.parse to fail
}
The above document is invalid JSON, despite it being perfectly valid JavaScript. Eventually, someone decided comments are so useful that a new specification and parser were created to allow us to put them in documents.
That spec is called JSONC. Note how the comment is now correctly parsed as such:
{
"org": "polyseam" // this comment is properly ignored
}
Now we know multiline strings are a missing feature of JSON that is quite valuable, and we know that we can create new specifications and parsers when it is worth while... I propose we create just one last variant of JSON:
{
"org": "polyseam",
"exampleText": `this text appears on line 0
this text appears on line 1`
}
By extending JSON in this way we have so much more flexibility in the way we read and write documents with JSON, which has impacts from the browser, to the server, to Kubernetes manifests, and beyond. We also provide a feature that 'just works' the way a JavaScript developer might imagine it should.
Do you think that JSONCT is a good idea? Does it already exist? Do you have a better name for it?
We'd love to hear from you!
Top comments (5)
JSON is a language meant to ignore new lines, as XML was before it, but lighter.
Comments are special, because you can remove them and still have the same json, that can be reduced to one line.
With your suggestion, you are going too far from the original DSL. If new lines become important, why these unnecessary brackets all over the place, shouldn't we remove them ? And BAM! you end up reinventing YAML 😅
Despite JSON being largely inspired by the object notation of JavaScript (as they say the clue is in the name) it has become a format common to a wide variety of technology stacks. The template literal syntax might not be specific to JS but I do not think it is anywhere as familiar to other languages as string, array and object delimiters. In any case you would have to get Doug Crockfords seal of approval.
The idea isn't to replace JSON with Doug's blessing, but rather provide an alternate syntax with an alternate file extension.
my-config-file.jsonctThere is precedent for this because
my-config-file-with-comments.jsoncalready exists.As authors of a JSON document we can choose whether it should be parsed as
.json,.jsonc, or.jsonctin the applications that consume the document.Just don’t. JSON was never meant to be treated like this. Comments are for expressions, not data. What shall we do next, arrays?
I thought JSON supported arrays from the outset.