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.
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.