11 ms·

WebAssembly: A New Hope

199 points by steipete 9y ago

jules 9y ago
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.
- jamesXswift 9y ago
  Honestly, it's going to be huge, imo. And like all good tech, can be used for good and evil :) We want the best experience for users and devs that we can deliver.
- greenhouse_gas 9y ago
  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.
  - jules 9y ago
    Using the same platform for everything has advantages, e.g. code sharing between client/desktop/mobile/server, mastering 1 standard library as opposed to several, seamless serialisation of data between platforms. From what I've gleaned from the docs so far, WebAssembly is very well designed and more pleasant to target than LLVM. Having a single compiler ensures that the code behaves the same on each platform. If you are asking why I think it may happen rather than why it would be a good idea: imagine that you are a compiler writer for language X. You can target WebAssembly and run the language not only on the web, but also cross platform on servers and desktops and potentially mobile, and you even get a cross platform standard library including networking, UI (DOM/HTML), OpenGL, and more. This will save a tremendous amount of work compared to targeting LLVM separately and implementing your own cross platform libraries (which requires expertise on each platform that the compiler writer is unlikely to have). It's like targeting the JVM but lower level (compiler writers like this) and runs seamlessly on the web like JS. Browser WebAssembly implementations will compile really fast because it has to be loaded and compiled for use on websites, making it suitable for a really fast compiler for interactive development and REPL, while it will be possible to compile to fast code via LLVM.
  - nathcd 9y ago
    But the reality of production systems is much more complex than this. Many medium- to large-production systems are written in multiple languages across large and diverse teams, have legacy components, varied open source components, and so on, all talking to each other. Sometimes this is as simple as sending messages around, but sometimes not. C is usually the lingua franca since it's the common denominator on most systems. Maybe WASM will end up in a place to better serve that role?
  - jcelerier 9y ago
    > 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 9y ago
      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 9y ago
        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.
  - shams93 9y ago
    You don't want to go bankrupt running a server side hls encoder when you can run it in the browser and simply punt the playlist chunks up to a simple s3 bucket directly from the client running ffmpeg in the browser say for a live broadcasting web app.
  - jbergens 9y ago
    You don't always know youer server arch and OS. If you sell solutions to others they may choose the server OS and you might want to support as many as possible.
- baybal2 9y ago
  >WebAssembly could become the universal cross platform low level VM. You know, people tried to do the same thing countless times already, there is Java and it tries to do exactly that. We all know where Java's promise "to run everywhere" went. There are JVMs for things beginning from microcontrollers to s390, but find one that can flawlessly run code that was compiled for a VM that is even one major releases old. Serious software in Java usually comes with something saying "version 2 of this software runs on JVM 'A' 1.4.13 with patchset 'B' 1.2, classpath 'C' 1.5, and exact VM setting from supplied jvm.conf".
  - jules 9y ago
    WebAssembly is unlikely to have this issue because it has to run on the web and browsers don't want to break backwards compatibility. Even with these issues the JVM has actually been quite successful as a language platform.
    - kbutler 9y ago
      The edge cases they cited seem to run counter to this expectation: "At this point, we want to issue a special thank you to the WebAssembly teams at Mozilla and Google, especially Alon Zakai, for being so helpful. We did run into a few edge cases but with their help we were able to still make it happen and even improved the Emscripten tool chain a bit along the way." If some percentage of realistic projects run into edge cases that are incompatible with either the spec or between browsers, it violates the whole "write once run anywhere" goal.
      - jules 9y ago
        WebAssembly is in its infancy.
        kbutler 9y ago
        > WebAssembly is in its infancy Exactly. Expectations that WebAssembly will be more cross-platform than any previous attempt at cross-platform are probably overly optimistic at this point. Though I'm hopeful, as well.
- zzbzq 9y ago
  It's not possible. As soon as WebAssembly gets as big as the web, someone will implement a browser-embedded browser in WebAssembly that runs in the browser and we will be back to square 1 in this kafkaesque nightmare we call Web.
  - chrshawkes 9y ago
    Down votes are unfair, this was quite funny.
    - btilly 9y ago
      Why would you think that it is a joke? It is true and how things have always gone! When I got into computers it would have been ridiculous to imagine carrying around a computer running a different OS in a virtual machine, within which we were running a virtual network of small virtual machines existed to run programs written in a scripting language that itself runs in a VM! Sounds crazy, right? And yet it isn't rare to find a developer on a Mac laptop running Linux in VirtualBox, inside of which they run Docker containers to run applications built on node.js. This is not done as a joke, it is done because it is a useful development environment for an application that is supposed to eventually be deployed to a cloud. Portable software has been a motivating dream of our industry since forever. It was a selling point of COBOL, Pascal, HTML, Java, Flash, JQuery, and so on and so forth. The idea of deploying a known client target to get rid of browser differences is inevitable. It is just a question of who will be the first to do one that is good and fast enough to get mindshare.
  - j45 9y ago
    Lol. Can't wait for this piece of art to arrive, plus compile JavaScript web apps could compile to binaries
  - j45 9y ago
    Lol. Can't wait for this piece of art to arrive, plus JavaScript web apps could compile to binaries
  - thousande 9y ago
    Like running the Windows version of Gimp in Wine in X Window in Chrome inside Firefox on a Mac? http://imgur.com/a/wRals http://imgur.com/a/wRals From: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
frik 9y ago
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 9y ago
  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 9y ago
    How did we get here? Please don't post off-topic inflammation.
  - mwfunk 9y ago
    No bitterness there, nope.
- greenhouse_gas 9y ago
  Anything wasm can do, JavaScript can do. And vice versa. Just wasm is faster.
  - sp332 9y ago
    I don't think that's right. For example wasm can't do DOM manipulation, although it might be added in the future. But as the article mentions, wasm will be getting even more different, as things like SIMD get added to wasm while SIMD.js has been abandoned.
flavio81 9y ago
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 !!
- jamesXswift 9y ago
  If anyone has any questions I'll try and answer if I can.
  - greenhouse_gas 9y ago
    Did you show it to Mozilla or Google? It seems that it can replace PDF.JS and whatever closed-source PDF reader chrome uses.
    - moosingin3space 9y ago
      Chrome's PDF reader is actually open-source: https://pdfium.googlesource.com/pdfium/ https://pdfium.googlesource.com/pdfium/
      - greenhouse_gas 9y ago
        Sorry. I'm out of date https://bugs.chromium.org/p/chromium/issues/detail?id=50852#c16 https://bugs.chromium.org/p/chromium/issues/detail?id=50852#...
      - mpweiher 9y ago
        And as far as I know it's the engine they're using.
- deleted 9y ago
  [deleted]
- mpweiher 9y ago
  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
throwaway95014 9y ago
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?
- jamesXswift 9y ago
  Understand the hesitancy. But we develop a very high quality engine for as many platforms as we can. I.e. we can maintain less code, keep it fast, maintain high quality and identical behaviour across platforms.
  - throwaway95014 9y ago
    I agree, it's 100% rational from your point of view, just as compiling it for the Flash VM or running as an ActiveX component would have made perfect sense for you to bring your high-quality code to more platforms. My hesitation isn't about your code. It's about what we as a community are doing to the web platform.
    - jamesXswift 9y ago
      Yeah it will be interesting. I feel like having used this now that we'd be poorer without it. But you are right. There are ethical challenges ahead.
- flavio81 9y ago
  In which way it is terrible? It is a Ps and PDF rendering engine. I don't know if you are already aware of this, but Postcript is almost a complete programming language, so writing a Ps renderer is like writing an interpreter (or compiler...) Not trivial stuff at all. Also, why do you call this "legacy C++ code"?
  - throwaway95014 9y ago
evmar 9y ago
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 9y ago
  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-platform/ https://pspdfkit.com/blog/2016/a-pragmatic-approach-to-cross...
  - flavio81 9y ago
    Great work guys! Keep on releasing more interesting libs for wasm!
- dvfjsdhgfv 9y ago
  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.
- 9y ago
ChrisSD 9y ago
"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/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...
- flavio81 9y ago
  Eventually it should replace Javascript. It ought to, because it defines a standard, versatile platform to execute code on the browser.
  - limeblack 9y ago
    Although you may be right I hope you are not. I like the semi open source nature and high levelness of JavaScript. It's not perfect but it beats dissembling things. Yes I know there are obfuscators.
- luke_wagner 9y ago
  Agreed, there was active discussion about this at the last WebAssembly CG meeting even: https://github.com/WebAssembly/meetings/blob/master/2017/CG-07.md#host-bindings https://github.com/WebAssembly/meetings/blob/master/2017/CG-...
  - ilaksh 9y ago
    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 9y ago
      > 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 9y ago
.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
- jamesXswift 9y ago
  Awesome!
- yodon 9y ago
  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 9y ago
    Downloading .NET Framework v4.0 WASM Edition... 1%... 4 GB to go.
    - yodon 9y ago
      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 9y ago
        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.
ledgerdev 9y ago
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?
- sondr3 9y ago
  If most of the more recent languages are anything to go by you'd target LLVM and in the future get a WASM support for free.
  - kodablah 9y ago
    As WASM gets higher level constructs like structs and GC, you might be wiser to compile to WASM (assuming the WASM-to-LLVM backend is high quality). WASM is primarily focused on being cross-platform and deterministic. I remember when Rust was being written, the devs complained about platform-specific LLVM IR they had to emit. The big question is who will make the first WASM stdlib iface so backends can implement it. Otherwise, you might leverage LLVM right now because you have libc.
- yodon 9y ago
  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 9y ago
    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.
Malic 9y ago
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.
- deleted 9y ago
  [deleted]
- jahnu 9y ago
  It already does! Try it out.
- coldtea 9y ago
  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 9y ago
    Oops - misinterpretation of skimming the article. Damn day job getting in the way of keeping up with HN articles! :)
TekMol 9y ago
more powerful features, such as threads, are planned as well What, no more async hell when coding for the browser?
- Spivak 9y ago
  Weird, most people seem to prefer the async model. It makes things clunky but it's fairly easy to reason about.
coldtea 9y ago
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?
grumblestumble 9y ago
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 9y ago
  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.
shmerl 9y ago
> 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 9y ago
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.

199 points by steipete 9y ago

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.

jamesXswift 9y ago
Honestly, it's going to be huge, imo. And like all good tech, can be used for good and evil :) We want the best experience for users and devs that we can deliver.
greenhouse_gas 9y ago
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.
- jules 9y ago
  Using the same platform for everything has advantages, e.g. code sharing between client/desktop/mobile/server, mastering 1 standard library as opposed to several, seamless serialisation of data between platforms. From what I've gleaned from the docs so far, WebAssembly is very well designed and more pleasant to target than LLVM. Having a single compiler ensures that the code behaves the same on each platform. If you are asking why I think it may happen rather than why it would be a good idea: imagine that you are a compiler writer for language X. You can target WebAssembly and run the language not only on the web, but also cross platform on servers and desktops and potentially mobile, and you even get a cross platform standard library including networking, UI (DOM/HTML), OpenGL, and more. This will save a tremendous amount of work compared to targeting LLVM separately and implementing your own cross platform libraries (which requires expertise on each platform that the compiler writer is unlikely to have). It's like targeting the JVM but lower level (compiler writers like this) and runs seamlessly on the web like JS. Browser WebAssembly implementations will compile really fast because it has to be loaded and compiled for use on websites, making it suitable for a really fast compiler for interactive development and REPL, while it will be possible to compile to fast code via LLVM.
- nathcd 9y ago
  But the reality of production systems is much more complex than this. Many medium- to large-production systems are written in multiple languages across large and diverse teams, have legacy components, varied open source components, and so on, all talking to each other. Sometimes this is as simple as sending messages around, but sometimes not. C is usually the lingua franca since it's the common denominator on most systems. Maybe WASM will end up in a place to better serve that role?
- jcelerier 9y ago
  > 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 9y ago
    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 9y ago
      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.
- shams93 9y ago
  You don't want to go bankrupt running a server side hls encoder when you can run it in the browser and simply punt the playlist chunks up to a simple s3 bucket directly from the client running ffmpeg in the browser say for a live broadcasting web app.
- jbergens 9y ago
  You don't always know youer server arch and OS. If you sell solutions to others they may choose the server OS and you might want to support as many as possible.
baybal2 9y ago
>WebAssembly could become the universal cross platform low level VM. You know, people tried to do the same thing countless times already, there is Java and it tries to do exactly that. We all know where Java's promise "to run everywhere" went. There are JVMs for things beginning from microcontrollers to s390, but find one that can flawlessly run code that was compiled for a VM that is even one major releases old. Serious software in Java usually comes with something saying "version 2 of this software runs on JVM 'A' 1.4.13 with patchset 'B' 1.2, classpath 'C' 1.5, and exact VM setting from supplied jvm.conf".
- jules 9y ago
  WebAssembly is unlikely to have this issue because it has to run on the web and browsers don't want to break backwards compatibility. Even with these issues the JVM has actually been quite successful as a language platform.
  - kbutler 9y ago
    The edge cases they cited seem to run counter to this expectation: "At this point, we want to issue a special thank you to the WebAssembly teams at Mozilla and Google, especially Alon Zakai, for being so helpful. We did run into a few edge cases but with their help we were able to still make it happen and even improved the Emscripten tool chain a bit along the way." If some percentage of realistic projects run into edge cases that are incompatible with either the spec or between browsers, it violates the whole "write once run anywhere" goal.
    - jules 9y ago
      WebAssembly is in its infancy.
      - kbutler 9y ago
        > WebAssembly is in its infancy Exactly. Expectations that WebAssembly will be more cross-platform than any previous attempt at cross-platform are probably overly optimistic at this point. Though I'm hopeful, as well.
zzbzq 9y ago
It's not possible. As soon as WebAssembly gets as big as the web, someone will implement a browser-embedded browser in WebAssembly that runs in the browser and we will be back to square 1 in this kafkaesque nightmare we call Web.
- chrshawkes 9y ago
  Down votes are unfair, this was quite funny.
  - btilly 9y ago
    Why would you think that it is a joke? It is true and how things have always gone! When I got into computers it would have been ridiculous to imagine carrying around a computer running a different OS in a virtual machine, within which we were running a virtual network of small virtual machines existed to run programs written in a scripting language that itself runs in a VM! Sounds crazy, right? And yet it isn't rare to find a developer on a Mac laptop running Linux in VirtualBox, inside of which they run Docker containers to run applications built on node.js. This is not done as a joke, it is done because it is a useful development environment for an application that is supposed to eventually be deployed to a cloud. Portable software has been a motivating dream of our industry since forever. It was a selling point of COBOL, Pascal, HTML, Java, Flash, JQuery, and so on and so forth. The idea of deploying a known client target to get rid of browser differences is inevitable. It is just a question of who will be the first to do one that is good and fast enough to get mindshare.
- j45 9y ago
  Lol. Can't wait for this piece of art to arrive, plus compile JavaScript web apps could compile to binaries
- j45 9y ago
  Lol. Can't wait for this piece of art to arrive, plus JavaScript web apps could compile to binaries
- thousande 9y ago
  Like running the Windows version of Gimp in Wine in X Window in Chrome inside Firefox on a Mac? http://imgur.com/a/wRals http://imgur.com/a/wRals From: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

frik 9y ago

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 9y ago
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 9y ago
  How did we get here? Please don't post off-topic inflammation.
- mwfunk 9y ago
  No bitterness there, nope.
greenhouse_gas 9y ago
Anything wasm can do, JavaScript can do. And vice versa. Just wasm is faster.
- sp332 9y ago
  I don't think that's right. For example wasm can't do DOM manipulation, although it might be added in the future. But as the article mentions, wasm will be getting even more different, as things like SIMD get added to wasm while SIMD.js has been abandoned.

flavio81 9y ago

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

jamesXswift 9y ago
If anyone has any questions I'll try and answer if I can.
- greenhouse_gas 9y ago
  Did you show it to Mozilla or Google? It seems that it can replace PDF.JS and whatever closed-source PDF reader chrome uses.
  - moosingin3space 9y ago
    Chrome's PDF reader is actually open-source: https://pdfium.googlesource.com/pdfium/ https://pdfium.googlesource.com/pdfium/
    - greenhouse_gas 9y ago
      Sorry. I'm out of date https://bugs.chromium.org/p/chromium/issues/detail?id=50852#c16 https://bugs.chromium.org/p/chromium/issues/detail?id=50852#...
    - mpweiher 9y ago
      And as far as I know it's the engine they're using.
deleted 9y ago
[deleted]
mpweiher 9y ago
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

throwaway95014 9y ago

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?

jamesXswift 9y ago
Understand the hesitancy. But we develop a very high quality engine for as many platforms as we can. I.e. we can maintain less code, keep it fast, maintain high quality and identical behaviour across platforms.
- throwaway95014 9y ago
  I agree, it's 100% rational from your point of view, just as compiling it for the Flash VM or running as an ActiveX component would have made perfect sense for you to bring your high-quality code to more platforms. My hesitation isn't about your code. It's about what we as a community are doing to the web platform.
  - jamesXswift 9y ago
    Yeah it will be interesting. I feel like having used this now that we'd be poorer without it. But you are right. There are ethical challenges ahead.
flavio81 9y ago
In which way it is terrible? It is a Ps and PDF rendering engine. I don't know if you are already aware of this, but Postcript is almost a complete programming language, so writing a Ps renderer is like writing an interpreter (or compiler...) Not trivial stuff at all. Also, why do you call this "legacy C++ code"?
- throwaway95014 9y ago

evmar 9y ago

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 9y ago
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-platform/ https://pspdfkit.com/blog/2016/a-pragmatic-approach-to-cross...
- flavio81 9y ago
  Great work guys! Keep on releasing more interesting libs for wasm!
dvfjsdhgfv 9y ago
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.
9y ago

ChrisSD 9y ago

"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/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...

flavio81 9y ago
Eventually it should replace Javascript. It ought to, because it defines a standard, versatile platform to execute code on the browser.
- limeblack 9y ago
  Although you may be right I hope you are not. I like the semi open source nature and high levelness of JavaScript. It's not perfect but it beats dissembling things. Yes I know there are obfuscators.
luke_wagner 9y ago
Agreed, there was active discussion about this at the last WebAssembly CG meeting even: https://github.com/WebAssembly/meetings/blob/master/2017/CG-07.md#host-bindings https://github.com/WebAssembly/meetings/blob/master/2017/CG-...
- ilaksh 9y ago
  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 9y ago
    > 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 9y ago

.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

jamesXswift 9y ago
Awesome!
yodon 9y ago
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 9y ago
  Downloading .NET Framework v4.0 WASM Edition... 1%... 4 GB to go.
  - yodon 9y ago
    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 9y ago
      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.

ledgerdev 9y ago

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?

sondr3 9y ago
If most of the more recent languages are anything to go by you'd target LLVM and in the future get a WASM support for free.
- kodablah 9y ago
  As WASM gets higher level constructs like structs and GC, you might be wiser to compile to WASM (assuming the WASM-to-LLVM backend is high quality). WASM is primarily focused on being cross-platform and deterministic. I remember when Rust was being written, the devs complained about platform-specific LLVM IR they had to emit. The big question is who will make the first WASM stdlib iface so backends can implement it. Otherwise, you might leverage LLVM right now because you have libc.
yodon 9y ago
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 9y ago
  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.

Malic 9y ago

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.

deleted 9y ago
[deleted]
jahnu 9y ago
It already does! Try it out.
coldtea 9y ago
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 9y ago
  Oops - misinterpretation of skimming the article. Damn day job getting in the way of keeping up with HN articles! :)

TekMol 9y ago

more powerful features, such as threads, are planned as well What, no more async hell when coding for the browser?

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

coldtea 9y ago

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?

grumblestumble 9y ago

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 9y ago
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.

shmerl 9y ago

> 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 9y ago

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.