the promise of Java and .NET that was never quite realized?
This very informative podcast interview suggest that it could,
both in web browsers, as well as on web servers running on NodeJS.
WebAssembly Future with Steve Klabnik - Software Engineering Daily
WebAssembly Engineering with Ben Smith and Thomas Nattestad - Software Engineering Daily
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)
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
No comments:
Post a Comment