Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Health and future of the GopherJS open source project #894
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.
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 https://github.com/gopherjs/gopherjs#installation-and-usage, and system calls can’t work (which means
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
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.
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.
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?
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.
Just to build on @dmitshur's initial point:
I have a number of changes in my fork at https://github.com/myitcv/gopherjs. These include:
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 https://github.com/myitcv/gopherjs/tree/master/testdata)
So my intention is to get these changes tidied up and merged into the main fork, i.e. this repo.