Security Demands Simplicity (was: Private Slots)

Tom Van Cutsem at
Mon Jan 21 08:23:54 PST 2013

2013/1/20 Allen Wirfs-Brock <allen at>

> I don't have a problem at all with making the proxy story more
> complicated.  Proxys are an expert feature designed for some specific use
> cases.  they are probably an attractive nuisance.  I would advise most JS
> programmer that if they are going down the road of using a Proxy, they are
> probably making a mistake.  In that light,  placing the extra complexity
> within the Proxy story seems just fine.

While in the specific case of proxies & private symbols, I think it is fine
if proxies take an extra complexity hit, I'd like to push back a little
here regarding the more general point.

People often complain that proxies are complicated. Well here's the deal:
proxies are only as complicated as the ES object model requires them to be.
The more features we add to the ES object model, the more complexity we
face in proxies. It's awkward to blame proxies for that extra complexity.
Proxies are just a (power-)tool that aim to let the ES programmer emulate
all aspects of ES objects in Javascript itself. If Javascript objects
become more complex, they obviously also become more complex to emulate.

It also gives a false sense of simplicity to think that pushing off extra
complexity into proxies actually sweeps all the complexity under the rug
for the non-expert programmers. Extra complexity in proxies also implies
extra complexity for any other kind of exotic/host object. Point-in-case:
how will host objects interact with private symbols? It isn't entirely
obvious. Does a WindowProxy forward them, or does each WindowProxy have its
own set? These issues reappear outside of Proxies proper.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list