syscall/js: Make syscall/js optional when compiling wasm?

[justinclift]

At present, when we compile to wasm syscall/js is automatically included.

This forces the runtime to either be a browser (eg Firefox, Chrome, etc), or at least pretend to be one.

That's kind of non-optimal, as some of the wasm execution environments presently being developed aren't targeted at browser environments. eg:

• https://github.com/Xe/olin
• https://github.com/ewasm/hera
• https://github.com/perlin-network/life
• https://github.com/cervus-v/cervus
• https://github.com/go-interpreter/wagon
• https://github.com/paritytech/wasmi
• https://github.com/nebulet/nebulet
• https://github.com/WAVM/WAVM
• https://github.com/cranestation/wasmtime

In the WebAssembly Gophers Slack channel we have people asking about non-browser use cases fairly often. It seems likely that'll be a fairly standard use case, if it can be catered to as well.

How feasible would it be to have some way to suppress the default syscall/js inclusion, or otherwise make it optional?

[Xe]

I have investigated creating a custom GOOS in the past, but it fails with that attached gnarly linker error. Guidance on it would be helpful, as implementing this would unblock the use of Go for my server side webassembly things.

[sbinet]

Loosely related to #25612 and github.com/go-interpreter/wagon

[peterbourgon]

Little to add except that I also have use cases for Go-to-wasm that don't involve a browser, and I'd be happy to chat about them to anyone interested in the issue.

[bcmills]

CC @neelance @cherrymui

[neelance]

If you don't have syscall/js, then you'd need something else to interact with the environment. Since there currently is no standard API in the WebAssembly ecosystem, I don't see why we should invent yet another API on our own. If such a standard API emerges in the future, I'd be happy to adopt it.

Today, I would implement the backend API of syscall/js as much as needed for the standard libraries, but no further. You don't need to implement full JavaScript for it. Do you see any significant downsides to this approach?

[justinclift]

@Xe @peterbourgon Probably best for you to jump in here. 😄

[Xe]

@neelance for now I have been using https://github.com/CommonWA/cwa-spec as an imaginary system ABI. What calls would we need to add to this for Go? The time call is one of them.

[neelance]

Is there any effort to get https://github.com/CommonWA/cwa-spec adopted by https://github.com/WebAssembly, maybe as an official spec?

[justinclift]

CC @losfair

[peterbourgon]

@neelance

If you don't have syscall/js, then you'd need something else to interact with the environment.

Essentially I want to punt on this question. I want to compile Go down to a WebAssembly module, exporting a set of functions as a sort of public API, and binding to or declaring (somehow) a set of import functions, to consume other modules. I want to load and run this module in a server-side environment, with no relation to JS. CommonWA is not of much interest to me (us) in this context.

[neelance]

@peterbourgon

Would you want to call the functions concurrently or only one at a time?
Which types of parameters and return values do you expect?
Would they do HTTP requests to other services?