We pretty seriously looked at PPAPI back when Adobe announced effective end of life for NPAPI Flash on Linux. If PPAPI were not as tied to Chrome's internals a

We pretty seriously looked at PPAPI back when Adobe announced effective end of life for NPAPI Flash on Linux. If PPAPI were not as tied to Chrome's internals as it is, we might in fact have implemented it. As far as being invested in JS, I think it's more being invested in managed code. Our experience with NPAPI is that you end up with the unmanaged code depending on all sorts of implementation details because it can. The classic example is that all NPAPI Flash instances across have to be in a single process, because they assume they share memory. And the browser can't do anything about it, since it's not involved in the memory sharing bits in any way. Similarly, the fact that NPAPI plug-ins can do their own network access makes them hard to align with CSP and the like. Managed code can start to depend on internals in weird ways too (e.g. sync access to cross-origin window bits), but you have more chances to pull the wool over its eyes in some way (e.g. blocking cross-process proxies). Once you accept managed code, JS seems like as good a place to start as any, with at least the benefit of being there to start with. ;) There are, of course, obvious drawbacks to the all-JS approach, starting with the fairly lacking parallelism story. At least now we've grown Workers, and there's work on things like SIMD, ParallelJS, etc. Then again, the one major language addition to a browser VM recently (Dart) didn't exactly address this need either....