It's very common to have DOM objects that need to act "arraylike". What this means is that properties whose names are integers smaller than UINT32_MAX-1 are "magic": they can appear and disappear based on various underlying changes. Such objects can't have new properties with numeric names be defined on them via user script, and a few other oddities. At the same time, properties whose names are strings just behave normally: can be set on the object itself, get looked up on the proto chain, and so forth. In fact, the behavior is very similar to the behavior of Array objects in JS. In the past we implemented such objects using resolve hooks, but that meant that indexed properties would not go away correctly. So once we had proxies we switched to using proxies, which works great for the indexed properties but slows down the non-indexed ones; we hacked things to work OK by manually checking proto shapes and caching some things in the object. Now we're ending up with objects for which the indexed case is an edge case and the named case is very performance sensitive, and which furthermore have a _lot_ (230 or so) properies on the prototype: just dealing with the caching there is likely to be slow or expensive in terms of memory or both... For now we're probably going to take the perf hit, but it would be _really_ nice if there were a way to just make this work well somehow. Waldo says that doing something that acts as a proxy for indexed props but a normal object for named ones should be doable, and I think it would do exactly what we want here.