Comment by 7952 | Hacker News Reader

Comment by 7952 | Hacker News Reader

Parent Full thread

>> We often engage in debates about whether Javascript/the web stack is fast enough to use for various types of software. Performance improvements are treated as an inevitability; "if it isn't fast enough today it will be tomorrow". Similar attitudes hold for missing APIs and functionality. Most people don't seem to really question what it really means for browsers to become more and more performant and more and more complex. The answer seems to be millions of lines of very complicated and low level C++.

Ironically, not needing to run high performance native code was a part of the original appeal of web apps. Google maps worked well however old your graphics card was. Gmail was secure even when viewed on an old version of IE.

If client side rendering is too slow, then don't render on the client. Cache the rasterized pdf as tiles up in the cloud and only read the actual document if the user selects text or zoom in. That is the only way to make massive pdf's load instantly on a slow machine.

That is the only way to make massive pdf's load instantly on a slow machine.

I beg to differ. Grab an older or smaller PDF reader. One of the ones with just two features- "scroll" and "zoom"- and you will find even a terribly slow machine can keep up.

(Except when it is one of those PDFs with 30MB pictures embedded in every page)

It's the bajillion added features of dubious value, and things like using js as the backend, that has kept PDF rendering decidedly heavyweight.

When a PDF is too large for PDF.js on my little 1.0GHz laptop, I open it up in Acrobat Reader and I'm back in business.

But I want to be able to quickly view those massive PDFs, 30MB per page is not particularly large for a large graphics heavy print quality document.

PDF rendering is essentially creating a binary from a source code package. Why would you recompile every single time when the purpose of the format is to deliver an exactly consistent binary output? Arguing that the format is badly designed does not open a document any faster!

I would argue the super-high-quality image PDF meant for printing on a 1200dpi plotter is an exceptional case a netbook will never handle well, no matter the format.

Usually when the PDF is silly big, someone just didn't do a good job preparing it.

Optimising compression and caching zoom levels does make a big difference. But it is exactly what is missing in a significant number of PDF files in the wild. This is particularly common in engineering drawings/maps and they can be slow to open on any machine. The point of my original comment was that client side code sitting is isolation will always have certain limitations regardless of how it is implemented.

> If client side rendering is too slow, then don't render on the client. Cache the rasterized pdf as tiles up in the cloud and only read the actual document...

Some people are not comfortable with giving their financial/proprietary/secret information to third party's "cloud". And since they have to pay for "cloud", you end up paying for it somehow at the end. With client side code: 1) nobody knows what you are looking at, 2) and you don't rely on network connectivity much.

Some of us are very happy to be able to[1] get the actual data directly to our machine without any "cloud" blurring our view, thanks : )

[1]: I have nothing against clouds, -as long as they are not mandatory that is.

Yes I agree. A "cloud" implementation of a PDF reader would be bad in a whole different way. It is annoying to have to use the "cloud" term at all as it implies certain things beyond just being a distributed/decentralised cache of data and external processing power. Those are the things that make the cloud approach useful and its a shame some of that cannot be used in normal desktop applications.

Reply on news.ycombinator.com