8 ms·

WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a

WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and verified?) by browsers 2. "Web apps" could potentially go away - leaving web browsers for what they were intended, document sharing

zach43 9y ago
I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems. If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build just a single binary from a C++ compiler which could work natively on all three operating systems? Would the WebAssembly project build the necessary infrastructure (linkers, dynamic loader, etc) for this to work?
- baq 9y ago
  If you google around, you'll find that POCs exist - qt apps on the browser in canvas tags. Accessibility nightmare but otherwise a dream come true in the so called enterprise. Can't wait for this tech to mature a bit more.
- jfbastien 9y ago
  In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are kind of like an OS' syscalls. That's a lot of work, isn't very advanced yet, but in theory is all possible and WebAssembly was explicitly designed to make it possible.
  - slededit 9y ago
    I'm actually working on an effort in this space. Specifically we're at the point where it's time to stand up a libc in a non web embedding. If anyone is interested in the effort they should let me know.
    - jfbastien 9y ago
      I'd honestly just start with musl libc. The one Emscripten supports mostly just imports the same syscalls as Linux, with some ugliness to be able to do some DCE. If you clean that up your embedder will only need to implement those syscalls.
      - slededit 9y ago
        I am working with musl, however not the one with emscripten. That one is heavily modified farming out significant parts to the javascript runtime. It is a goal to provide a minimal surface area for embeddors and part of that is not requiring a JS runtime.
    - mwcampbell 9y ago
      Please contact me privately. My email is in my profile. Thanks!
- flohofwoe 9y ago
  WebAssembly itself is just (more or less) an instruction set, not a complete runtime platform. It doesn't define APIs for rendering, audio, input, filesystem access, networking, etc... Electron provides all that, but at the very high cost of shipping a complete browser runtime with your app.
  - kodablah 9y ago
    Yup, we need an stdlib (and not libc)
  - primeblue 9y ago
    Oh don't you worry, that will come and we'll be free of that ugly JavaScript thing.
- kuschku 9y ago
  You are lucky, Java 9 was just released. Now you can ahead-of-time compile any JVM project into a single executable, it will run on all platforms, and it will have nice UI toolkits (JavaFX is quite awesome). Even better, with Truffle + Graal in Java 10 also native interoperability with basically every other language is coming, so you can basically combine this with every language.
- gwbas1c 9y ago
  Write once, run everywhere always has various tradeoffs. The closer you get to fundamental differences in operating systems, the more platform-specific code you need. UI, for example, is hard to make platform independent if your application needs to look and feel native; or needs to plug into platform-specific features. What would be useful is a way to easily call WebAssembly libraries from native applications. This way common business logic can be written cross-platform; but the parts of an application that need to remain native are left native.
- pebers 9y ago
  No, because at the least all three have different executable formats (PE, Mach-O and ELF respectively). I suppose it might end up being possible to ship some sort of HTML + WASM bundle that they all know how to interpret if it became common enough.
lmkg 9y ago
I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a <canvas> element.
- RubenSandwich 9y ago
  I hope not as HTML has accessibility built in while canvas doesn’t. No need to take a step backwards on this. I’m okay with rendering to canvas but long as accessibility is taken into account. (Hint: most of the time it is not.)
  - wlesieutre 9y ago
    I've said the same, but you just know somebody comes along and says "If we render our entire site into a <canvas> it'll make ad blocking more difficult," and then poof there goes the last 20 years of work on accessibility.
    - EvanAnderson 9y ago
      Agreed. There will also be the "This will prevent scrapers" excuse. Whatever the silly rationalization for all-Flash websites was will be invoked, as well.
    - vvanders 9y ago
      Oy, that has to be the most depressing thing I've read all day.
    - gbuk2013 9y ago
      Good luck for that site getting indexed by Google ;)
      - kuschku 9y ago
        Just like with AJAX sites, Google will simply support it. But writing third-party search engines will become even more impossible.
AnIdiotOnTheNet 9y ago
We had that in the 90s. We called it Java.
- grondilu 9y ago
  https://www.quora.com/What-is-the-difference-between-Java-WebAssembly https://www.quora.com/What-is-the-difference-between-Java-We...
- DiThi 9y ago
  Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple implementations in the first place. And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).
  - AnIdiotOnTheNet 9y ago
    And how much of that is true today?
    - DiThi 9y ago
      All of it except the closed source part. The design decisions are still there, the attack surface is still pretty big (although with much more testing and fuzzing done to date), and there's still only one implementation that can run any applet out there (not counting MS java which was abandoned when XP was released).
    - primeblue 9y ago
      It's still ugly
  - weinzierl 9y ago
    > Java only had one closed source implementation... This is not true. There were alternative implementations from very early on, most notably the Microsoft one. > ...and had many security issues during its life. True, but WASM hadn't had much of a life so far, so we will see. > And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings). From what I understand, so far, every communication between the browser and WASM has to go through JavaScript and from what I see I think it's ugly as well[1]. Don't get me wrong, I'm not at all against WASM, but I see the very same arguments for and against WASM I remember from the 90s about Java. This is especially true when it comes to security. Java was designed with a sandbox and a bytecode verifier from very early on. [1] https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html https://kripken.github.io/emscripten-site/docs/porting/conne...
ams6110 9y ago
> It may become the future platform that native, dekstop apps run on So Flash, again?
- pjmlp 9y ago
  Someone will most certanly implement a SWF to WebAssembly converter.
  - primeblue 9y ago
    They should be fined
otakucode 9y ago
My first thought reading the specification was '6 months before there's silicon that runs the bytecode directly.'
- Ajedi32 9y ago
  Obligatory "The Birth & Death of JavaScript" reference: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... METAL is coming.
- weinzierl 9y ago
  No really. WASM is based on a stack machine and not a register machine. On the other hand there was PicoJava [1] and there is Jazelle [2]. So, maybe... [1] https://en.wikipedia.org/wiki/PicoJava https://en.wikipedia.org/wiki/PicoJava [2] https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
  - pjmlp 9y ago
    Stack machines used to be common in mainframe hardware, back in the day. http://www.retrocomputingtasmania.com/home/projects/burroughs-b5500 http://www.retrocomputingtasmania.com/home/projects/burrough... http://datamuseum.dk/wiki/Rational/R1000s400 http://datamuseum.dk/wiki/Rational/R1000s400
mtgx 9y ago
Sounds like good news for Chromebooks.
Ajedi32 9y ago
> "Web apps" could potentially go away I prefer to think of it instead as native apps going away. Or rather, the web becoming indistinguishable from native. If native apps start being run on WASM, and web apps start being run on WASM, and the web continues to gain access to more and more "native" APIs... it may not be long before there's basically no difference between a native app and a web app, from the end-user _or_ developer's perspective.
- krapp 9y ago
  I feel like this won't really take off until we have something other than a web browser, or something that just feels different from a web browser, which is optimized for WASM applications, and which includes package management. Caching a WASM application locally is not much different than downloading a standalone native binary.
  - archagon 9y ago
    Yes! Get rid of the chrome, navigation buttons, etc. and give us a pseudo-VM that runs the browser as we know it as an “app”. I hope WASM and the like might eventually lead us there.
    - krapp 9y ago
      It makes sense if the web is going to be divided up between "documents" and "applications" (which it is, whether anyone likes it or not) not to run the applications in an environment designed to display documents. Bonus points if the default is to download, cache and update the source code and "installation" is just local compilation to an appdata folder or something, similar to what browsers do with HTML, CSS and JS, rather than just download a blob of bytecode. That would make the FOSS people happy.

zach43 9y ago

I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems. If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build just a single binary from a C++ compiler which could work natively on all three operating systems? Would the WebAssembly project build the necessary infrastructure (linkers, dynamic loader, etc) for this to work?

baq 9y ago
If you google around, you'll find that POCs exist - qt apps on the browser in canvas tags. Accessibility nightmare but otherwise a dream come true in the so called enterprise. Can't wait for this tech to mature a bit more.
jfbastien 9y ago
In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are kind of like an OS' syscalls. That's a lot of work, isn't very advanced yet, but in theory is all possible and WebAssembly was explicitly designed to make it possible.
- slededit 9y ago
  I'm actually working on an effort in this space. Specifically we're at the point where it's time to stand up a libc in a non web embedding. If anyone is interested in the effort they should let me know.
  - jfbastien 9y ago
    I'd honestly just start with musl libc. The one Emscripten supports mostly just imports the same syscalls as Linux, with some ugliness to be able to do some DCE. If you clean that up your embedder will only need to implement those syscalls.
    - slededit 9y ago
      I am working with musl, however not the one with emscripten. That one is heavily modified farming out significant parts to the javascript runtime. It is a goal to provide a minimal surface area for embeddors and part of that is not requiring a JS runtime.
  - mwcampbell 9y ago
    Please contact me privately. My email is in my profile. Thanks!
flohofwoe 9y ago
WebAssembly itself is just (more or less) an instruction set, not a complete runtime platform. It doesn't define APIs for rendering, audio, input, filesystem access, networking, etc... Electron provides all that, but at the very high cost of shipping a complete browser runtime with your app.
- kodablah 9y ago
  Yup, we need an stdlib (and not libc)
- primeblue 9y ago
  Oh don't you worry, that will come and we'll be free of that ugly JavaScript thing.
kuschku 9y ago
You are lucky, Java 9 was just released. Now you can ahead-of-time compile any JVM project into a single executable, it will run on all platforms, and it will have nice UI toolkits (JavaFX is quite awesome). Even better, with Truffle + Graal in Java 10 also native interoperability with basically every other language is coming, so you can basically combine this with every language.
gwbas1c 9y ago
Write once, run everywhere always has various tradeoffs. The closer you get to fundamental differences in operating systems, the more platform-specific code you need. UI, for example, is hard to make platform independent if your application needs to look and feel native; or needs to plug into platform-specific features. What would be useful is a way to easily call WebAssembly libraries from native applications. This way common business logic can be written cross-platform; but the parts of an application that need to remain native are left native.
pebers 9y ago
No, because at the least all three have different executable formats (PE, Mach-O and ELF respectively). I suppose it might end up being possible to ship some sort of HTML + WASM bundle that they all know how to interpret if it became common enough.

lmkg 9y ago

I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a <canvas> element.

RubenSandwich 9y ago
I hope not as HTML has accessibility built in while canvas doesn’t. No need to take a step backwards on this. I’m okay with rendering to canvas but long as accessibility is taken into account. (Hint: most of the time it is not.)
- wlesieutre 9y ago
  I've said the same, but you just know somebody comes along and says "If we render our entire site into a <canvas> it'll make ad blocking more difficult," and then poof there goes the last 20 years of work on accessibility.
  - EvanAnderson 9y ago
    Agreed. There will also be the "This will prevent scrapers" excuse. Whatever the silly rationalization for all-Flash websites was will be invoked, as well.
  - vvanders 9y ago
    Oy, that has to be the most depressing thing I've read all day.
  - gbuk2013 9y ago
    Good luck for that site getting indexed by Google ;)
    - kuschku 9y ago
      Just like with AJAX sites, Google will simply support it. But writing third-party search engines will become even more impossible.

AnIdiotOnTheNet 9y ago

We had that in the 90s. We called it Java.

grondilu 9y ago
https://www.quora.com/What-is-the-difference-between-Java-WebAssembly https://www.quora.com/What-is-the-difference-between-Java-We...
DiThi 9y ago
Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple implementations in the first place. And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).
- AnIdiotOnTheNet 9y ago
  And how much of that is true today?
  - DiThi 9y ago
    All of it except the closed source part. The design decisions are still there, the attack surface is still pretty big (although with much more testing and fuzzing done to date), and there's still only one implementation that can run any applet out there (not counting MS java which was abandoned when XP was released).
  - primeblue 9y ago
    It's still ugly
- weinzierl 9y ago
  > Java only had one closed source implementation... This is not true. There were alternative implementations from very early on, most notably the Microsoft one. > ...and had many security issues during its life. True, but WASM hadn't had much of a life so far, so we will see. > And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings). From what I understand, so far, every communication between the browser and WASM has to go through JavaScript and from what I see I think it's ugly as well[1]. Don't get me wrong, I'm not at all against WASM, but I see the very same arguments for and against WASM I remember from the 90s about Java. This is especially true when it comes to security. Java was designed with a sandbox and a bytecode verifier from very early on. [1] https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html https://kripken.github.io/emscripten-site/docs/porting/conne...

ams6110 9y ago

> It may become the future platform that native, dekstop apps run on So Flash, again?

pjmlp 9y ago
Someone will most certanly implement a SWF to WebAssembly converter.
- primeblue 9y ago
  They should be fined

otakucode 9y ago

My first thought reading the specification was '6 months before there's silicon that runs the bytecode directly.'

Ajedi32 9y ago
Obligatory "The Birth & Death of JavaScript" reference: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... METAL is coming.
weinzierl 9y ago
No really. WASM is based on a stack machine and not a register machine. On the other hand there was PicoJava [1] and there is Jazelle [2]. So, maybe... [1] https://en.wikipedia.org/wiki/PicoJava https://en.wikipedia.org/wiki/PicoJava [2] https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- pjmlp 9y ago
  Stack machines used to be common in mainframe hardware, back in the day. http://www.retrocomputingtasmania.com/home/projects/burroughs-b5500 http://www.retrocomputingtasmania.com/home/projects/burrough... http://datamuseum.dk/wiki/Rational/R1000s400 http://datamuseum.dk/wiki/Rational/R1000s400

mtgx 9y ago

Sounds like good news for Chromebooks.

Ajedi32 9y ago

> "Web apps" could potentially go away I prefer to think of it instead as native apps going away. Or rather, the web becoming indistinguishable from native. If native apps start being run on WASM, and web apps start being run on WASM, and the web continues to gain access to more and more "native" APIs... it may not be long before there's basically no difference between a native app and a web app, from the end-user _or_ developer's perspective.

krapp 9y ago
I feel like this won't really take off until we have something other than a web browser, or something that just feels different from a web browser, which is optimized for WASM applications, and which includes package management. Caching a WASM application locally is not much different than downloading a standalone native binary.
- archagon 9y ago
  Yes! Get rid of the chrome, navigation buttons, etc. and give us a pseudo-VM that runs the browser as we know it as an “app”. I hope WASM and the like might eventually lead us there.
  - krapp 9y ago
    It makes sense if the web is going to be divided up between "documents" and "applications" (which it is, whether anyone likes it or not) not to run the applications in an environment designed to display documents. Bonus points if the default is to download, cache and update the source code and "installation" is just local compilation to an appdata folder or something, similar to what browsers do with HTML, CSS and JS, rather than just download a blob of bytecode. That would make the FOSS people happy.