Deprecate and remove GopherJS support from Vecty

[slimsag]

History

In Sep 2018 we added WebAssembly support to Vecty in addition to the current GopherJS support. At the time, Go's WebAssembly compilation target (and specifically, syscall/js) were very new and had a number of issues surrounding callbacks and other things that had not yet been worked out.

Originally, supporting both GopherJS and WebAssembly made since because GopherJS was more stable and polished but was difficult because they had separate JS interfaces. GopherJS then gained syscall/js API compatibility gopherjs/gopherjs#908 which reduced the burden on Vecty to support multiple JS interfaces.

A bit about me

I am one lone developer working on Vecty and, while I know and have worked with multiple people in the GopherJS community personally, I am not speaking on behalf of the GopherJS community - I am merely speaking on behalf of myself as a consumer of GopherJS and maintainer of Vecty.

My intent is not to downplay the significance of GopherJS, the accomplishments of people who have worked on it, or anything like that. My sole goal here is to improve the pace at which Vecty can be developed.

The state of GopherJS

In the two years since, Go's native WebAssembly support has gained great momentum and its syscall/js interface has generally become much more stable. WebAssembly is Vecty's preferred compilation target today. GopherJS has seen less time investment from maintainers and the community (my personal belief as a user of it only), is looking for more support and generally I would say has a less certain future.

The state of Vecty + GopherJS

Today, Vecty fully supports three compilation targets:

1. GopherJS
2. Go + WebAssembly
3. Go + native architectures (for testing only).

Supporting GopherJS has been painful because of a few reasons:

• Its support of syscall/js has often lagged behind the official Go version (sometimes by quite a lot).
• Its lack of support for Go modules has been painful to test and has led to a number of ugly hacks in e.g. Vecty example projects that we've had to workaround and has been a recurring source of failures in our CI pipeline.
• Keeping documentation up-to-date and answering user questions relating to GopherJS takes a non-trivial amount of time that could otherwise go to developing Vecty.

Deprecating and removing GopherJS support from Vecty officially

This means that;

• We will only test and support Go + WebAssembly support.
• GopherJS may still be able to compile your Vecty application, but it may also not be able to if it lags behind the official Go compiler too much.
• If you encounter issues using Vecty with GopherJS, we cannot help/assist and will advise using Go's WebAssembly support instead.
• If you have an application which compiles using GopherJS only today, you will need to update it to use WebAssembly or target the v0.5.0 tag of Vecty, which is the last version officially supporting GopherJS at that time.
• Bundle sizes will be larger (comparison) until we can support TinyGo as a compilation target.

When?

This will happen immediately today as the time I have available to spend working on Vecty is quite limited. I could wait for input, but it would mean that this change may not go through for several more months and TinyGo support and a few other things would be delayed further.

Feedback

I am very open to feedback here, my intent is to push development of Vecty further along and if I find a lot of opposition to this change (I anticipate I won't, but I am open to being surprised) I will definitely reconsider the change. Please don't hold back your thoughts/feedback!