3 ms·

It's not just a matter of open/closed source. Bundling in yet another C binary is only going to widen the surface area for security vulnerabilities for millions

It's not just a matter of open/closed source. Bundling in yet another C binary is only going to widen the surface area for security vulnerabilities for millions of people, and there's really not a great reason to do so anymore. PDF.js proves that it's possible to write high-performance javascript to do this stuff, without introducing any security risks and it's completely cross-platform. Computers are only going to get faster, and js compilers are only going to get better too.

jonknee 14y ago
But Chrome's works better and has been around (and useful for millions) for years. Perhaps they'll move to a JS solution in the future, but if I had to choose between the two right now I'd take the faster more complete one.
- mehrzad 14y ago
  >But Chrome's works Citation needed, pdf.js has performed better for me personally than Chrome's viewer.
- abrowne 14y ago
  pdf.js supports PDF indexes (or whatever that's called), but AFAICT Chrome's doesn't.
pifflesnort 14y ago
JS-everywhere ideologues are always trying to buy a hamburger today and pay for it tomorrow. Someday machines will be faster. Someday the implementation will on par with the alternatives. How it works today is what matters to users. Tomorrow the native stack will just make use of more hardware features, it will still be faster, and we'll still be having the same conversation that we'be been having with JS ideologues for 10 years now. "Someday ..." This is what the XML ideologues used to say too. The problem wasn't XML, it was the libraries, or the lack of dedicated XML processing hardware. Then someone realized that if you got rid of the core complexity -- XML -- you could stop layering on piles of additional complexity while trying to work around the root of the problem. Someday...