I see WebAssembly as a platform at the intersection between Native, the Web and what has made the success of Node on server side. The fact that it is a web standard makes it a place where big companies like Google, Oracle or Apple can be involved but can't control everything like with app stores on mobile. For an independant actor like JetBrains, it could matters. I also think we need this kind of common platform for all usages : mobile/web/server/IoT.
I keep thinking about how Kotlin could take advantage of WebAssembly. The "funny" thing is that WebAssembly platform matches with a kind of mix between Kotlin/JS and Kotlin/Native.
It matches with Kotlin/JS because it could be used as a dropin replacement for current JS code generated asap WebAssembly will have GC and Web API exposed.
But if you just use WebAssembly for that you are doing with JS, you get it wrong. WebAssembly is conceptually more close to Kotlin/Native. Look what https://github.com/AssemblyScript/assemblyscript
is doing. They are using a more constraint subset of TypeScript to generate very small and efficient WebAssembly code. If they were just using regular TypeScript they would generate bloated WebAssembly and the interest would be close to 0.
WebAssembly is a native technology of a special kind and the language need to adapt to it, like Kotlin/JVM was originally carefuly crafted for the JVM. Kotlin/WebAssembly if it exists some day would be IMO a mix of Kotlin/JS and Kotlin/Native.
It is close of Kotlin/Native semantics, but it would need to have a Kotlin/Native -> Kotlin IR -> Binaryen toolchain (see https://github.com/WebAssembly/binaryen
). LLVM is not a good fit at all, especially for WebAssembly GC.
The reason why I think it has a huge potential on server-side is that with serverless, microservices, and more generally the fact that workload run in the Cloud, I see a very deep move toward native technologies. GraalVM native images which has been graduated by Oracle as a first class product is a good example, Kotlin/Native, Swift on server side are also other ones.
The GraalVM native images case is pretty interesting. The JVM has been designed to run workload of multiple applications on production, now we see that it consumes too much in the Cloud where JVM are isolated in containers, so we are going to use it only for development, and our JVM bytecode will be translated to native code on the Cloud platform. To me that mainly means that nowadays, we are able to build technologies that allow developers to be efficient to develop complex applications and that can run efficiently, start fast, consume less memory via native runtime.