<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>Klathmon</author><text>Because JSON.parse blocks the thread it&amp;#x27;s in, and JS is single threaded [1].&lt;p&gt;So even if you put it behind a promise, when that promise actually runs, it will block the thread.&lt;p&gt;In essence, using promises (or callbacks or timeouts or anything else like that) allows you to delay the thread-blocking, but once the code hits `JSON.parse`, no other javascript will run until it completes. And since no other javascript will run, the UI is entirely unresponsive during that time as well.&lt;p&gt;[1] Technically there are web-workers, and I looked into them to try and solve this problem. Unfortunately any complex-objects that get sent to or from a worker need to be serialized (no pass-by-reference is allowed except for a very small subset of &amp;quot;C style&amp;quot; arrays called TypedArrays). So while you could technically send the string to a worker and have the worker call `JSON.parse` on it to get an object, when you go to pass that object back the javascript engine will need to do an &amp;quot;implicit&amp;quot; `JSON.stringify` in the worker, then a `JSON.parse` in the main thread. Making it entirely useless for my usecase.&lt;p&gt;But continuing with that same thought process, I very nearly went for an architecture that used a web-worker, did the `JSON.parse` in the worker, then exposed methods that could be called from the main thread to get small amounts of data out of the worker as needed. Something like `worker.getProperty(&amp;#x27;foo.bar.baz&amp;#x27;)` which would only take the parsing hit for very small subsets of the data at a time. But ultimately the oboe.js solution was simpler and faster at runtime.</text><parent_chain><item><author>nostrebored</author><text>Why not just use promises?&lt;p&gt;side note: legit question, I don&amp;#x27;t do web&amp;#x2F;app dev</text></item><item><author>Klathmon</author><text>I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread.&lt;p&gt;I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds!&lt;p&gt;So I ended up using a library called oboe.js [1] to incrementally parse the massive JSON blobs putting liberal `setTimeout`&amp;#x27;s between each step to avoid hanging the main thread for more than about 200ms at a time.&lt;p&gt;This meant that it would often take 5x longer to fully parse the JSON blob than just using `JSON.parse`, but it was a much nicer UX as the UI would never hang or freeze during that process (at least perceptively), and the user wasn&amp;#x27;t waiting on that parsing to happen to use the app, there was still more user-input I needed from them at that time. So even though it would often take 15+ seconds to parse now, the user was often spending 30+ seconds inputting more information, and now the UI would be fluid the whole time.</text></item><item><author>Tade0</author><text>I think this fragment catches the spirit of this piece:&lt;p&gt;&lt;i&gt;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.&lt;/i&gt;&lt;p&gt;Although it may still not be worth it. At work I have this hand-rolled utility for mocking the backend using a .har file(which is a JSON). I use it to reproduce bugs found by the testers, who are kind enough to supply me both with such a file and a screencast.&lt;p&gt;On a MacBook Pro a 2.6MB .har file takes about 140ms to parse and process.</text></item></parent_chain></comment><story><title>The cost of parsing JSON</title><url>https://v8.dev/blog/cost-of-javascript-2019#json</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>RussianCow</author><text>Promises are a way to deal with async code. Parsing JSON is synchronous and CPU-bound, so promises offer no benefit. And since web pages are single-threaded[0], there isn&amp;#x27;t really any way you can parse JSON in the background and wait on the result.&lt;p&gt;[0]: There is now the Web Workers API which does allow you to run code in the background. I&amp;#x27;ve never used it, but I have heard that it has a pretty high overhead since you have to communicate with it through message passing, so it&amp;#x27;s possible you wouldn&amp;#x27;t actually gain anything by using it to parse a large JSON object.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;developer.mozilla.org&amp;#x2F;en-US&amp;#x2F;docs&amp;#x2F;Web&amp;#x2F;API&amp;#x2F;Web_Workers_API&amp;#x2F;Using_web_workers&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;developer.mozilla.org&amp;#x2F;en-US&amp;#x2F;docs&amp;#x2F;Web&amp;#x2F;API&amp;#x2F;Web_Workers...&lt;/a&gt;</text><parent_chain><item><author>nostrebored</author><text>Why not just use promises?&lt;p&gt;side note: legit question, I don&amp;#x27;t do web&amp;#x2F;app dev</text></item><item><author>Klathmon</author><text>I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread.&lt;p&gt;I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds!&lt;p&gt;So I ended up using a library called oboe.js [1] to incrementally parse the massive JSON blobs putting liberal `setTimeout`&amp;#x27;s between each step to avoid hanging the main thread for more than about 200ms at a time.&lt;p&gt;This meant that it would often take 5x longer to fully parse the JSON blob than just using `JSON.parse`, but it was a much nicer UX as the UI would never hang or freeze during that process (at least perceptively), and the user wasn&amp;#x27;t waiting on that parsing to happen to use the app, there was still more user-input I needed from them at that time. So even though it would often take 15+ seconds to parse now, the user was often spending 30+ seconds inputting more information, and now the UI would be fluid the whole time.</text></item><item><author>Tade0</author><text>I think this fragment catches the spirit of this piece:&lt;p&gt;&lt;i&gt;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.&lt;/i&gt;&lt;p&gt;Although it may still not be worth it. At work I have this hand-rolled utility for mocking the backend using a .har file(which is a JSON). I use it to reproduce bugs found by the testers, who are kind enough to supply me both with such a file and a screencast.&lt;p&gt;On a MacBook Pro a 2.6MB .har file takes about 140ms to parse and process.</text></item></parent_chain></comment><story><title>The cost of parsing JSON</title><url>https://v8.dev/blog/cost-of-javascript-2019#json</url></story>