Hacker News Reader

Comment by evmar | Hacker News Reader

I think WASM is great, but it also is not a panacea.

You can see this demonstrated in their demo where highlighting the text garbles it -- because they render without using browser technologies, they miss out on browser implementations of things like highlighting. (Another example: their "get in touch" link in the demo is not a real link and can't be right-clicked, indexed by search engines, etc.)

In the specific context of a PDF that is perhaps inevitable (PDFs likely need special text layout) but in the larger context of random native apps, you only get a "free" port to the web by cutting out web features.

With that said, let me emphasize again that in the right domains this is all super awesome. It just doesn't solve the problem of making good webapps.

View on HN

PSPDFKit CTO here.

I 100% agree with you that our current implementation misses out on lots of browser-provided native behaviour. But this is not an inherent limitation of WebAssembly.

PSPDFKit started as an iOS-only framework. We then abstracted out a shared C++ layer which has tight hooks with the platform (Android or iOS).

PSPDFKit for Web is still a young product, one feature we have on our long-term roadmap is to have the browser handle rendering text natively. Our WebAssembly Core can "extract" WebFonts for the glyphs from the PDF and position them using HTML tags. This truly gives you the best of both worlds. PDF files need to be rendered absolutely accurately, so for now we went with rendering to an image.

If you're interested in our cross-platform strategy, you might be interested in https://pspdfkit.com/blog/2016/a-pragmatic-approach-to-cross...

Great work guys! Keep on releasing more interesting libs for wasm!

Your complaints have little to do with wasm; as the post says it has no direct access to the DOM.

wasm is only supposed to speed up heavy computations like those needed to decode and rasterize the PDF, modifying the page is still done through javascript.

Yup there's zero reason this couldn't just output a dom manipulation via FFI into straight JS code. It's fairly straightforward to do with wasm/asm.js.

Just curious: Has anyone does this yet? Specifically, I'm thinking of something vdom-like with the possibility of callbacks into wasm. Obviously, they would have to go some type of string marshalling and "proxied" IDs for callbacks, but the applications I'm thinking of don't require "huge" performance.

Yup, you call a c function that calls out to JS and then make whatever dom/canvas calls you want.

Do you happen to have a link to an implementation for wasm?

Not publicly, the emscripten docs covers it in pretty good detail:

http://kripken.github.io/emscripten-site/docs/porting/connec...

i don't understand the point you're trying to make.

i can't comment on the highlight-garble problem you mention, because i don't see it (firefox x64 for linux); however, the link "problem" has nothing to do with WASM. it's a PDF link, not an HTML link, and those have always been a completely separate concept. the same "problem" would exist however you're rendering the PDF, unless you convert it to HTML (which i don't think is the goal of pspdfkit).

What WASM also misses is good multithreading support, shared data (between threads), locking primitives, and things like memory fence instructions.

Well, that is, in a big part, true also for native desktop apps ported to the web. Nevertheless, the gain is so big it's still worth it.

Reply on news.ycombinator.com