3 ms·
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 alwa
by 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 agoThere is no way of knowing someone won’t do a.foo = window.alert later though, unless it’s a frozen object
- zeven7 7y agoThat's also true of an object parsed with JSON.parse
- tracker1 7y agoJSON.parse won't parse a function call/literal. Direct injection would.
- zeven7 7y agoYou'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 agoDon't we already have that, plus a transport medium with JSON?
- SamBam 7y agoThe speed-up is at object instantiation.`a.foo = window.alert` could only be done post instantiation.