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

Health and future of the GopherJS open source project #894

dmitshur opened this Issue Jan 29, 2019 · 2 comments


None yet
2 participants
Copy link

dmitshur commented Jan 29, 2019

I'd like to open this tracking issue to open a discussion about the future of GopherJS, and the health of the project. The goal here is to try to answer the question: what does the future and roadmap look like for GopherJS? This is something that affects both the users and contributors to the project.

Project Health

Right now, the latest GopherJS 1.11-2 supports Go 1.11.x and works on macOS and Linux. On Windows or other OSes, it requires setting GOOS to one of two supported values, as documented at, and system calls can’t work (which means gopherjs test can’t be used on those platforms). It can be described as functional, but with known limitations.

There are many open issues and PRs that haven’t been fully reviewed and merged. In the last few months, there hasn’t been much activity in that regard. This is indicative of declining health of an open source project.

At this time, there are 4 people with push rights to the main GopherJS repository: @neelance, myself, @hajimehoshi, and @myitcv as of recently (issue #799). To land a PR into master, it needs to go through code review and get a LGTM from at least one other maintainer. Richard has been quite busy working on Go WebAssembly and elsewhere. I have a full time job now, leaving me with less time to spend on GopherJS than before. Hajime and Paul have other commitments too. Being an open source project, we’re all volunteers working in spare time, so the resources we can dedicate to the project are limited.

From my side, I can say that I’m committed to doing my best to keep GopherJS running in its current state: on macOS and Linux, and compatible with the current Go releases (1.11 right now, 1.12 in a few months, 1.13, 1.14, etc.) for the foreseeable future. I can’t spend much more time on fixing the remaining issues and reviewing incoming PRs, at least nowhere near what I’d like.

I think it would be very helpful for contributors to have a better idea of what kind of PRs they can/should send and if it has a chance of being reviewed.

Ways To Proceed

We have a few possible strategies to choose from about what to do next. I will enumerate them below, and make a proposal for a suggested plan of action below. However, if there exists a better option that we haven't thought of, your input will be greatly appreciated.

Option A: Do Nothing

I want to make it clear that this is not a good option. However, this is the default outcome that happens unless we actively work towards one of the other options.

This option is to do nothing and let things keep going as they are. This isn’t great, there are many stale PRs and it’s unclear to contributors if they should spend time creating new PRs, and whether their PR will be properly reviewed and eventually merged or closed.

The outcome of this path is that the health of the open source project will continue to decline and it will be perceived closer to being a dead project.

Option B: Limit Scope, Cull Contributions

This option is to more actively limit the scope of contributions we accept, and communicate this (e.g., in README, a CONTRIBUTING file, etc.). Start closing PRs that are out of scope, since we don’t have the time required to get them reviewed.

This option takes active work and time spent, as PRs need to be triaged and closed, sometimes even when there are valuable changes in them. However, the benefits are that the project health is improved and it becomes easier to make progress. Contributors are saved from spending time on out of scope PRs unnecessarily or kept wondering when their PR will be reviewed.

Option C: Somehow Increase PR Reviewing Resources

This option involves trying to get more help with reviewing existing PRs and getting them merged in. I don’t know how to make this happen. I don’t think we should be sacrificing quality and merging changes that aren’t thoroughly reviewed and tested. Many of the fixes require significant time and effort to investigate and understand how to resolve in the best way.

This option would be great if it were viable, but we need to be realistic and understand it can't happen on its own.

Suggested Plan

From initial discussions with other maintainers, we are currently leaning towards Option B, limiting scope to be more manageable given the resources we have available, cutting down on feature development, but maintaining functionality and support for new Go releases as they come out. We should also do a better job of communicating it so that both contributors and users have a better idea of what to expect.

However, I’d like to invite input from the wider GopherJS community and hear feedback, suggestions for how we should proceed, and what’s best for the future of GopherJS.

From myself and other maintainers, I'd like to thank everyone who has contributed or used GopherJS over the years. I think it's a phenomenal project that has enabled people to build some really interesting things, and allowed us to use Go in more unexpected places! It should continue to work well for many years to come, until there's really no need to keep supporting it.


This comment has been minimized.

Copy link
Member Author

dmitshur commented Jan 29, 2019

Frequently Asked Questions

This comment will be expanded over time to include our answers to various questions that come up.

What is the future/roadmap? How does it compare to WebAssembly?

@dmitshur's answer: The first section of the Future of GopherJS and Go in the browser blog post compares GopherJS to WebAssembly and how they're related.

The current reality is that neither GopherJS, nor Go 1.11+ WebAssembly support are the best in all aspects. WebAssembly support is more actively improving, while GopherJS has already reached a point that's closer to its maximum. In some aspects, GopherJS is currently ahead of WebAssembly, but in other ways, WebAssembly performs better. It depends on the project, the use case, and often requires evaluation.

Most new end projects that are targeting browsers should probably try WebAssembly first, and GopherJS second, if WebAssembly does not produce adequate results.

For libraries that target browser APIs, the best experience for users is to support both GopherJS and WebAssembly. That way packages can be used by bigger audiences, and it's easier to migrate from one to another. The remainder of the aforementioned blog post describes some of the techniques for doing so.

However, there are many existing projects that target GopherJS, and are running in production. We plan to maintain existing GopherJS functionality for the foreseeable future (at least the next few years) so these projects can continue to be compiled with a current Go version.

@dmitshur dmitshur pinned this issue Jan 29, 2019


This comment has been minimized.

Copy link

myitcv commented Feb 20, 2019

Just to build on @dmitshur's initial point:

From initial discussions with other maintainers, we are currently leaning towards Option B

I have a number of changes in my fork at These include:

  • module support (90% done, still need to add better tests around GopherJS as a library - see #855 (comment))
  • extensive test coverage for both GOPATH and module modes
  • tidied up CI scripts
  • a fix for #883

Along with a number of other folks, I'm successfully using this fork and so the changes are relatively stable. And they have the added benefit of the increased test coverage (and new tests can trivially be added

So my intention is to get these changes tidied up and merged into the main fork, i.e. this repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment