Bringing the web up to speed with WebAssembly
blog.acolyer.org
blog.acolyer.org
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
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.
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.
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!
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.
But writing third-party search engines will become even more impossible.
Even Google’s OCR utility can’t reliably detect German Umlaute in fancy fonts.
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.
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.
I am beting once WebAssembly gets mature enough, we will get the revenge of plugins.
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.
Even the apps will use HTML's model via their DOM tree.
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 anyone is interested in the effort they should let me know.
Electron provides all that, but at the very high cost of shipping a complete browser runtime with your app.
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.
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.
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.
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.
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.
But either way, I'd still take "use this object model for host GC interop" over "use this object model or leave the platform."
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.
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.
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...
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.
> 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...
So Flash, again?
METAL is coming.
http://www.retrocomputingtasmania.com/home/projects/burrough...
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.
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.
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.
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'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.
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.
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.
See the design documents: https://github.com/WebAssembly/design/blob/master/Portabilit...
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.
As long as you don't make 1000's of calls per frame it runs pretty well.
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.
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
Is it? How do we know? The attack surface in browsers is huge.
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.
If anyone had actually cared about security on the web we wouldn't be where we are now.
And we already have a bluetooth stack for the web, USB drivers in JS, etc.
To the point that they redefined the URL spec and then complained that cURL didn't fulfill it.
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.?
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.
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.
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...
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.
- < 10% user-beneficial compute in the browser
- 60% ad and tracking obfuscation
- 20% annoying scrolling and transitions
- 10% hostile code
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.
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.).
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.
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.
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.
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.
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.
I did not realize that the design was this ambitious! I wonder how lightweight a standalone implementation could be, while still getting competitive performance.
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
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.
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?
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.