Skip to content
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

Merged
merged 38 commits into from Jul 1, 2019
Merged

Add WebAssembly support #232

merged 38 commits into from Jul 1, 2019

Conversation

slimsag
Copy link
Member

@slimsag slimsag commented Jan 21, 2019

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:

  • GopherJS (browser, testing)
  • Go + WebAssembly (browser, testing)
  • Go + Native (for testing Vecty itself, autocomplete in editors etc)

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

@slimsag
Copy link
Member Author

slimsag commented Jan 21, 2019

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.

@slimsag
Copy link
Member Author

slimsag commented May 13, 2019

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:

  • Go 1.12 has been released, so we don't need to advise installing Go tip anymore.
  • TinyGo now has support for all reflection APIs we need.
  • GopherJS has added syscall/js support (thanks to @hajimehoshi) so we no longer need to use gopherwasm in examples and can unify our DOM implementations between GopherJS/WASM.

Remaining work:

(index):4 GET http://localhost:8080/main.wasm net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)

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 cd example/markdown && wasmserve if you are keen to reproduce)

@aykevl
Copy link

aykevl commented May 13, 2019

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 js.FuncOf support so there is still progress.

@hajimehoshi
Copy link

wasmserve has a bug only affecting example/markdown where it returns:

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 :-)

@slimsag
Copy link
Member Author

slimsag commented May 26, 2019

Confirmed the wasmserve issue is actually a bug in WSL not wasmserve: hajimehoshi/wasmserve#5

@johanbrandhorst
Copy link

What is the status of this? I think vecty could move to using syscall/js for both WebAssembly and GopherJS now that GopherJS has syscall/js too. What do you think?

@slimsag slimsag force-pushed the wasm branch 2 times, most recently from 8e15258 to 2592a9d Compare June 30, 2019 03:25
.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

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.

Copy link
Member Author

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)


- 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)

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?

Copy link
Member Author

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.

example/go.mod Outdated Show resolved Hide resolved
@codecov-io
Copy link

codecov-io commented Jul 1, 2019

Codecov Report

Merging #232 into master will increase coverage by 1.77%.
The diff coverage is 57.89%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
markup.go 70.96% <ø> (ø) ⬆️
dom_native.go 53.84% <53.84%> (ø)
dom.go 57.45% <60%> (+2.16%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 216758a...9cf66b5. Read the comment docs.

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?
@slimsag slimsag changed the title [WIP] Add WebAssembly support Add WebAssembly support Jul 1, 2019
@slimsag
Copy link
Member Author

slimsag commented Jul 1, 2019

Good news! It's finally time for this to be merged: Vecty now has WebAssembly support! 😃 🎉

  • Consult the new README for details on bundle sizes, etc. (hello world is surprisingly small!)
  • Consult the updated PR description for details on supported build targets (WebAssembly, GopherJS, native, TinyGo, etc).
  • Consult the new example/README.md for details on building examples for WebAssembly.
  • Consult the CHANGELOG for exact details on the API breakage here.

@slimsag slimsag merged commit 875bd2c into master Jul 1, 2019
@slimsag slimsag deleted the wasm branch July 1, 2019 08:22
dmitshur added a commit to shurcooL/Go-Package-Store that referenced this pull request Feb 2, 2020
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

WebAssembly support
5 participants