Bringing the web up to speed with WebAssembly(blog.acolyer.org)
blog.acolyer.org
Bringing the web up to speed with WebAssembly
https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/
171 comments
> "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.
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.
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.
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.
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.
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.
I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a <canvas> element.
I don't think so, at least not from non-professional content producers. There will still be a desire to have an easily written, shared, and rendered document upon which you can give your thoughts.
HTML has always been best at that, and will still be good at that in the future. The only contender I know of would be markdown, which fulfills many of those needs while being even easier to write. Its greatest pitfall in a contest against HTML is that it is by design non-standard, as it is meant to be a pre-render stage document, and presumably your render stage will smooth out any non-standard markdown elements, giving you a standard document in a format like HTML.
HTML has always been best at that, and will still be good at that in the future. The only contender I know of would be markdown, which fulfills many of those needs while being even easier to write. Its greatest pitfall in a contest against HTML is that it is by design non-standard, as it is meant to be a pre-render stage document, and presumably your render stage will smooth out any non-standard markdown elements, giving you a standard document in a format like HTML.
It can't be that and that alone unless browsers somehow decide not to support the rest of HTML... which seems very unlikely.
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.)
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.
We can port webkit to wasm, so our developers won't have to deal with browser inconsistencies anymore :)
Yeah, and V8, so we could just write JavaScript again and wouldn't have to deal with WASM. With a bit support from WASM and a few tweaks to V8 it could run near native JavaScript speed. Let's call it JavaScript paravirtualization.
If you strip out the legacy cruft it should be much faster. Reduce it to just the components used!
If I understood properly: yes, I do share the bitterness.
<troll> Look at us introduce this great new lang! It will potentially get rid of 99.99% of the current web developers and prevent any future script kiddies from getting in the game!
Behold the speed of our sealed box environment little jimmy!
Stay tuned for next weeks episode of Tech%20Elitism where we cover DRM for the web and public discourse policing!
If I understood properly: yes, I do share the bitterness.
<troll> Look at us introduce this great new lang! It will potentially get rid of 99.99% of the current web developers and prevent any future script kiddies from getting in the game!
Behold the speed of our sealed box environment little jimmy!
Stay tuned for next weeks episode of Tech%20Elitism where we cover DRM for the web and public discourse policing!
Interpreters can go a long way, but JIT code generation is required for really fast dynamic language implementation. That's quite a bit off for WebAssembly: https://github.com/WebAssembly/design/blob/master/FutureFeat...
Oy, that has to be the most depressing thing I've read all day.
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.
Most ad blocking is about intercepting specific urls, which can work at a layer below javascript.
They can also do server side ads and make the url indistinguishable from another image asset. They haven't, so it isn't 'dire' enough yet.
They can also do server side ads and make the url indistinguishable from another image asset. They haven't, so it isn't 'dire' enough yet.
Good luck for that site getting indexed by Google ;)
Just like with AJAX sites, Google will simply support it.
But writing third-party search engines will become even more impossible.
But writing third-party search engines will become even more impossible.
HTML is also much a more convenient encoding for content than writing on the canvas. It's fully declarative¹ and everything.
Yet, plenty of people already prefer to send you a black page and manually write everything on the DOM's document. I certainly do not understand them, but they are way too common.
1 - You just write your content, and it's there. There isn't more declarative than that.
Yet, plenty of people already prefer to send you a black page and manually write everything on the DOM's document. I certainly do not understand them, but they are way too common.
1 - You just write your content, and it's there. There isn't more declarative than that.
HTML isn't great for application code. That's the issue, and anyone targeting WASM and canvas would be looking to recreate desktop apps on the web, not traditional websites.
Yes, it's bad for applications. But that does not explain why people send their text based pages as javascript.
> But that does not explain why people send their text based pages as javascript.
Probably because they're using front-end javascript frameworks which do that, and because they were taught that this is the best and most efficient way to render anything on the web. No one wants to make a special case for text because it seems inelegant.
Probably because they're using front-end javascript frameworks which do that, and because they were taught that this is the best and most efficient way to render anything on the web. No one wants to make a special case for text because it seems inelegant.
But it's not the best and most efficient way to render everything. If you have a mostly static site, you don't need the front-end framework.
[deleted]
Same here.
I am beting once WebAssembly gets mature enough, we will get the revenge of plugins.
I am beting once WebAssembly gets mature enough, we will get the revenge of plugins.
Nothing intrinsically wrong with plugins that are instantly available on every platform.
Alas poor applets, they were before their time.
Canvas is too slow and handles text rendering poorly. If browsers really want to take another step in that particular direction, they're going to have to expose a lower level API for graphics and text rendering.
Yes, something like OpenGL.
Maybe. OpenGL has a lot of history and baggage. I'm pretty sure the current browser engines don't use OpenGL for 2d graphics. I think they still use Skia (Chrome) and Cairo (WebKit). It could be as "easy" as allowing calls to be made directly to those graphics libraries in WebAssembly.
Skia makes use of OpenGL, DirectX or Vulkan.
In any case, it should be hierarchical. It should be simple and efficient to move an object and all its children around.
I think you're missing the point. An object and child hierarchy is too high level for what I'm suggesting. Just expose the graphics library and let the programmers handle the rest. If you want something hierarchical that's simple and efficient to move an object and all its children around, great. You write that for your applications. Make it into a framework if others want to use it. But if somebody wants to use a different approach for their application, they should be able to do so.
Well, I'm all for a low level approach. But going a little higher allows the GPU to handle a lot of things. Or do you propose to incorporate something like CUDA/OpenCL into WASM?
SVG perhaps?
Say... WebGL?
The web is mostly documents, with a few apps sprinkled here and there. HTML will likely be around, and in good use, for a long time.
Even the apps will use HTML's model via their DOM tree.
Even the apps will use HTML's model via their DOM tree.
Yes, and there will be a default WASM code that interprets and renders the rest of the HTML! (in case anybody still wants to use HTML as W3C defined it).
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?
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?
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.
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.
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.
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.
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 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.
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.
If anyone is interested in the effort they should let me know.
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.
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.
Please contact me privately. My email is in my profile. Thanks!
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.
Electron provides all that, but at the very high cost of shipping a complete browser runtime with your app.
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.
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.
We had that in the 90s. We called it Java.
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).
> 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/conne...
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/conne...
> most notably the Microsoft one.
My bad. However it was closed source too, and abandoned rather quickly.
> True but WASM hadn't had much of a life so far, so we will see.
It uses the same security model as JS, which is much more mature than VMs not designed for so much exposure to random third party code.
> from what I see I think it's ugly as well
Ugly but not slow. WASM memory can be read and written directly from/to a typed array, instead of converting strings. Since it's fast enough, one can make less ugly APIs wrapping that behaviour.
> Java was designed with a sandbox and a bytecode verifier from very early on.
They probably protected the code itself from escaping the sandbox, but not the environment (all the API in its complex glory). WASM on the other side is exclusively allowed to talk with JS (for now, at least), therefore the only API level bugs are in JS, not in WASM.
My bad. However it was closed source too, and abandoned rather quickly.
> True but WASM hadn't had much of a life so far, so we will see.
It uses the same security model as JS, which is much more mature than VMs not designed for so much exposure to random third party code.
> from what I see I think it's ugly as well
Ugly but not slow. WASM memory can be read and written directly from/to a typed array, instead of converting strings. Since it's fast enough, one can make less ugly APIs wrapping that behaviour.
> Java was designed with a sandbox and a bytecode verifier from very early on.
They probably protected the code itself from escaping the sandbox, but not the environment (all the API in its complex glory). WASM on the other side is exclusively allowed to talk with JS (for now, at least), therefore the only API level bugs are in JS, not in WASM.
> The goal for WASM is to enable browsers to run untrusted code in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent code from inspecting or changing files on the client file system. Also, the intent is to prevent code from using network connections to circumvent file protections or people's expectations of privacy.
> WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment.
Sounds familiar? This is straight from 1998 [1](ha!) with JDK replaced by WASM and applet/classes by code;-) I hear you and I hope this is enough for WASM to succeed. Still I don't see the killer argument why I should believe it will.
[1] https://web.archive.org/web/19980214233937/http://java.sun.c...
> WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment.
Sounds familiar? This is straight from 1998 [1](ha!) with JDK replaced by WASM and applet/classes by code;-) I hear you and I hope this is enough for WASM to succeed. Still I don't see the killer argument why I should believe it will.
[1] https://web.archive.org/web/19980214233937/http://java.sun.c...
"functionality" in this case means APIs. WASM won't have any APIs that JS doesn't already have. So "conservative" means "just a few APIs", not "just communication with code in an already battle-proven VM". And AFAIK there are no plans for "loading and authenticating signed code" in WASM. It's always untrusted unless you run it with a runtime that provides the privileged APIs (such as node.js). Java always had both unprivileged and privileged APIs in the same place.
And how much of that is true today?
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).
It's still ugly
Java never had, or tried to have, binary portability.
"Write once, run everywhere" was literally the motto of Java. Java bytecode does run everywhere there is a JRE and the JRE has been ported to a lot of hardware.
I'm quite excited about WASM (as I was, admittedly, about Java Applets in the 90s), but this is a question that haunts me. I wish someone with better understanding of WASM and Java than me could write up why byte code delivery to a sandboxed VM in the browser failed in the 90s and why we should believe it will succeed now, or what exactly WASM brings to the table that Java didn't.
I think it mainly failed because Sun basically abandoned it. Security was not the issue I think (Flash was the same, maybe worse, still widely used) but the UX was quite terrible and never really improved: You had the jvm with its long startup times which was more than noticeable in the 90s and early 2000s. Applets always felt very alien inside a Website and using the applet simply to call into optimized code from JS was, while possible not really what it was used for.
Security maybe more of an issue today but WASM probably is not worse than JS in that regard (basically it's just another turing complete language). As others have said APIs are more problematic, which I suspect will ever get worse while browsers further and further try to transform from document viewers to application runtimes (think of such "brilliant" ideas like WebUSB). WASM is not the key issue here, it's running untrusted code on the client which, even if it's sometimes not outright harmful takes control away from the user in one way or antother. In the end the main difference is that it's now a feature of the Browser rather than a plugin which has a hard time to fit in nicely.
Security maybe more of an issue today but WASM probably is not worse than JS in that regard (basically it's just another turing complete language). As others have said APIs are more problematic, which I suspect will ever get worse while browsers further and further try to transform from document viewers to application runtimes (think of such "brilliant" ideas like WebUSB). WASM is not the key issue here, it's running untrusted code on the client which, even if it's sometimes not outright harmful takes control away from the user in one way or antother. In the end the main difference is that it's now a feature of the Browser rather than a plugin which has a hard time to fit in nicely.
Virtual machines tend to take a while to initialize, for Java in part to verify the code.
If it were just the bytecode then it would not have failed. JVM bytecode and WASM have plenty of similarities. What cost Java is the stdlib surface area and security model. Also that it is a separate runtime was annoying, like Adobe with Flash, there was one primary vendor.
So many JVM bugs and a huge stdlib. WASM has no real lib, and when it does, it's security model is already restrictive... there's no disk, network, threads (yet), etc.
So many JVM bugs and a huge stdlib. WASM has no real lib, and when it does, it's security model is already restrictive... there's no disk, network, threads (yet), etc.
Along with the other responses, the JVM imposes its own object model on any language implemented on top of it. WebAssembly does not, so it is vastly simpler and more flexible.
For example, you had to rewrite your apps to run as Java applets. You do not have to rewrite things to run on WebAssembly- all the existing C, C++, etc. code is compatible, up to the platform API.
For example, you had to rewrite your apps to run as Java applets. You do not have to rewrite things to run on WebAssembly- all the existing C, C++, etc. code is compatible, up to the platform API.
This is of course assuming that the WASM GC proposal doesn't require a specific object model to get host GC interop.
So far it doesn't look like it will: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
But either way, I'd still take "use this object model for host GC interop" over "use this object model or leave the platform."
But either way, I'd still take "use this object model for host GC interop" over "use this object model or leave the platform."
A big reason Java failed was that it was painfully slow. Starting the VM and importing everything took tens of seconds on old machines, and still takes a couple of seconds on new ones.
Then people started worrying about security and all of the Java applets broke because nobody wants to go through that code signing process.
I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.
Then people started worrying about security and all of the Java applets broke because nobody wants to go through that code signing process.
I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.
>I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.
WebAssembly in browsers executes similarly to javascript in the same sandbox with the same platform APIs with the same kind of delivery methods, so I don't think we have that to worry about.
WebAssembly in browsers executes similarly to javascript in the same sandbox with the same platform APIs with the same kind of delivery methods, so I don't think we have that to worry about.
That's very much the question indeed. All that's really needed for a native experience on both Android and iOS is a native ARM binary, optionally bundled with webkit, but then that's what native runtime environments for Android and iOS have already built-in.
It was so ugly
My first thought reading the specification was '6 months before there's silicon that runs the bytecode directly.'
Obligatory "The Birth & Death of JavaScript" reference: https://www.destroyallsoftware.com/talks/the-birth-and-death...
METAL is coming.
METAL is coming.
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
[2] https://en.wikipedia.org/wiki/Jazelle
[1] https://en.wikipedia.org/wiki/PicoJava
[2] https://en.wikipedia.org/wiki/Jazelle
Stack machines used to be common in mainframe hardware, back in the day.
http://www.retrocomputingtasmania.com/home/projects/burrough...
http://datamuseum.dk/wiki/Rational/R1000s400
http://www.retrocomputingtasmania.com/home/projects/burrough...
http://datamuseum.dk/wiki/Rational/R1000s400
Sounds like good news for Chromebooks.
WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic.
Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Everything running from WASM is in an isolated sandbox. For obvious security reasons this isn't likely to change.
Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Everything running from WASM is in an isolated sandbox. For obvious security reasons this isn't likely to change.
> Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't.
Note that WebAssembly is an MVP right now. It's getting threads, SIMD, native DOM interaction, GC, which would allow many languages to compile to it and run efficiently.
http://webassembly.org/docs/future-features/
Note that WebAssembly is an MVP right now. It's getting threads, SIMD, native DOM interaction, GC, which would allow many languages to compile to it and run efficiently.
http://webassembly.org/docs/future-features/
I did not see native DOM interaction in that document and the thing it linked to is 404.
Hmm, that website mirrors github but got stale: https://github.com/WebAssembly/design/blob/master/FutureFeat...
It now links to here: https://github.com/WebAssembly/design/issues/1079
The person maintaining that mirror went back to grad school, I'll see who maintains it now. Apologies for the 404.
It now links to here: https://github.com/WebAssembly/design/issues/1079
The person maintaining that mirror went back to grad school, I'll see who maintains it now. Apologies for the 404.
> Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic.
I disagree. Flash could draw things without interacting with DOM thorough JS. Also Flash had sophisticated IDE. WebAssembly is just asm.js+ with a strong aim to compile C/C++ for the web, so you don't need to rewrite anything.
I disagree. Flash could draw things without interacting with DOM thorough JS. Also Flash had sophisticated IDE. WebAssembly is just asm.js+ with a strong aim to compile C/C++ for the web, so you don't need to rewrite anything.
There are various drawing surfaces on the web that don't involve interacting with the DOM (canvas, webgl, etc).
I'm not sure what you mean about the IDE? Webassembly won't restrict what source language you use so you'll be able to use any IDE that supports your chosen language. And that would include Flash and its tools if someone writes a compiler.
I'm not sure what you mean about the IDE? Webassembly won't restrict what source language you use so you'll be able to use any IDE that supports your chosen language. And that would include Flash and its tools if someone writes a compiler.
I mean Flash had a dedicated IDE. WebAssembly can be compared to ABC (ActionScript Bytecode) not to Flash.
WebAssembly is a compilation target (like JVM Bytecode). You need an IDE for the source language, not the target.
That's his/her point; they were trying to point out why Flash and WebAssembly aren't analogous.. Flash was a cohesive toolchain; not a build target.
Exactly. So the patent can compare WebAssembly to ActionScript byte code or swf binary format not to Flash.
> ..., to the web
And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, which are not in the WA scope. But for some embedded use cases this is not a blocker: the API is there at the C level, one just need to expose it to the WA runtime (which could be automated, see SWIG and the like). A secure format, with some strong backers and high performance open source implementations has a lot of potential. I'm very curious about the footprint of the loader/compiler/runtime: it should be ok for most Linux embedded systems, but how low-end could it go as a secure ISA agnostic code distribution system?
For your second point, JavaScript is also sandboxed. On principle, there is no reason that in time the API offered to JS today won't become available to the WA runtime in the future --- although I've no idea if there's any actual work along those lines, I don't follow web front-end tech too closely.
And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, which are not in the WA scope. But for some embedded use cases this is not a blocker: the API is there at the C level, one just need to expose it to the WA runtime (which could be automated, see SWIG and the like). A secure format, with some strong backers and high performance open source implementations has a lot of potential. I'm very curious about the footprint of the loader/compiler/runtime: it should be ok for most Linux embedded systems, but how low-end could it go as a secure ISA agnostic code distribution system?
For your second point, JavaScript is also sandboxed. On principle, there is no reason that in time the API offered to JS today won't become available to the WA runtime in the future --- although I've no idea if there's any actual work along those lines, I don't follow web front-end tech too closely.
> For your second point, JavaScript is also sandboxed.
There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on....
To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO.
WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.
There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on....
To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO.
WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.
Actually the eventual goal is to give WASM access to import "environment" apis, which in the browser means DOM, Cookies, etc.
See the design documents: https://github.com/WebAssembly/design/blob/master/Portabilit...
See the design documents: https://github.com/WebAssembly/design/blob/master/Portabilit...
You should be able to write a very basic WebAssembly compiler in much less than half a megabyte. The WebAssembly format itself can be assumed to already be pre-optimized, and is expressed in terms of i32/i64/f32/f64 with an infinite register set and stack machine, with a very well structured control flow. You really don't need a smart compiler to lower this to semi-efficient code. The runtime in a non-JavaScript embedder then has to expose a series of syscalls, but that's not very big either.
Well anything that lets me run Lua in the browser[1] is cool by me ;).
But yeah, interop is something that you can't just hand-wave away. It needs to be done carefully and with the right semantics and performance. That said I think we well get there and for a certain limited use cases it's already there.
[1] https://github.com/vvanders/wasm_lua
But yeah, interop is something that you can't just hand-wave away. It needs to be done carefully and with the right semantics and performance. That said I think we well get there and for a certain limited use cases it's already there.
[1] https://github.com/vvanders/wasm_lua
Oh man, with Lua in the browser, I'd actually start to write web stuff again. And we could get a really nice fast port of Love2D running!
Yeah, probably wouldn't be too hard. I've got Lua things drawing to an HTML5 canvas that runs at 60 FPS on a private project.
As long as you don't make 1000's of calls per frame it runs pretty well.
As long as you don't make 1000's of calls per frame it runs pretty well.
>Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't.
It already is. Lua has already been ported to WebAssembly, people are writing apps in C/C++ with SDL, I've seen MVPs of .Net, and once WASM gets native garbage collection, the floodgates are going to open. The sandbox only makes it more attractive.
It already is. Lua has already been ported to WebAssembly, people are writing apps in C/C++ with SDL, I've seen MVPs of .Net, and once WASM gets native garbage collection, the floodgates are going to open. The sandbox only makes it more attractive.
Yeah, I wonder why OP thinks that the sandbox is bad.
Yes, you won't be able to use the filesystem and other std stuff, but you want to do browser stuff in the browser, like creating websockets and coloring your dom nodes in various colors
Yes, you won't be able to use the filesystem and other std stuff, but you want to do browser stuff in the browser, like creating websockets and coloring your dom nodes in various colors
> more secure
Is it? How do we know? The attack surface in browsers is huge.
Is it? How do we know? The attack surface in browsers is huge.
A few ways that come to mind:
1. WebAssembly has almost no APIs to the platforms whereas Flash had a bunch (i.e. it's "as safe as JavaScript, because it can only call JavaScript"). 2. The code is all new, as opposed to what I hear is a hard-to-maintain older codebase which wasn't designed with security in mind. 3. It's very static in that memory accesses are pretty easy to bounds check for the compiler.
Implementation-wise there's plenty of interesting things that can be done to tighten security of WebAssembly.
1. WebAssembly has almost no APIs to the platforms whereas Flash had a bunch (i.e. it's "as safe as JavaScript, because it can only call JavaScript"). 2. The code is all new, as opposed to what I hear is a hard-to-maintain older codebase which wasn't designed with security in mind. 3. It's very static in that memory accesses are pretty easy to bounds check for the compiler.
Implementation-wise there's plenty of interesting things that can be done to tighten security of WebAssembly.
And how long do you think that'll last? As developers stubbornly persist in trying to make desktop applications on the web, they'll demand more and more access to the host, and browser developers will give it to them in an effort to one-up each other.
If anyone had actually cared about security on the web we wouldn't be where we are now.
If anyone had actually cared about security on the web we wouldn't be where we are now.
Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/
That doesn’t help, as the browser vendors ignore the W3C entirely anyway, and just do stuff in the WHATWG.
And we already have a bluetooth stack for the web, USB drivers in JS, etc.
And we already have a bluetooth stack for the web, USB drivers in JS, etc.
That is entirely incorrect for the WebAssembly CG and WG.
The WebAssembly grouo may be different, but in every other group I've seen, the browsers simply didn't care about what everyone else was doing.
To the point that they redefined the URL spec and then complained that cURL didn't fulfill it.
To the point that they redefined the URL spec and then complained that cURL didn't fulfill it.
I was a bit skeptical of WebAssembly when it started popping up, but reading through this and the MDN docs has made me get a bit more excited.
In a few years WebAssembly might make for a great environment to learn about lower level programming. I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything.
What's the reasonable thing to do when a grow-memory instruction returns -1?
How are people using WebAssembly? Are there high-quality polyfills available for older browsers?
How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?
In a few years WebAssembly might make for a great environment to learn about lower level programming. I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything.
What's the reasonable thing to do when a grow-memory instruction returns -1?
How are people using WebAssembly? Are there high-quality polyfills available for older browsers?
How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?
> I've always loved assembly, since it gives you the bare minimum of concepts and tooling from which you can build everything.
Well... modern assembly is monstrously complex. Probably more so than your favorite high level programming language. Modern assembly is generally not a bare minimum, because it's designed to give compilers the interface to run code fast, not to be easy to program by people.
And WebAssembly is a bit of a misnomer since it's not quite your processor's assembly; it's designed to be assembled fast on the client side, while also being memory-safe. Ironically that makes it simpler than actual assembly.
Well... modern assembly is monstrously complex. Probably more so than your favorite high level programming language. Modern assembly is generally not a bare minimum, because it's designed to give compilers the interface to run code fast, not to be easy to program by people.
And WebAssembly is a bit of a misnomer since it's not quite your processor's assembly; it's designed to be assembled fast on the client side, while also being memory-safe. Ironically that makes it simpler than actual assembly.
It sounds like you're assuming they were talking about x86 when they didn't actually specify...
I learned assembly with an 8086 emulator, and I've had the pleasure of writing assembly for bare-metal ARM microcontrollers. But you're right, modern x86 assembly is a whole different beast. I've tried looking through their manuals, but as I recall their manuals are largely unapproachable +3000 page tomes.
My comment was written with the 8086 emulator in mind. It was great because you could view what was in each register, as well as the inspect any section of memory.
My comment was written with the 8086 emulator in mind. It was great because you could view what was in each register, as well as the inspect any section of memory.
> What's the reasonable thing to do when a grow-memory instruction returns -1?
A good assumption is that your WebAssembly binary already has an implementation of malloc which calls grow_memory. It should do something sane, and you shouldn't need to worry: it's similar to having mmap fail on other platforms. What do you do when mmap fail? I usually just give up and abort, but in rare cases I'll do other fancy things.
> Are there high-quality polyfills available for older browsers?
Work had started in 2015 for a solid polyfill, but now all major browser vendors have shipped WebAssembly so that work wasn't seen as necessary anymore.
> How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?
Not that satisfying an answer, but https://github.com/WebAssembly/design/blob/master/FeatureTes...
A good assumption is that your WebAssembly binary already has an implementation of malloc which calls grow_memory. It should do something sane, and you shouldn't need to worry: it's similar to having mmap fail on other platforms. What do you do when mmap fail? I usually just give up and abort, but in rare cases I'll do other fancy things.
> Are there high-quality polyfills available for older browsers?
Work had started in 2015 for a solid polyfill, but now all major browser vendors have shipped WebAssembly so that work wasn't seen as necessary anymore.
> How is forward-compatibility expected to be handled? Right now there's only WebAssembly with the core feature-set. What happens as some vendors start to add support for varying features such as GC, SIMD, threads, etc.?
Not that satisfying an answer, but https://github.com/WebAssembly/design/blob/master/FeatureTes...
> What's the reasonable thing to do when a grow-memory instruction returns -1?
99% of the time, you proceed to try to write into address (-1) and your process is killed by the supervisor. Despite what many people say, that's a perfectly reasonable thing to do, if you can afford to have your process killed.
The rest of the time, you'll do something very application dependent, like cleaning caches, optimizing for space instead of time, postponing some task, etc.
99% of the time, you proceed to try to write into address (-1) and your process is killed by the supervisor. Despite what many people say, that's a perfectly reasonable thing to do, if you can afford to have your process killed.
The rest of the time, you'll do something very application dependent, like cleaning caches, optimizing for space instead of time, postponing some task, etc.
Once you mentioned "bare minimum of concepts and tooling from which you can build everything" I immediately thought of js module-for-everything situation. We might be getting even more of them written in webassembly.
I suspect that the use cases for WebAssembly will be something like this:
- < 10% user-beneficial compute in the browser
- 60% ad and tracking obfuscation
- 20% annoying scrolling and transitions
- 10% hostile code
- < 10% user-beneficial compute in the browser
- 60% ad and tracking obfuscation
- 20% annoying scrolling and transitions
- 10% hostile code
That's about the breakdown for Javascript too, right?
Probably, but only the first use case needs more performance.
Can't be overstated. Web assembly is going to be a disaster for users in the long run.
The helpless feeling as a bunch of people actively destroy the web for no reason other than that it's more convenient for them is so frustrating.
The helpless feeling as a bunch of people actively destroy the web for no reason other than that it's more convenient for them is so frustrating.
Add DRM to the 60% and I'd agree.
Really interesting paper. When I first heard about what WebAssembly was trying to achieve, I naively wondered why people didn't just slap some existing interpreter for bytecode into browsers (JVM, .NET, maybe even adapt LLVM?) and go with that. I knew people had been burned by Java applets, but I was still curious why they invented something new again instead of possibly adapting existing stuff.
Of course I accepted that they surely had some good reasons for doing it the way they did, but the paper has some interesting specific points in favor of the Webassembly and against existing stuff like the JVM (easier verification of the bytecode etc.).
Of course I accepted that they surely had some good reasons for doing it the way they did, but the paper has some interesting specific points in favor of the Webassembly and against existing stuff like the JVM (easier verification of the bytecode etc.).
My worry is, does this make it easier for the big companies to silo the internet more completely? From a developer POV with regard to performance, this seems great, but from the standpoint of open communication, it seems problematic.
It doesn't make it any easier than minified, obfuscated JS.
Out of curiosity, is there anybody in the last couple of years who would say that reading the source of websites was a significant component of their learning the web? (By "significant", I don't mean "primary" but I do mean more than "I once popped open a bit of source and found a method I didn't know existed".) Even in 1997, I was using free documentation, not reading websites, which even before minification and such were still often quite ugly to read.
I love Webassembly, because It will eventually remove Javascript's dominance from the web for good.
Eich's support is poetic.
This is a brilliant result, make this toy broken language compete
This is probably hand-waving but : instead of implementing threads directly into the WebAssembly language, would it make sense to compile a known micro-kernel to WebAssembly and then compile the C standard library (which, IIRC, implements threads)?
Yes. Let's combine the renowned safety of the C standard library with the speed and efficiency of a web browser!
This wouldn't help at all. Kernels (micro or no) can only implement preemption with the help of hardware timers (and, if you want parallelism, hardware cores), which Webassembly cannot access. (The C library does not implement threads; it merely wraps the kernel's implementation of them.)
So at some level WebAssembly itself must provide some sort of primitive for threading, or else at best you'll get cooperative coroutines/an event loop.
So at some level WebAssembly itself must provide some sort of primitive for threading, or else at best you'll get cooperative coroutines/an event loop.
[deleted]
I'd rather see something like async/await before true threads. So much of web programming is network IO bound; that what we really need are primitives that make async programming easier.
Threads can come later.
The problem is that when async programming is hard due to language or framework difficulties, threads are the easier choice. But then, older code is locked into patterns that are hard to refactor to async/await.
Threads can come later.
The problem is that when async programming is hard due to language or framework difficulties, threads are the easier choice. But then, older code is locked into patterns that are hard to refactor to async/await.
I wonder how this will affect Java in the long term. In the comments about the JDK9 release, there was discussion about the JVM becoming a sort of language-agnostic platform where Java is a small part. It seems WebAssembly is occupying a lot of the same space, but from a sort of opposite direction (in the sense of providing the compilation target first).
Java and the JVM obviously aren't going anywhere soon, but the history of javascript, node.js, etc. leads me to suspect WebAssembly could displace the JVM in the long term.
Java and the JVM obviously aren't going anywhere soon, but the history of javascript, node.js, etc. leads me to suspect WebAssembly could displace the JVM in the long term.
Java is a language. It comes with a standard VM, compile mechanism, and bytecode. Fortunately, the Java platform is well segmented so that the language is a separate technology from those other pieces. Scala, for example, is a language different from Java, but still targets the compile mechanism and JVM.
WebAssembly, by contrast, is not a language. It is only a bytecode and conforming container. Java could compile to WebAssembly instead of its standard bytecode and the biggest difference is execution environment. In order for WebAssembly to displace the JVM it would have to run where the JVM can run with appropriate levels of support.
WebAssembly, by contrast, is not a language. It is only a bytecode and conforming container. Java could compile to WebAssembly instead of its standard bytecode and the biggest difference is execution environment. In order for WebAssembly to displace the JVM it would have to run where the JVM can run with appropriate levels of support.
I was a little unclear about this, but I meant Java in the broad sense of the Java ecosystem, including the JVM and the language. I was mostly wondering if languages will move toward WebAssembly as a target instead of the JVM, and what consequences that will have.
On the other hand, maybe I had Java the language in mind unconsciously at some level. You're right that you could have Java targeting WebAssembly instead of its standard bytecode, which I hadn't thought about.
At least now, it seems like the JVM offers some stuff that WebAssembly doesn't, but I have a hunch it won't stay that way in the long run.
There's been a lot of good discussion here about WebAssembly versus the JVM; it seems like lots of people have similar thoughts about this topic.
On the other hand, maybe I had Java the language in mind unconsciously at some level. You're right that you could have Java targeting WebAssembly instead of its standard bytecode, which I hadn't thought about.
At least now, it seems like the JVM offers some stuff that WebAssembly doesn't, but I have a hunch it won't stay that way in the long run.
There's been a lot of good discussion here about WebAssembly versus the JVM; it seems like lots of people have similar thoughts about this topic.
In many ways, the JVM bytecode is a superset of WASM. That's why I wrote https://github.com/cretz/asmble.
Interesting--this seems forward-thinking and useful.
> nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future.
I did not realize that the design was this ambitious! I wonder how lightweight a standalone implementation could be, while still getting competitive performance.
I did not realize that the design was this ambitious! I wonder how lightweight a standalone implementation could be, while still getting competitive performance.
We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. WebAssembly will finally deliver that and it seems to be done by the same people/organizations. What changed?
>We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible.
Technologically speaking, this has been possible since the days of p-code. The browser vendors have only just decided that it's something that's actually beneficial
Technologically speaking, this has been possible since the days of p-code. The browser vendors have only just decided that it's something that's actually beneficial
It's also been possible since Javascript.
Same organizations, different people, and enough time to experiment with (read: suffer pains from) things like asm.js and PNaCl for those people to agree that something like WebAssembly was a good idea.
It's called the CLR. (Common language runtime, which is what C# runs on.)
The problem is that the CLR forces you into a "one-size-fits-all" garbage collector. It's good for what it does, but if your application needs are different, than the CLR just won't work.
The problem is that the CLR forces you into a "one-size-fits-all" garbage collector. It's good for what it does, but if your application needs are different, than the CLR just won't work.
There are plenty of VMs out there, the JVM and CLR being the biggest two. Up to now though none were usable on the web.
Yet, almost one year after its release, nobody makes money directly or indirectly with wasm... despite the beauty of its engineering, I'm starting to worry. Who will continue funding it if nobody uses it?
Exactly. WASM stories always bring up wild fantasies of platform world domination, when in reality there aren't APIs for even the most basic things, let alone practical apps.
In a heretical way, I've got to ask why not just use JVM byte codes, an incomparably more established platform at this point with several mature VMs and sophisticated API ecosystem, albeit not necessarily in the graphics space? Why did we want to rid browsers of Java in the first place just to start all over with it?
In a heretical way, I've got to ask why not just use JVM byte codes, an incomparably more established platform at this point with several mature VMs and sophisticated API ecosystem, albeit not necessarily in the graphics space? Why did we want to rid browsers of Java in the first place just to start all over with it?
Java doesn't provide a sufficient security model for running arbitrary C/C++-like code, which is the entire purpose of WebAssembly. Drop that and all the new use cases will just go back to asm.js instead.
That's... not Java or the JVM providing the security model. It's impressive but it's not a comparable solution to WebAssembly.
It hasn’t got a big installed base yet[1], so it’s hard to justify the investment. Also, remember that experience with Applets/Flash/Silverlight has burned developers, and probably made them fearful. I expect that once a big player makes a move, momentum will build.
[1]https://caniuse.com/#search=Wasm
[1]https://caniuse.com/#search=Wasm
Figma is using it (though I'm not sure how much money they're making at this point): https://blog.figma.com/webassembly-cut-figmas-load-time-by-3...
Webassembly is incredibly hard to debug in the browser. Source maps give you a decent stack trace, but you can't evaluate variables. I'm hoping this situation improves.
AKA how to bring more advertising and tracking crap to your browser...I really do hope it's not that.
Url changed from https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-s..., which points to this.
acolyer.org's glosses on papers are excellent and I like reading them myself, but sometimes it's a bit of a struggle knowing where to situate them on HN given the original source rule (https://news.ycombinator.com/newsguidelines.html).
Edit: changed my mind. Like I said, a bit of a struggle.
acolyer.org's glosses on papers are excellent and I like reading them myself, but sometimes it's a bit of a struggle knowing where to situate them on HN given the original source rule (https://news.ycombinator.com/newsguidelines.html).
Edit: changed my mind. Like I said, a bit of a struggle.
I think you made a good choice: acolyer.org posts provide enough additional analysis, comparisons to previous posts, and meta-commentary to stand on their own.
JavaScript is so 2015, long live C++
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