-
Notifications
You must be signed in to change notification settings - Fork 17.8k
WebAssembly
Go 1.11 added an experimental port to WebAssembly. Go 1.12 has improved some parts of it, with further improvements expected in Go 1.13.
WebAssembly is described on its home page as:
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.
If you’re new to WebAssembly read the Getting Started section, watch some of the Go WebAssembly talks, then take a look at the Further examples below.
This page assumes a functional Go 1.11 or newer installation. For troubleshooting, see the Install Troubleshooting page.
To compile a basic Go package for the web:
package main
import "fmt"
func main() {
fmt.Println("Hello, WebAssembly!")
}
Set GOOS=js
and GOARCH=wasm
environment variables to compile
for WebAssembly:
$ GOOS=js GOARCH=wasm go build -o main.wasm
That will build the package and produce an executable WebAssembly module file named main.wasm. The .wasm file extension will make it easier to serve it over HTTP with the correct Content-Type header later on.
To execute main.wasm in a browser, we’ll also need a JavaScript support file, and a HTML page to connect everything together.
Copy the JavaScript support file:
$ cp "$(go env GOROOT)/misc/wasm/wasm_exec.js" .
Create an index.html
file:
<html>
<head>
<meta charset="utf-8">
<script src="wasm_exec.js"></script>
<script>
const go = new Go();
WebAssembly.instantiateStreaming(fetch("main.wasm"), go.importObject).then((result) => {
go.run(result.instance);
});
</script>
</head>
<body></body>
</html>
If your browser doesn’t yet support WebAssembly.instantiateStreaming
,
you can use a polyfill.
Then serve the three files (index.html
, wasm_exec.js
, and
main.wasm
) from a web server. For example, with
goexec
:
$ goexec 'http.ListenAndServe(":8080", http.FileServer(http.Dir(".")))'
Or use your own basic HTTP server command.
Note: for the goexec
command to work on Unix-like systems, you must add the path environment variable for Go to your shell’s profile
. Go’s getting started guide explains this:
> Add /usr/local/go/bin to the PATH environment variable. You can do this by adding this line to your /etc/profile (for a system-wide installation) or $HOME/.profile:
export PATH=$PATH:/usr/local/go/bin
Note: changes made to a profile file may not apply until the next time you log into your computer
Finally, navigate to http://localhost:8080/index.html, open the
JavaScript debug console, and you should see the output. You can
modify the program, rebuild main.wasm
, and refresh to see new
output.
It’s possible to execute compiled WebAssembly modules using Node.js rather than a browser, which can be useful for testing and automation.
With Node installed and in your PATH
, set the -exec
flag to the
location of go_js_wasm_exec
when you execute go run
or go test
.
By default, go_js_wasm_exec
is in the misc/wasm
directory of your
Go installation.
$ GOOS=js GOARCH=wasm go run -exec="$(go env GOROOT)/misc/wasm/go_js_wasm_exec" .
Hello, WebAssembly!
$ GOOS=js GOARCH=wasm go test -exec="$(go env GOROOT)/misc/wasm/go_js_wasm_exec"
PASS
ok example.org/my/pkg 0.800s
Adding go_js_wasm_exec
to your PATH
will allow go run
and go test
to work for js/wasm
without having to manually provide the -exec
flag each time:
$ export PATH="$PATH:$(go env GOROOT)/misc/wasm"
$ GOOS=js GOARCH=wasm go run .
Hello, WebAssembly!
$ GOOS=js GOARCH=wasm go test
PASS
ok example.org/my/pkg 0.800s
Also:
-
An experimental new framework Vugu is worth trying out, if you’re looking for something like VueJS. 😄
-
vue - The progressive framework for WebAssembly applications.
-
A library for streamlining DOM manipulation is in development.
-
There is a binding generator that can be used.
-
A new canvas drawing library - seems pretty efficient.
You can use the net/http library to make HTTP requests from Go, and they will be converted to fetch calls. However, there isn’t a direct mapping between the fetch options and the http client options. To achieve this, we have some special header values that are recognized as fetch options. They are -
-
js.fetch:mode
: An option to the Fetch API mode setting. Valid values are: "cors", "no-cors", "same-origin", navigate". The default is "same-origin". -
js.fetch:credentials
: An option to the Fetch API credentials setting. Valid values are: "omit", "same-origin", "include". The default is "same-origin". -
js.fetch:redirect
: An option to the Fetch API redirect setting. Valid values are: "follow", "error", "manual". The default is "follow".
So as an example, if we want to set the mode as "cors" while making a request, it will be something like:
req, err := http.NewRequest("GET", "http://localhost:8080", nil)
req.Header.Add("js.fetch:mode", "cors")
if err != nil {
fmt.Println(err)
return
}
resp, err := http.DefaultClient.Do(req)
if err != nil {
fmt.Println(err)
return
}
defer resp.Body.Close()
// handle the response
Please feel free to subscribe to #26769 for more context and possibly newer information.
-
Configuring GoLand and Intellij Ultimate for WebAssembly - Shows the exact steps needed for getting Wasm working in GoLand and Intellij Ultimate
If you run a newer version of Chrome there is a flag (chrome://flags/#enable-webassembly-baseline
) to enable Liftoff, their new compiler, which should significantly improve load times. Further info here.
WebAssembly doesn’t yet have any support for debuggers, so you’ll
need to use the good 'ol println()
approach for now to display
output on the JavaScript console.
An official WebAssembly Debugging Subgroup has been created to address this, with some initial investigation and proposals under way:
Please get involved and help drive this if you’re interested in the Debugger side of things. 😄
WebAssembly Code Explorer is useful for visualising the structure of a WebAssembly file.
-
Clicking on a hex value to the left will highlight the section it is part of, and the corresponding text representation on the right
-
Clicking a line on the right will highlight the hex byte representations for it on the left
Go releases prior to 1.11.2 have a bug which can generate incorrect wasm code in some (rare) circumstances.
If your Go code compiles to wasm without problem, but produces an error like this when run in the browser:
CompileError: wasm validation error: at offset 1269295: type mismatch: expression has type i64 but expected f64
Then you’re probably hitting this error.
The solution is to upgrade to Go 1.11.2 or later.
-
Shimmer - Image transformation in wasm using Go
-
GoWasm Experiments - Demonstrates working code for several common call types
-
bumpy - Uses the 2d canvas, and a 2d physics engine. Click around on the screen to create objects then watch as gravity takes hold!
-
-
WASM port of an experimental Gameboy Color emulator. The matching blog post contains some interesting technical insights.
-
-
Basic triangle (source code) - Creates a basic triangle in WebGL
-
Rotating cube (source code) - Creates a rotating cube in WebGL
-
Splashy (source code) - Click around on the screen to generate paint…
At present, Go generates large Wasm files, with the smallest possible size being around ~2MB. If your Go code imports libraries, this file size can increase dramatically. 10MB+ is common.
There are two main ways (for now) to reduce this file size:
-
Manually compress the .wasm file.
-
Using
gz
compression reduces the ~2MB (minimum file size) example WASM file down to around 500kB. It may be better to use Zopfli to do the gzip compression, as it gives better results thangzip --best
, however it does take much longer to run. -
Using Brotli for compression, the file sizes are markedly better than both Zopfli and
gzip --best
, and compression time is somwhere inbetween the two, too.
-
Examples from @johanbrandhorst
Example 1
Size | Command | Compression time |
---|---|---|
|
(uncompressed size) |
N/A |
|
|
53.6s |
|
|
3m 2.6s |
|
|
2.5s |
|
|
0.8s |
Example 2
Size | Command | Compression time |
---|---|---|
|
(uncompressed size) |
N/A |
|
|
5.7s |
|
|
16.2s |
|
|
0.2s |
|
|
0.2s |
Use something like https://github.com/lpar/gzipped to automatically serve compressed files with correct headers, when available.
2. Use TinyGo to generate the Wasm file instead.
TinyGo supports a subset of the Go language targeted for embedded devices, and has a WebAssembly output target.
While it does have limitations (not yet a full Go implementation), it is still fairly capable and the generated Wasm files are… tiny. ~10kB isn’t unusual. The "Hello world" example is 575 bytes. If you gz -6
that, it drops down to 408 bytes. 😉
This project is also very actively developed, so its capabilities are expanding out quickly. See https://tinygo.org/webassembly/webassembly/ for more information on using WebAssembly with TinyGo.
-
Awesome-Wasm - An extensive list of further Wasm resources. Not Go specific.