Sunday, August 19, 2018

Wasm: GoLang vs. .Net

WebAssembly (wasm) is getting ready for its prime time
since all major browsers now have support for it.

Essentially, wasm provides universal "virtual machine"
with small subset of JavaScript commands, that can be provided either as a binary "bytecode" or as a script.
The performance is close to code compiled directly to machine language (i.e. factor of 2).
The security model is same as for JavaScript, meaning as good as it gets for web.
For web browsers that don't natively support wasm, there are "shims" that interpret commands in standard JavaScript, obviously with performance penalty, (i.e. factor of 5).
Wasm is already fast enough even for many action games, that used to be possible only with native apps. And since wasm apps are pure web apps, the distribution is quite optimal.

Except for C and C++ programs (usually games), it is in theory possible to convert programs in any strongly typed  language to wasm, and there are already good examples.

A typical use-case for using languages as Go and C# in web browser
is re-using server based business logic in client side web apps and even SPAs (single page web apps)

Google is actively working on making GoLang run with wasm, and
Microsoft is working on making .NET work on wasm also.
But those two approaches are quite different, and it is interesting to compare.

Latest GoLang compiler (SDK) has option to produce wasm as an "target CPU architecture" with JavaScript as an "OS", all in one step. The resulting code has not dependencies,
but it is relatively large, since not all optimizations are implemented yet.

.NET Blazor project has quite different approach. It takes Mono (.NET) VM compiled in native output (C/C++ like) and converts that to wasm using typical C/C++ toolset (LLVM).
That is obviously relatively large, but it does not change over type. Then, any standard .NET DLL that does not try to directly access OS or HW can run on top of that VM (.NET) on VM (wasm) or VM (JavaScript) setup. The effort now is to enhance integration with web browser (DOM, JS).

Both solutions are "work in progress" and it is too early for conclusions.
Here are a few more details...

For running GoLang in web browsers, there was  already a tool GopherJS for converting Go source code to JavaScript. That does not require or use wasm, and runs Go based code in web browser.
GitHub - gopherjs/gopherjs: A compiler from Go to JavaScript for running Go code in a browser
GopherJS Playground


GopherJS vs WebAssembly for Go - DEV Community 

"The latest Go version 1.11 supports WebAssembly port by Richard Musiol, the same author of GopherJS. Now Go 1.11 is on the way releasing, but you can test WebAssembly APIs with the latest Go by compiling yourself. Your compiled program for WebAssembly is available both on browsers and Node.js. You can use full features of Go including goroutines. You can call any JavaScript functions from Go, and you can pass Go function as a JavaScript callback. The API is defined at syscall/js package. The environment variables for WebAssembly are GOOS=js and GOARCH=wasm"
WebAssembly excursion with Go – Boris Djurdjevic – Medium

BxJS - Compiling Golang to WebAssembly - YouTube


Welcome to the Blazor preview docs website!

GitHub - aspnet/Blazor: Blazor is an experimental .NET web framework using C#/Razor and HTML that runs in the browser with WebAssembly

Online Demo:
https://blazor-demo.github.io