> I have no idea why Mozilla was so resistant to pnacl

Pepper for one is a pretty good reason IMHO

Why? It seems like a good replacement for npapi.

Brendan Eich discussed about this few months ago at: https://news.ycombinator.com/item?id=4630334

Anyway, he said that the problem with Pepper is that its API is gigantic and its only spec is the implementation in Chromium. Other browsers could port the API but it come at very high cost due to WebKit-specific glue code.

The "problem" with pnacl is that it means the end of Javascript's death grip on the browser, which Brendan Eich is interested in extending for obvious reasons

I think you're overstating it. It more likely means the beginning of Google's death grip on the browser.

How does Google have a death grip on the browser?

They don't yet. I'm saying pnacl is more likely to result in Google getting a death grip on the browser than ending Javascript's dominance.

Oooooh, the ominous "yet". Scary.

To be clear, there are two things that have historically been called "pepper". The first was a basically a better version of NPAPI, with the limited scope that implies. That was replaced by something that's basically a Google-proprietary replacement for the entire web stack, with both the scope and the problems that implies.

> Among other things, JavaScript is necessarily single threaded...

That isn't quite true anymore either, because of Web Workers and ParallelArray.

https://bugzilla.mozilla.org/showdependencytree.cgi?id=80186...

https://github.com/RiverTrail/RiverTrail/wiki/ParallelArray

"That isn't quite true anymore either, because of Web Workers and ParallelArray."

Quote from yesterday's discussion:

https://news.ycombinator.com/item?id=5451658

"WebWorkers are not really a multithread model. Game engines could be written to leverage message passing based isolates, but in some cases, but doing it in an optimal form isn't exactly developer friendly, it's one of pains of developing the PS3 SPEs is that they didn't share system memory and you had to DMA stuff around."

ParallelArray allows data to be shared without copies.

Isn't that browsers only? And not really suited (or horribly suited) for realtime work like video games.

WebWorker with native threads is available on Node.js: https://github.com/audreyt/node-webworker-threads

For an alternate model of parallel computing, WebCL (OpenCL) has been ported to Node.js as well: https://github.com/fifield/node-webcl

DRY? I think NaCl will require Mozilla to implement another VM or parser, and do same optimization it already does on JS. So why should they repeat themselves?

Because designing web standards around laziness is not a great idea and leads to things like.... JavaScript.

Isn't V8 multi-threaded? You might be right about the other JS engines, though.

It may run on multiple threads but I don't think it exposes threading to the runtime. Ecmascript is certainly single threaded and async by design, so v8 would be straying far from the spec.

I'd love to be proven wrong.

Wait, what are Web-workers then?

for opening up a new separate thread, that you can only communicate through message passing. It's not part of the core language but the browser library hence why you can't use them in Node.

They're also more directly comparable to processes than threads, as they do not share memory (though there are a couple of proposals to allow them to).

Apparently ParallelArray allows shared memory.

yeah but that's not approved yet and from what I can tell ParallelArray is higher level then Workers and doesn't really expose that sort of thing.