
WebAssembly: A New Hope - steipete
https://pspdfkit.com/blog/2017/webassembly-a-new-hope/
======
flavio81
TL:DR; They have written a PS & PDF renderer that runs completely in the
client, by using web-assembly. They show the performance to be not so far off
using native code, and this allows offloading the CPU load of PDF rendering to
the client rather than the server.

Excellent !!

~~~
mpweiher
Correction: last I checked, they didn't write the PDF renderer themselves, it
is Google's PDFium[1] which was open-sourced a while ago. Before they were
using Apple's built in PDF engine, but apparently that had too many bugs for
them.

It does not do Postscript, the "PS" in PSPDFKit are the initials of the
creator, Peter Steinberger (really nice guy, by the way!). Two/three letter
prefixes are common in Objective-C as there are no namespaces (I use MPW).

[1] [https://pdfium.googlesource.com](https://pdfium.googlesource.com)

~~~
favorited
Based on Peter's blog post[0] a few years ago, I was under the impression they
wrote their own.

Maybe steipete can chime in?

[0][https://pspdfkit.com/blog/2016/a-pragmatic-approach-to-
cross...](https://pspdfkit.com/blog/2016/a-pragmatic-approach-to-cross-
platform/)

~~~
mpweiher
Hmmm...don't remember where I got that information from, so I could well be
remembering wrong.

I do see that pspdfkit folk are active in the pdfium bug tracker, for example:

[https://bugs.chromium.org/p/pdfium/issues/detail?id=641](https://bugs.chromium.org/p/pdfium/issues/detail?id=641)

That sounds like a production problem, but it could just as well be them
trying it out.

~~~
eridius
It's certainly quite plausible that they compare their behavior with other
engines, and then file bugs on those other engines if they find them.

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

~~~
MartinMond
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...](https://pspdfkit.com/blog/2016/a-pragmatic-approach-to-cross-
platform/)

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

------
throwaway95014
This is not a comment on the work done by these no doubt well-intentioned
folks. But to pull a quote from their article:

"compile our 500.000 LOC C++ core to WebAssembly and asm.js"

This is absolutely terrible for the web :-( We've escaped activex, flash, java
applets, and now we're bringing lots of legacy c++ to the web in a way that
conflicts with the underlying tenets?

~~~
ashark
I'd be more concerned if it weren't already basically impossible to figure out
WTF is going on on any "web app" using View Source.

I wish we'd all agreed to severely cripple Javascript[1] early on and instead
improved built-in form elements and stuff like frames, but we didn't so here
we are. The web's already mostly transitioned from being for people to being
for machines and the delivery thereof, so webassembly's not going to ruin
anything. It's already ruined.

[1] Say, no ability to trigger a broad set of events that would ordinarily be
user-initated, no ability to submit forms itself, no XHR or similar. Probably
some other stuff I'm not thinking of right now. So, almost but not quite
worthless. That would have been necessary if we'd wanted to keep the people
browsing in control of the Web. Instead we chased "oooh, shiny!" and took that
control away, practically speaking.

~~~
saurik
I don't see how that does anything except force logic to the server and
guarantee page-by-page update and view semantics. At least some large
percentage of the code for some of these "modern" web apps is on my computer:
that means a _lot_ ; and anything we can do to discourage code running in the
cloud with data stored in the cloud--which absolutely implies giving complex
turing complete control over local behavior and expansive state--is a
fundamental win for users of the World Wide Web.

~~~
ashark
> I don't see how that does anything except force logic to the server and
> guarantee page-by-page update and view semantics.

Which keeps the delivered document a _document_ , and not an application.

> At least some large percentage of the code for some of these "modern" web
> apps is on my computer: that means a lot; and anything we can do to
> discourage code running in the cloud with data stored in the cloud--which
> absolutely implies giving complex turing complete control over local
> behavior and expansive state--is a fundamental win for users of the World
> Wide Web.

I consider it much better that only explicitly-requested actions (clicking a
"submit" button, or a link, for example[1]) trigger submission of data and
execution on a server than to let javascript trigger the same. Control over
behavior and data is better retained, especially for lay users, if it's
impossible for an ordinary web page to send every mouse movement and keystroke
to a server—something that's in fact done, all the time. Retaining that
control is well worth pushing web "app" logic to the server.

Programs that need local execution would just have to be delivered as... a
local program, not a web page. Losing that distinction cost the average user
control and safety when they're in their browser, and fundamentally changed
what the web is. Some of us much preferred what the web used to be, not
because we hate progress, but because progress that destroys something that
was itself valuable kinda sucks. "Web apps" should have had some other
delivery channel, if they had to exist—and clearly there's a demand for better
cross-platform GUI application delivery. Making browsers serve that purpose
has made the web fat, opaque, and untrustworthy.

[1 EDIT] and in fact I'd rather restrict submission of _new_ data, that the
server didn't already have, to form elements the appearance of which cannot be
modified at all, like a "submit" button. No JS submit-form-or-add-querystring-
data-to-URL-on-link-click shenanigans. On my ideal web links would be safe to
click, always, with only form submit buttons carrying any risk at all (and
even that far less than now, if, say, JS isn't permitted to add to or modify
form data in a POSTable form, which is another restriction JS would have on my
ideal Web)

------
jules
WebAssembly might be even bigger than the web. People already use the V8 JS
engine server side, and make client side apps with Electron. WebAssembly could
become the universal cross platform low level VM.

~~~
greenhouse_gas
The question is: Why?

Multi-platform makes sense client-side, where you have to deploy to
Windows/Mac/Linux/FreeBSD/Android/iOS on x86 and ARM.

You know your server arch. You know your server OS. As long as you don't use C
or C++ (or you're carful to be multiplatform), all switching is a recompile
away.

~~~
jcelerier
> As long as you don't use C or C++ (or you're carful to be multiplatform),
> all switching is a recompile away.

why do you say "as long as you don't use C or C++" ? these two languages are
especially good when it comes to compile a single code base to multiple
platforms. Got a 150kloc C++ app that "just compiles" to windows, mac, linux,
android, iOS, under x86, x86_64, ARM, and it even worked on PPC macs last time
I tried.

~~~
greenhouse_gas
Because you have to be careful to be multiplatform. For example, your code can
break if you assume an int is 4 bytes when in your target it's 8 (hard coded
values for pointer arithmetic), or vice versa.

~~~
jcelerier
well, I and scores of other programmers must be quite lucky because I don't
ever remember having to assume or leverage the fact that int or whatever data
type was 4 or 8 bytes.

------
ChrisSD
"It's important to point out that it is designed to complement JavaScript not
replace it and that in a browser context it has no direct access to the DOM,
only via JavaScript."

That maybe true of current implementations but the design docs[0] appear to
suggest that you will be able to import platform features in WebAssembly.

[0]
[https://github.com/WebAssembly/design/blob/master/Portabilit...](https://github.com/WebAssembly/design/blob/master/Portability.md#api)

~~~
luke_wagner
Agreed, there was active discussion about this at the last WebAssembly CG
meeting even:
[https://github.com/WebAssembly/meetings/blob/master/2017/CG-...](https://github.com/WebAssembly/meetings/blob/master/2017/CG-07.md#host-
bindings)

~~~
ilaksh
The biggest issue that I see and mentioned before is that the APIs are not
versioned and instead rely on 'feature detection' which seems to be due to
poor support for/understanding of modern style versioned modules in C++.

~~~
tomjakubowski
> understanding of modern style versioned modules in C++.

Could you enlighten us about this? Is this something to do with the eternal
C++ modules proposal that never seems to make it into a standard?

The thing that comes to my mind when I hear "versioned modules" and "C++" is
the way you can use "versioned" namespace re-exports to avoid ABI breakage,
like so:

    
    
        // header for version 1 of library
        namespace mylib {
        namespace v1 {
          struct Foo {
            int num_apples;
          };
        }
        using namespace v1;
        }
        
        // header for version 2 of library
        namespace mylib {
        namespace v1 {
          class Foo {
            int num_apples;
          };
        }
        namespace v2 {
          class Foo {
            int num_apples;
            int num_bananas;
          };
        }
        using namespace v2;
        }
    

But I don't think that's what you mean.

------
LyalinDotCom
.NET team is also looking seriously in some C# love for WebAssembly eco-
system. Its not a real project here yet but we have made some progress, check
out this great interview:

.NET Rocks! #1455 - WebAssembly and Blazor with Steve Sanderson
[https://www.youtube.com/watch?v=cCdF9-q4n5k](https://www.youtube.com/watch?v=cCdF9-q4n5k)

~~~
yodon
I'm sure some here will laugh but I cannot wait for the day I'm able to ditch
JavaScript and TypeScript and just write all my in-browser code in C# via
WebAsm.

~~~
londons_explore
Downloading .NET Framework v4.0 WASM Edition... 1%... 4 GB to go.

~~~
yodon
The download for the fully functional app in the video is ~300K, of which
~100K is bootstrap.js, so no this is not a lot of webasm being talked about to
provide .NET support

~~~
tym0
From the github
([https://github.com/SteveSanderson/Blazor](https://github.com/SteveSanderson/Blazor)):

> Is this actually .NET in the browser?

> It's not the regular .NET Framework or .NET Core runtime. It's a third-party
> .NET runtime called DotNetAnywhere, which has been updated and extended in
> various ways to support being compiled to WebAssembly, to load and run .NET
> Core assemblies, and with some additional functionality such as basic
> reflection and so on.

> Can I build a real production app with this?

> No. It's incredibly incomplete. For example, many of the .NET APIs you would
> expect to be able to use are not implemented.

------
Malic
I wonder when Node.js will (if?) support WASM. Assuming it does, then this
becomes a cross platform server-side solution for PDF generation AND THAT is
something I could actually use this very day.

~~~
coldtea
There are already node/webkit based "server-side solutions for PDF generation"
like phantomjs.

And what they showcase here is a PDF document renderer, not a PDF generator.

~~~
Malic
Oops - misinterpretation of skimming the article. Damn day job getting in the
way of keeping up with HN articles! :)

------
grumblestumble
I'd be interested to know what (aside from the new wasm support) the PSPDFKit
standalone web viewer offers over PDFJS. We're currently using the latter,
which is good enough for our needs, stable and actively developed, and open
source. It does a lot of the work via Web Workers, and on desktop at least,
it's performant enough for viewing even unusually large PDFs full of raster
images.

~~~
steipete
PSPDFKit for Web is a hybrid renderer. It can render on the client or server,
depending on device capability and power. This allows you to view a 500MB+
file even on a slow connection via your smartphone, make notes that are
instantly synced to our on-premise server via
[https://pspdfkit.com/instant/](https://pspdfkit.com/instant/) and then later
you can continue to markup the file on either your desktop browser or maybe a
native iOS app such as [https://pdfviewer.io/](https://pdfviewer.io/).

We currently deliver SDKs for all major platforms with Windows coming in Q4
and they all have the same high-fidelity renderer and deliver the same result.

With pdf.js, how the output renders also depends on your browser, and it just
doesn't support some of the more complex graphics with knockout groups,
patterns and gradients.

See Mozilla's presentation where they say that full support for these is not
even planned:
[https://youtu.be/4yLzRoErOHw?t=20m27s](https://youtu.be/4yLzRoErOHw?t=20m27s)

Our customers are in Enterprise B2B space. Some might still use IE11 (which we
fully support). Some care that their PDF files do not leak and only want
streamed access. Most care about annotation syncing. Some apply watermarks on-
demand. We solve a different category of needs than the more consumer-focussed
pdf.js.

------
ledgerdev
If you were creating a new general purpose language language today would you
target WASM? And what's the latest on garbage collection for WASM?

~~~
yodon
Garbage collection is a "Post-MVP" task[0], which is presumably why the
official .NET projects haven't formally started targeting WebAsm yet.

[0]
[https://github.com/WebAssembly/design/issues/1079](https://github.com/WebAssembly/design/issues/1079)

~~~
ledgerdev
Great to know it's on the roadmap. Once a GC is in place, WASM seems like the
universal platform of the future for computing. Fast startup, efficient, and
the same everywhere. We were supposed to get a world of hundreds or thousands
of cores for each application, but reality is most everything is moving
towards small single threaded in the cloud like serverless.

------
shmerl
_> It's important to point out that it is designed to complement JavaScript
not replace it and that in a browser context it has no direct access to the
DOM, only via JavaScript._

Why so? Why can't you avoid using JavaScript?

------
amluto
I've always found PDF.js (i.e. Firefox) to be a nicer experience than Chrome's
PDFium, which makes me wonder what this adds.

------
coldtea
A big question is, can WebAssembly be used to speed up e.g. Atom and VSC
general operation?

Or is the way those are doing things mostly incompatible?

------
TekMol

        more powerful features, such as threads, are planned as well
    
    

What, no more async hell when coding for the browser?

~~~
Spivak
Weird, most people seem to prefer the async model. It makes things clunky but
it's fairly easy to reason about.

------
frik
We will quickly find out that while WebAssembly might sound like a next step
is a bad thing to happen to the web - ads will be binary blobs that consume
100% CPU and adblockers won't work and cannot be implemented without wasting
even more CPU. Beside that the web will get more and more closed down - sound
like something that Bill Gates had originally in mind in 1994/95 with pay-per-
view Win32 based TheMicrosoftNetwork that never took off, because of the free
WWW with ads skyrocketed.

Edit: Re "Anything wasm can do, JavaScript can do." ASM.js was one thing and
ok, wasm is the real concern. What about the "binary blobs" do you not
understand. The usual downvoters who have vast interest in succeeding of this
questionable tech.

~~~
throwaway95014
Yes. And why? So some bro could be a "founder" of a project to get a
promotion. Fly around on expenses holding meetings and act all important. I've
been in the room. The pseudo-PC bro-ness is nauseating.

~~~
sctb
How did we get here? Please don't post off-topic inflammation.

