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 https://github.com/gopherjs/gopherjs/pull/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:
GopherJS
Go + WebAssembly
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).
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.
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!
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/jsAPI compatibility https://github.com/gopherjs/gopherjs/pull/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/jsinterface 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:
Supporting GopherJS has been painful because of a few reasons:
syscall/jshas often lagged behind the official Go version (sometimes by quite a lot).Deprecating and removing GopherJS support from Vecty officially
This means that;
v0.5.0tag of Vecty, which is the last version officially supporting GopherJS at that time.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!