> it's kind of sad that they felt they couldn't pick up on Gnash or LightSpark or some of the other good open-source Flash work out there
The whole point is that doing it in JS avoids the need for a native code plug-in, which cuts off an entire avenue of security problems. Same story as PDF.js.
There's a big difference between displaying a PDF file in JavaScript and compiling and displaying an active, real-time Flash game in JavaScript. A PDF file is just words and pictures on a page, same thing browsers have always done. They don't include animations, they don't accept user input, they don't connect to servers and stream files and send updates, and they definitely don't run real-time graphics code or path finding and collision detection algorithms.
The applications of Flash make it a better candidate for native code instead of the performance wreck of a from-scratch JIT-on-JIT solution. I think it's a great demo and probably a useful experiment that can improve the quality of Firefox's JavaScript compilers, but I don't think it's a very serious candidate to replace Flash Player for its most common strongholds (for instance: that simple little car demo runs at 20fps on my machine, which I built last month and has an i7 3770K). And that's really what we need right now.
The excuses to write this in JavaScript are pretty flat. You don't think they can figure out how to make an NSAPI plugin reasonably secure? You don't think they can get the code portable enough to work on multiple platforms? The biggest issue is probably mobile since many machines there use ARM, but Lightspark uses LLVM as its backend, which already supports ARM. I'm confident Mozilla's engineers can figure that out and give us a real replacement for the Flash player.
I don't mean to imply that this project isn't impressive -- it is. But I hate to see them duplicate so much effort for a solution that is, by nature, performantly disadvantaged. We need a serious challenger to Flash Player (we've had enough toys) and Mozilla is in a good position to provide that, so I hope they choose to do so.
>They don't include animations, they don't accept user input, they don't connect to servers and stream files and send updates
A PDF file is much more than just words and pictures. There are forms which accept user input, weird embedded content, and other strange things. Although I am not familiar with the spec, I have seen the features that Adobe Acrobat lets you do with PDFs and it seems pretty monstrous.
To clarify, there are several security issues that arise from all of this [0], and as others on this page have pointed out, that is a good reason to make use of the existing infrastructure around browser sandboxing.
Right, but what percentage of the esoteric features technically supported by PDFs are actually in use? With the exception of forms, the huge, overwhelming majority of PDFs never use things like embedded objects (which, funnily enough, can sometimes be Flash files). And forms are definitely doable in a JavaScript PDF reader; they are, in fact, probably easier than in a native PDF reader since you'll be able to use HTML. So in JS, they can display almost any PDF in the world with no trouble at all. How many Flash programs are more complex than that little car demo, which runs slowly on my top-of-the-line hardware?
Why are we so afraid of native code these days? Firefox already runs plugins in a sandbox, and has done so since 3.6. There is more complexity and opportunity for screwups in unmanaged code, yes, and for a PDF JavaScript is just fine, but for something that requires a powerful, fast VM capable of real-time graphics and real-time user input without lag or freezes, it is silly to write off the benefit of performant native code just because Adobe's plugins are rife with security holes, which I believe is what is happening here.
We already have a thing that's capable of real-time graphics and real-time user input, it's called a web browser. This is simply leveraging that to run a different set of input.
The whole point is that doing it in JS avoids the need for a native code plug-in, which cuts off an entire avenue of security problems. Same story as PDF.js.