4 ms·

This makes total sense, it really just means that the time it takes to compile JSON.parse on a string literal is offset by how much simpler and faster parsing a

• EGreg 7y ago
  Why isn’t the Javascript compiler storing an intermediate form after parsing the code? Then surely it would be faster to just execute the bytecode?
  • jackcodes 7y ago
    It is, I believe. The article seems to be saying you can get to that intermediate form more quickly by parsing the object from a string than you can parsing it as a POJO.
• SamBam 7y ago
  It seems that you could define a subset of JS Objects that are exactly those you could define with JSON (no functions, no recursion), and the browser could always read these more efficiently. With modern tooling, these could probably even be automatically be discovered at compile time, and all your `const a = {b: "c"}` objects could be changed into `const a = SimpleObject({b: "c"})`. Without that, you could probably use Typescript today to spit out JSON whenever the compiler saw that it was more efficient.
  • jacobr 7y ago
    There is no way of knowing someone won’t do a.foo = window.alert later though, unless it’s a frozen object
    • zeven7 7y ago
      That's also true of an object parsed with JSON.parse
      • tracker1 7y ago
        JSON.parse won't parse a function call/literal. Direct injection would.
        • zeven7 7y ago
          You're right about that, but I don't think you're following the argument. The argument was that there could be a `SimpleObject` that's limited and parses quicker. A `SimpleObject` wouldn't parse a function call, just like JSON.parse. As OP said, "subset of JS Objects". This subset of JS objects wouldn't support function calls.
          • tracker1 7y ago
            Don't we already have that, plus a transport medium with JSON?
    • SamBam 7y ago
      The speed-up is at object instantiation.`a.foo = window.alert` could only be done post instantiation.