I haven’t seen many posts about the new WebAssembly support in Go 1.11, so I decided to try it out and see what it could do. I’ve been having some fun with it, and thought I would share some code to encourage other Go programmers to get started with WebAssembly.
Go is popular for server-side web programming, and now it can also be used in the client.
I wrote it entirely in Go, without writing a single line of JavaScript! (There is JavaScript glue code to get it loaded, and that’s just copied directly from $GOHOME/misc/wasm.)
The README has directions for playing the game. The HTML, CSS, and Go code are commented so you can understand how WebAssembly works. If you want to try making your own WebAssembly app, it can act as a starting point. I also have a simpler example of WebAssembly in Go, which may be a better place to start learning: https://github.com/Yaoir/ClockExample-Go-WebAssembly
I’d like to hear from Mac and iOS users to see if the video poker app works well on Apple products, using Safari, Firefox, Chrome, and Opera. The only problem I’ve seen so far is when using Firefox on an old Android 4.2 tablet. Overall, WebAssembly support seems to work well.
It is working on mac os 10.14.1 (latest) in Chrome, Firefox and Safari. I can test on ios on sunday. Good work The only difference I noticed was that I won more on the Chrome version
Thanks everyone for helping test it! It’s good to know things are working on the Mac. Hopefully it will work as well on iOS.
I tried something different with the JavaScript glue code in the HTML file, but I’m still having the same problem with Firefox on Android. I wonder if the problem is specific to my old Android version, or it is also affecting more recent Android versions.
I’d like some more help with testing that so I can figure out if I need to report it as a bug in Go/wasm or Firefox. (To help out, start up Firefox on Android and run the app, then reload the page. The bug is that the app will never finish loading. Clearing the browser cache fixes it. Sometimes, quickly tapping the reload button many times will also clear it.)
In case there are any experts reading this, the problem is that the JavaScript glue code hangs at the WebAssembly.instantiateStreaming() call.
Maybe you browser cache is playing tricks with you here? You could reference the wasm with a not used query which could be the modified time. For example myprogram.wasm?t=78888776 and then will a new version always be loaded instead of the browser using the cached one. If you can’t automatically change the js file or the HTML file could you instead explicitly change a version in the url. For example myprogram.wasm?version=1.0.1 and change this then ever the wasm is updated.
The following part which will be going to tackle the perception that will manage it and the client side web development that goes along with web assembly so can’t load xpcom it will work in chrome and sometimes stuck a loading.
Since I posted the topic, I’ve learned about this issue with Go’s support for WebAssembly:
The description is a close match to the behavior I’ve observed, so I assume that’s causing the problem.
I recently learned from Christine Dodrill on the Gopher Slack workspace that it’s possible to use TinyGo to produce very small wasm files (kilobytes instead of megabytes) and that the wasm apps run on mobile devices without encountering the “out of memory” error. However, TinyGo is very limited and immature. I tried it with the video poker app, and it would not compile. Anyway, that’s another thing to look into for anyone who wants to explore options.
The only difference I noticed was that I won more on the Chrome version