Hacker News Reader

Comment by gqcwwjtg | Hacker News Reader

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 JSON object is than a js one.

View on HN

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.

There is no way of knowing someone won’t do a.foo = window.alert later though, unless it’s a frozen object

That's also true of an object parsed with JSON.parse

JSON.parse won't parse a function call/literal. Direct injection would.

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.

Don't we already have that, plus a transport medium with JSON?

The speed-up is at object instantiation.`a.foo = window.alert` could only be done post instantiation.

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?

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.

Reply on news.ycombinator.com