runtime: implement timers, JavaScript callbacks back into WebAssembly

[bradfitz]

After some discussion last week with @cherrymui, @rsc, @aclements, et al, we decided that users would be really sad if Go 1.11 was released with WebAssembly support and then realized they couldn't really use it in a browser well, without working timers & callbacks back into Go.

@cherrymui did a little prototype of callbacks and it was enough to show a demo of a Go webassembly program updating images in the DOM and responding to button clicks.

So we decided it was worth spending a bit of time and making sure the wasm support is what users will expect for Go 1.11.

@neelance, what's your availability look like to finish that in the next month or two?

I see you updated your branch (https://github.com/neelance/go/commits/wasm-wip) 3 days ago with neelance@773eb46

Do you need any help? @cherrymui and perhaps @aclements could help if needed.

Please use this issue number in any related CLs. Thanks!

[gopherbot]

Change https://golang.org/cl/114197 mentions this issue: runtime, sycall/js: add support for callbacks from JavaScript

[neelance]

Thanks for offering the help! Callbacks are already working quite well. I just cleaned up the commit some more and pushed the CL for initial feedback/review: https://go-review.googlesource.com/c/go/+/114197

Do we also want to use this to get support for http.Transport into this release? There is already a POC at https://github.com/johanbrandhorst/fetch.

[bradfitz]

An http.DefaultTransport value implementing http.RoundTripper I assume? SGTM for Go 1.11. Let's do it.

If the author wants to send it via a PR or CL I can review. (PRs get converted into Gerrit these days)

[dmitshur]

I'm happy to offer help with implementing and/or reviewing here as well.

I'm the author of the original Fetch API-based http.RoundTripper implementation in GopherJS that https://github.com/johanbrandhorst/fetch is based on, so I'm very familiar with how it works.

I've reached out to @johanbrandhorst and I'll coordinate next steps (regarding http.DefaultTransport) with him.

[johanbrandhorst]

@shurcooL I'll try and get something in as soon as I can. I'm thinking we should implement the XHR transport as well and maybe make that the default as even among browsers that support WASM, they don't all support Fetch out of the box.

[neelance]

fetch can be polyfilled and services like https://polyfill.io/ make it trivially easy to do so efficiently. I nowadays always prefer the newer (stable) APIs + polyfills.

[bradfitz]

@neelance, in general I agree with that, but note that we want Go WebAssembly to work for users without the users needing to write or deal with any JavaScript. So unless that polyfill is part of some Go JS library, I'd rather we just fall back to an XHR RoundTripper if fetch is unavailable.

[neelance]

@bradfitz This is a slippery slope. What about all the ES6 features that wasm_exec.js is using?

[neelance]

For example fetch is supported by older browsers than async/await.

[bradfitz]

@johanbrandhorst, @neelance, which browsers support WebAssembly & the ES6 features we're depending on but do NOT support Fetch?

If zero, then obviously we don't need XHR support.

https://caniuse.com/#feat=fetch suggests everything supports Fetch that already supports wasm.

[neelance]

Oh yes, working on WebAssembly such much made me take it for granted. ;-) Yes, it looks like all browsers that support WebAssembly also support Fetch. No XHR needed.