4

According to the 2019 Chrome Dev Summit video, "Faster apps with JSON.parse", using JSON.parse with a string literal instead of declaring the json through an object literal results in a noticeable speed improvement. The google JSON.parse benchmarks show a major difference between the two.

//JS object literal
const data = { foo: 42, bar: 1337 }; // 

//JSON.parse 20%+ faster
const data = JSON.parse('{"foo":42,"bar":1337}'); //

When declaring json in javascript, are there any downsides of using JSON.parse instead an object literal? Should json always be declared using the JSON.parse?

Eugene
  • 10,957
  • 20
  • 69
  • 97
  • 4
    For any given snippet of code, performance rarely matters; for a maintainable codebase, readability matters far more. The moderate confusion (to other readers of your code) and marginal extra complication of `JSON.parse` probably isn't worth it in most cases. – CertainPerformance Dec 02 '19 at 01:44
  • 1
    You cannot store keys which are functions and `undefined` values in a JSON format – adiga Dec 02 '19 at 02:23

2 Answers2

7

There's no downside, JSON.parse returns an object just like the object literal gives you.

As for when to object literal or not read below.

As long as the JSON string is only evaluated once, the JSON.parse approach is much faster compared to the JavaScript object literal, especially for cold loads. A good rule of thumb is to apply this technique for objects of 10 kB or larger — but as always with performance advice, measure the actual impact before making any changes.

Source: https://v8.dev/blog/cost-of-javascript-2019

qkombur
  • 111
  • 4
  • 2
    The downside is readability, which is why the video also explains that it's good to use this while packaging... not literally in your code. – Brad Dec 02 '19 at 01:56
3

MUST READ!!

You said JSON.parse is faster, but this is the worst choice if your objects size are small.

/* JSON.parse */
start = new Date();

for(i=0; i<1000000; i++){ //create from JSON
const miniObjectFromJson = JSON.parse('{"foo":42,"bar":1337}');
}
end = new Date()
timeGap = end - start; //457

/* JS object literal */
start = new Date()

for(i=0; i<1000000; i++){ //create from JS Object Literal
const miniObjectFromLiteral = { foo: 42, bar: 1337 };
}
end = new Date()
timeGap = end - start; //9

There is a performance difference of tens of times.

Your thoughts can only be affected by the massive size of the object case, at least 8Mb.

reference: https://www.youtube.com/watch?v=ff4fgQxPaO0

yoonsukhyun
  • 39
  • 4
  • 1
    Well, the second loop may be misleading. I’m a dumbass, but even I can write a “compiler” to determine that the operation is side-effect free, and the value isn’t used (don’t forget that the modern JS engines are astonishingly good). Arguably the same could be said as well for the first loop, but analysing globals, and native function calls isn’t as trivial (JSON global may be changed at runtime, and knowing that .parse is a side-effect free operation isn’t guaranteed). – Link0 Jul 26 '22 at 07:59
  • Most of all, we are trading off JS parse time to runtime, with expectations that the latter is more efficient at parsing json than js. Mostly, these literals are declared only once, and are not used to create unique objects countless times. – Link0 Jul 26 '22 at 08:09