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.
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?
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.
So Flash, again?
METAL is coming.
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.
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.
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.
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.
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.
