If you click through, you can find the original Twitter conversation that prompted this posting [1]. In that conversation, an interesting point about "optimizing away" string representations was brought up: [2, 3]
> Interesting! How is this better or worse than the usual trick of `JSON.parse(JSON.stringify(obj))` ?
(...)
My idea was that the browser could detect that the string is immediately parsed anyway and just interpret the two function calls as "deep copy this object for me".
I had thought about somethig like this in the context of innerHTML a whole ago. Generally, there are a lot of places in the DOM where can modify an object not by setting properties, but by getting a string representation of the object, modifying that string, then feeding the new string back to the browser for reparsing. Examples are document.cookie, css properties and of course innerHTML.
In those cases, an optimisation like the above sounds like it could actually make sense.
E.g., if someone abused innerHTML like this:
for (let i = 0; i < data.length; i++) {
myList.innerHTML = myList.innerHTML + "<li>" + data[i] + "</li>";
doSomethingWith(myList.lastChild);
}
a naive implementation would have to serialize, parse and recreate the whole object tree for each iteration of the list. However you could probably optimize it by having innerHTML return some special object that only "looks" like a string but somehow keeps track of its mutations internally. When the object is fed back to innerHTML later, the browser could use the internal properties to mutate the DOM instead of recreating it.
I'm curious, does anyone know if optimisations like this are actually used?
If you click through, you can find the original Twitter conversation that prompted this posting [1]. In that conversation, an interesting point about "optimizing away" string representations was brought up: [2, 3]
> Interesting! How is this better or worse than the usual trick of `JSON.parse(JSON.stringify(obj))` ?
(...)
My idea was that the browser could detect that the string is immediately parsed anyway and just interpret the two function calls as "deep copy this object for me".
I had thought about somethig like this in the context of innerHTML a whole ago. Generally, there are a lot of places in the DOM where can modify an object not by setting properties, but by getting a string representation of the object, modifying that string, then feeding the new string back to the browser for reparsing. Examples are document.cookie, css properties and of course innerHTML.
In those cases, an optimisation like the above sounds like it could actually make sense.
E.g., if someone abused innerHTML like this:
a naive implementation would have to serialize, parse and recreate the whole object tree for each iteration of the list. However you could probably optimize it by having innerHTML return some special object that only "looks" like a string but somehow keeps track of its mutations internally. When the object is fed back to innerHTML later, the browser could use the internal properties to mutate the DOM instead of recreating it.I'm curious, does anyone know if optimisations like this are actually used?
[1] https://twitter.com/DasSurma/status/955484341358022657
[2] https://twitter.com/sergiomdgomes/status/955484966313488384
[3] https://twitter.com/moritz_kn/status/956444334970343424