Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Health and future of the GopherJS open source project #894
Comments
Frequently Asked QuestionsThis 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. |
|
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. |
|
I'm totally fine with @myitcv . I was wondering when we decide the way to go. The last update was already 4 months ago... |
|
@hajimehoshi I've summarised the one remaining "blocker" to upstreaming the module support at myitcv#42 |
|
@myitcv As you probably would have guessed, the most important to me (i.e. for Perkeep) is that GopherJS keeps on working with the next releases of Go. And also that module support gets added, so that if a user should choose to, they could completely blow up our vendor dir and still be able to fully build Perkeep with GO111MODULE on. That is, until we switch to WASM (or something else), if we ever do. So I hope your plan works out. |
|
I'm most wishing for Go 1.12 support, GO111MODULE support, and for the call signature for gopherjs/build to change as little as possible, as I have scripts directly importing it. |
And vendor in a compatible GopherJS version (bd77b112433e999447bf4bc599e36214ba494a99). In addition, since GopherJS: 1) Still does not support Go modules for now 2) Seems to be dying (gopherjs/gopherjs#894) 3) Has been hard to maintain for Perkeep we decided to gradually move away from it, and to remove it from go.mod. As a result, in this PR, we repurposed the skipGopherJS option into buildWebUI, which, in combination with the GO111MODULE env value gives the 4 following possible behaviours (GO111MODULE=auto omitted on purpose). 1) GO111MODULE=off, -buildWebUI=true: -old behaviour, i.e. use vendored in gopherjs to rebuild (gophejs itself and then) the web UI 2) GO111MODULE=off, -buildWebUI=false: -fetch the JS code for the web UI and the publisher from the Google Cloud bucket of the Perkeep project. That code was previously built by the scenario 1) and uploaded there. 3) GO111MODULE=on, -buildWebUI=false: -same as 2) 4) GO111MODULE=on, -buildWebUI=true: -forces GO111MODULE=off behind the scenes when rebuilding GopherJS and the web UI code with it. Finally, we also modified the checks regarding where we are (i.e. whether in $GOPATH/src/perkeep.org). Because even though go modules will in theory allow to build from anywhere, since we disable modules when the Web UI is rebuilt, we can therefore only do it from within the GOPATH. Change-Id: Iee66d7ee882c6d408b5996fd26178bcd7426e3f8
|
I don't know if the maintainers are aware, but last year I created a gopherJS 'stack' entry on StackShare. I wasn't aware at the time that I would be tagged as the owner of the project there when doing this -- while it adds good visibility to the project, I hope the real maintainers could take ownership. Please contact me to arrange for that to happen. I placed a note giving proper credit and a link as soon as I'd realized what happened. I love gopherjs and I hope it doesn't die. It was available before WebAssembly target was an option, it's wonderful to use and it's good to keep competing implementations the web alive. I think it's a really great thing. Thank you. |
|
@Russtopia Did you get my request on StackShare? |
|
Hi, I just got back from out of town; I don't seem to see any notification or message there. Where should I look? |
|
@neelance Hello, haven't heard anything on the stackshare.io thing for a while. I asked them how you might have messaged me and they say they have no notification mechanism -- so if you want me to take action on that 'stack' on their site please let me know perhaps via other means. Thanks. |
|
I've tried again: |
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 https://github.com/gopherjs/gopherjs#installation-and-usage, and system calls can’t work (which means
gopherjs testcan’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.