I'll get started soon.

@hajimehoshi thanks for your great work for gopherjs, may I ask in this context what would you recommend if I'm actively using honnef.co/go/js/dom and honnef.co/go/js/xhr, while keeping in mind possible wasm move in future? Should I stick with these libs or is there any solution which better suits in the wasm space? Maybe some support is planned by honnef.co maintainers?

Hi, I have no idea about these projects. Please ask the owners.

Well it's not about these projects, but generally about your vision of moving towards wasm in the context of this particular adoption keeping in mind that many ppl still (and will) be using other libs as well. Ok your point is clear.

@inliquid I don't wish to speak for @dominikh but in the past he has expressed his intent not to spend anymore time on adapting the existing libraries to webassembly. I think there are alternative efforts to have a syscall/js-based DOM interface such as https://github.com/dennwc/dom. Ideally for the DOM specifically we would generate Go bindings directly from the WebIDL spec like Rust does. @dennwc was doing some work in this area last year sure if that effort is still ongoing. Would you be interested in contributing to this?

Hi @johanbrandhorst! Thank you for detailed comments, I will follow mentioned repo activity and try to contribute when possible.

Will we get another release with this?

I guess GopherJS does not have a 'release' policy. Not sure though.

The release policy is we increment the version number by 1 whenever there's a notable or large change. It's just for convenience, so people can tell if their GopherJS version includes said notable/large change (and we can ask them in bug reports). It's also so we can blog/tweet about a new version being released. See issue #500 for background.

I think adding support for syscall/js warrants bumping the version, if you'd like to do that @hajimehoshi. It would become 1.12-2.

Sure, let me update the version soon :-)