It's not possible. As soon as WebAssembly gets as big as the web, someone will implement a browser-embedded browser in WebAssembly that runs in the browser and we will be back to square 1 in this kafkaesque nightmare we call Web.

Like running the Windows version of Gimp in Wine in X Window in Chrome inside Firefox on a Mac? http://imgur.com/a/wRals

From: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Lol. Can't wait for this piece of art to arrive, plus compile JavaScript web apps could compile to binaries

Down votes are unfair, this was quite funny.

Why would you think that it is a joke? It is true and how things have always gone!

When I got into computers it would have been ridiculous to imagine carrying around a computer running a different OS in a virtual machine, within which we were running a virtual network of small virtual machines existed to run programs written in a scripting language that itself runs in a VM!

Sounds crazy, right? And yet it isn't rare to find a developer on a Mac laptop running Linux in VirtualBox, inside of which they run Docker containers to run applications built on node.js. This is not done as a joke, it is done because it is a useful development environment for an application that is supposed to eventually be deployed to a cloud.

Portable software has been a motivating dream of our industry since forever. It was a selling point of COBOL, Pascal, HTML, Java, Flash, JQuery, and so on and so forth. The idea of deploying a known client target to get rid of browser differences is inevitable. It is just a question of who will be the first to do one that is good and fast enough to get mindshare.

Honestly, it's going to be huge, imo. And like all good tech, can be used for good and evil :)

We want the best experience for users and devs that we can deliver.

The question is: Why?

Multi-platform makes sense client-side, where you have to deploy to Windows/Mac/Linux/FreeBSD/Android/iOS on x86 and ARM.

You know your server arch. You know your server OS. As long as you don't use C or C++ (or you're carful to be multiplatform), all switching is a recompile away.

Using the same platform for everything has advantages, e.g. code sharing between client/desktop/mobile/server, mastering 1 standard library as opposed to several, seamless serialisation of data between platforms. From what I've gleaned from the docs so far, WebAssembly is very well designed and more pleasant to target than LLVM. Having a single compiler ensures that the code behaves the same on each platform.

If you are asking why I think it may happen rather than why it would be a good idea: imagine that you are a compiler writer for language X. You can target WebAssembly and run the language not only on the web, but also cross platform on servers and desktops and potentially mobile, and you even get a cross platform standard library including networking, UI (DOM/HTML), OpenGL, and more. This will save a tremendous amount of work compared to targeting LLVM separately and implementing your own cross platform libraries (which requires expertise on each platform that the compiler writer is unlikely to have). It's like targeting the JVM but lower level (compiler writers like this) and runs seamlessly on the web like JS.

Browser WebAssembly implementations will compile really fast because it has to be loaded and compiled for use on websites, making it suitable for a really fast compiler for interactive development and REPL, while it will be possible to compile to fast code via LLVM.

> As long as you don't use C or C++ (or you're carful to be multiplatform), all switching is a recompile away.

why do you say "as long as you don't use C or C++" ? these two languages are especially good when it comes to compile a single code base to multiple platforms. Got a 150kloc C++ app that "just compiles" to windows, mac, linux, android, iOS, under x86, x86_64, ARM, and it even worked on PPC macs last time I tried.

Because you have to be careful to be multiplatform. For example, your code can break if you assume an int is 4 bytes when in your target it's 8 (hard coded values for pointer arithmetic), or vice versa.

well, I and scores of other programmers must be quite lucky because I don't ever remember having to assume or leverage the fact that int or whatever data type was 4 or 8 bytes.

But the reality of production systems is much more complex than this. Many medium- to large-production systems are written in multiple languages across large and diverse teams, have legacy components, varied open source components, and so on, all talking to each other. Sometimes this is as simple as sending messages around, but sometimes not. C is usually the lingua franca since it's the common denominator on most systems. Maybe WASM will end up in a place to better serve that role?

You don't want to go bankrupt running a server side hls encoder when you can run it in the browser and simply punt the playlist chunks up to a simple s3 bucket directly from the client running ffmpeg in the browser say for a live broadcasting web app.

You don't always know youer server arch and OS. If you sell solutions to others they may choose the server OS and you might want to support as many as possible.

>WebAssembly could become the universal cross platform low level VM.

You know, people tried to do the same thing countless times already, there is Java and it tries to do exactly that. We all know where Java's promise "to run everywhere" went.

There are JVMs for things beginning from microcontrollers to s390, but find one that can flawlessly run code that was compiled for a VM that is even one major releases old.

Serious software in Java usually comes with something saying "version 2 of this software runs on JVM 'A' 1.4.13 with patchset 'B' 1.2, classpath 'C' 1.5, and exact VM setting from supplied jvm.conf".

The JVM is also massively more complex than WebAssembly. It defines its own object model, its own memory management system, its own enormous standard library.

WebAssembly is how these things should have been done from the start. Leave the object model, memory management, and libraries to the languages built on top, where they can be changed without affecting the backwards compatibility story of the VM itself.

WebAssembly is unlikely to have this issue because it has to run on the web and browsers don't want to break backwards compatibility. Even with these issues the JVM has actually been quite successful as a language platform.

The edge cases they cited seem to run counter to this expectation:

"At this point, we want to issue a special thank you to the WebAssembly teams at Mozilla and Google, especially Alon Zakai, for being so helpful. We did run into a few edge cases but with their help we were able to still make it happen and even improved the Emscripten tool chain a bit along the way."

If some percentage of realistic projects run into edge cases that are incompatible with either the spec or between browsers, it violates the whole "write once run anywhere" goal.

WebAssembly is in its infancy.

> WebAssembly is in its infancy

Exactly.

Expectations that WebAssembly will be more cross-platform than any previous attempt at cross-platform are probably overly optimistic at this point.

Though I'm hopeful, as well.

These failures are why the runtime ships with executable code within .NET Core, Golang and Rust.