https://github.com/pypyjs/pypyjs/issues/145

1) "For addons only" is an important qualification. It means you don't have to worry about sandboxing at all, since addons are already all-powerful (or at least were at the time).

2) It added a _lot_ of complexity throughout the DOM. There are tons of places in the web platform that basically assume you have a "JS value" and things fall apart if that's not the case. Most simply, what happens if python code sets document.body.onclick and then JS code reads it, or vice versa? It's possible that this complexity and the resulting performance impact is worth carrying around if the use cases are compelling enough, but they just weren't.

3) The python implementation in question did not have a good solution for the problem of cross-language cycles. Those were solved for JS and C++ in Firefox by creating a cycle collector that tightly integrates with the JS GC and the refcounting system the C++ side uses. But that was only possible due to full control over the JS GC implementation (and hence the ability to change it to flag objects as "only owned by C++ stuff" and whatnot). Doing the same thing with Python would be a nontrivial undertaking, just for the C++ and Python bits. Dealing with cycles that involve all three languages would be _quite_ hard.

    <script type="text/vbscript">
       Sub link_onClick
          ' Do some processing!
       End Sub
    </script>

Closest I've come to JS client and server was with ActionScript via Flex/Flash and VB.Net on the server... having XML literals on both sides was really nice, though I prefer JS on both ends... I don't miss C# much at all.