Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ES5 shim for proxies #8
I've been exploring various concepts for trying to bring ES6 features to ES5 supporting engines (without source rewriting). One example is of bringing
In fact, it's trivial to shim most of the features of proxies as this very repo shows. The direct proxy concept is implemented on top of the original proxy api almost entirely (from a user standpoint) due to the fact that almost all of the operations in JS are already only accessible via function calls, and some of the ones that aren't still defer to JS code anyway (toString, valueOf). The only ones that are non-obvious to shim are the literal operations: get, set, delete, has, in. Using ES5 and premeditation, you can even handle get and set for existing properties.
I don't have answers to this but I thought it could potentially be in the spirit of this specific project.
I have had similar thoughts. In particular, your point about trapping the existing properties of an object on an ES5 engine without any support for proxies.
The reason I haven't pursued this is that the emulation would be woefully incomplete: you'd be able to trap property "get", "set" and function "apply" of existing properties but that's pretty much it (apart from all the Object.* methods of course, but those are not the commonly used operations). If properties are added to the target object after the proxy is created, those won't get trapped. Similarly, we wouldn't be able to trap "in", "delete" and "for-in", and only unreliably trap "new". All in all, I think there would just be too many missing features to be a usable/reliable shim.
However, it's nice to know that the Reflect API (excluding Proxy and VirtualHandler) is shimmable in ES5. Most of these methods are really just a thin wrapper around things easily done in pure ES5, but some methods do offer some added benefit: