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.