-
-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add WebAssembly support #232
Conversation
It will likely be a few more weeks before I have time to begin working on this again and finish the remaining bits / merge it. |
Looks like the ecosystem is maturing a bit so we're pretty closer to being able to merge this. Notable things that have happened recently:
Remaining work:
No other errors, logs, etc. Unsure why. Doesn't affect other examples. cc @hajimehoshi if you have any ideas, otherwise I'll find more minimal case and file/fix upstream. (Just checkout this branch and |
I don't think the reflect support in TinyGo is good enough: it still doesn't support inspecting structs for example. However, I have been working on a better map implementation which is a prerequisite to |
That's a strange error message I've never seen. I'll take a look later, but now I'm on a business trip, so I cannot guarantee when :-) |
Confirmed the wasmserve issue is actually a bug in WSL not wasmserve: hajimehoshi/wasmserve#5 |
What is the status of this? I think vecty could move to using |
8e15258
to
2592a9d
Compare
.travis.yml
Outdated
- gopherjs test -v ./... | ||
# Test with Go compiler (under amd64 and wasm architectures) and GopherJS compiler. | ||
#- go test -race ./... | ||
- GOOS=js GOARCH=wasm go test -exec="$(go env GOROOT)/misc/wasm/go_js_wasm_exec" ./... # https://github.com/golang/go/wiki/WebAssembly#executing-webassembly-with-nodejs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI there is https://github.com/agnivade/wasmbrowsertest which allows you to test against a browser.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat, I can see why that'd be useful -- though one of our goals with Vecty is to make go test
alone (even without GOOS=js) work (initially just for testing Vecty itself, secondarily/not in this PR in projects using Vecty)
example/README.md
Outdated
|
||
- Go 1.12+ WebAssembly support | ||
- [GopherJS](https://github.com/gopherjs/gopherjs) (Go to JavaScript transpiler) | ||
- [TinyGo](https://github.com/tinygo-org/tinygo) WebAssembly support (produces tiny binaries, but with tradeoffs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😬 is this right? TinyGo doesn't support all of reflect
yet. Have you tested it with TinyGo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I haven't updated this file yet & TinyGo most likely doesn't work. Will fix.
Codecov Report
@@ Coverage Diff @@
## master #232 +/- ##
==========================================
+ Coverage 57.64% 59.41% +1.77%
==========================================
Files 3 4 +1
Lines 654 653 -1
==========================================
+ Hits 377 388 +11
+ Misses 219 208 -11
+ Partials 58 57 -1
Continue to review full report at Codecov.
|
Using blackfriday v2 with GopherJS and WebAssembly is not currently easily possible because with Go modules v2 must be imported as: ``` github.com/russross/blackfriday/v2 ``` But `gopherjs serve` cannot use that versioned import path, since it is not module-ware ([open issue](gopherjs/gopherjs#855)). So we end up stuck in a catch-22: Go 1.12 WebAssembly can't build `gopkg.in/russross/blackfriday.v2` anymore (import path must be suffixed with `/v2`) and GopherJS cannot build `github.com/russross/blackfriday/v2`. Initially I just tried downgrading to blackfriday v1 at `github.com/russross/blackfriday` but unfortunately that appears to have a different problem where module-aware builders like Go 1.12 are forced to use v2 but non-module-aware work fine, I suspect due to the `go.mod` comitted to that repo currently. This works for now, and the long term fix is GopherJS getting module-aware building.
Note that we still use a mock JS implementation for purposes of testing because syscall/js does not provide any such facilities today.
In some such as `TestRenderBody_RenderSkipper_Skip` it is not logically apparent to me how these ever passed on master before this, because the panic would have always led to RAF never being called unless `renderComponent` called RAF?
- run tests with GOOS=js GOARCH=wasm. - upgrade to go 1.12 - do not test with -v flag - use gofumpt/gofumports
Good news! It's finally time for this to be merged: Vecty now has WebAssembly support! 😃 🎉
|
Update Go Package Store to be compatible with Vecty API after vecty.RenderBody became blocking as part of hexops/vecty#232. Use the new non-blocking vecty.RenderInto instead, which was created as part of the solution described in hexops/vecty#247. Updates hexops/vecty#232. Updates hexops/vecty#247.
Prior to this PR, Vecty was only usable with GopherJS which would compile Go to JS code.
After this PR, Vecty can be used with:
All examples in the
example
directory work under both GopherJS and WebAssembly, and a README is added to describe how to compile for each.TinyGo future support
In the future, Vecty will automatically gain support for TinyGo once it supports the subset of reflection and
syscall/js
that we make use of.See tinygo-org/tinygo#93 for more discussion around this.
Prior work
Supersedes the prior PR for this by using build tags instead of exposing a
gopherwasm
API directly. See #215 (comment) for discussion around this.Fixes #211