-
Notifications
You must be signed in to change notification settings - Fork 43
WebAssembly #33
Comments
the standard golang WASM uses a ton of ram. I have been using tinyGO that has WAMS support. Tinygo is amazing... Really should try it. Also i was thinking that running the golang WASM code inside WebWorkers is a smart way to go, so that the GUI thread is freed up. Anything you built you would want to be that way. This would allow people to build HTML GUI apps with shenzen and have all the logic inside the Webworkers doing whatever pipelines are needed. The GUI would be updated based on the results of any computation. i would consider using a dependency on CommLink also to abstract it a little. But it might be overkill too. Commlink handles the aspects of communication between the Window and the Webworkers. |
For now I'm more concerned that GopherJS might become unusable - e.g. gopherjs/gopherjs#855 means that to rebuild the client one can't be doing things the module way. It's another command that needs to be installed locally, but Go WASM has the benefit of being built into Go. TinyGo is promising. I think some Go features are in use that TinyGo isn't supporting yet, so we'll see. |
A few days ago I started experimenting in the wasm branch. After many minor code fixes, it compiles and runs up to the point of displaying a graph. Sadly UI interaction is broken after that point; the client crashes inside github.com/johanbrandhorst/protobuf which is still based on GopherJS. From a very quick look, Johan's packages don't look too difficult to port to syscall/js... |
Good thing I didn't keep going down that path, because of course github.com/johanbrandhorst/grpcweb-wasm-example exists already. |
The bulk of the UI is still built with GopherJS.
The WebAssembly compiler might be ready.
The text was updated successfully, but these errors were encountered: