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.

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 https://github.com/myitcv/gopherjs. These include:

• module support (90% done, still need to add better tests around GopherJS as a library - see module-aware building #855 (comment))
• extensive test coverage for both GOPATH and module modes
• tidied up CI scripts
• a fix for bug: nil variable definition causes compiler panic #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 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.

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:

If you don't see the request, then maybe add [email protected] manually?

See https://github.com/goplusjs/gopherjs for recent go version support.

I also felt like I needed to reply to this point, as I honestly disagree. There were clearly people with enough drive, expertise, and time to continue maintaining GopherJS, such as #894 (comment).

I'm not familiar with the politics over the last three years, but it seems to me like the problem boils down to the project simply refusing to transition to new maintainers. Which is fine if you really want to just end a project for good. But it's dishonest to say that it had to happen because the project could not find adequate maintainers.

From my end there are no politics at all. I don't have the time to maintain this project any more, that's all. You linked @myitcv in your comment. He already has write access to this repository. He could have stepped up to the primary maintainer role at any time, but he did not. And this is fine. As far as I know he also does not have the time to be the primary maintainer.

We have a lot of people who like the project, but who don't want to be the primary maintainer. So what is the way forward in this situation?

@mvdan Just give me someone who says in this thread "I want to be the primary maintainer of GopherJS and will spend the time necessary to keep it in a good shape" and I'll happily try to make the transition happen. Don't just send out accusations.

To be clear, I did not mean my comment above as an accusation or any form of personal attack. I completely understand if neither of you wants to spend more time on GopherJS, and respect that.

You linked @myitcv in your comment. He already has write access to this repository.

I can't speak for him so I'll just let him give his point of view if he wishes to :)

Just give me someone who says in this thread "I want to be the primary maintainer of GopherJS and will spend the time necessary to keep it in a good shape" and I'll happily try to make the transition happen.

If I might give some constructive feedback, that feels like a high bar to set. I understand that GopherJS is a complex project, but I think it's ultimately not going to survive as a project if it requires someone to commit to dedicating an amount of ongoing effort that nears an indefinite full-time position.

A small group of people who contribute, review, and garden when they have availability is not quite the same, but it's still better than an archived project. I also imagine it would be easier to encourage others to step up to that kind of a role.

So what is the way forward in this situation?

To continue with the above, I think a clear path for developers to gain access to the repository would help. Essentially, option C from the original post. It says:

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.

I think the intent there is good, but the outcome is that the project is stuck in a deadlock. There aren't existing active maintainers and there's a large backlog, but one can always start somewhere. "Don't let perfect be the enemy of the good" - option C wants a perfect solution, but I argue for the "good": admit that, with new maintainers and without the existing ones, the quality might temporarily suffer. And that's fine, because that's almost always going to be better than an archived project in the long run :)

A small group of people who contribute, review, and garden when they have availability is not quite the same, but it's still better than an archived project. I also imagine it would be easier to encourage others to step up to that kind of a role.

If it works, then that's fine with me. I believe this still needs someone who is the "head" of this group. Would you be willing to fill this position? You seem motivated enough. :)

There really needs to be a "head" for this. If there isn't, then certain decisions, responsibilities, etc. will just fall back to me or @dmitshur. I can not just give write access to everyone and hope for the best. I do not believe that this would work and therefore I do feel that this would not be "right" for the project. If no head can be found, then I only see the freeze as an option.

I am willing to take on the "head" role, as long as that doesn't require being the primary code contributor.

I think ideally one person would do both, but if we're going to migrate to more of a "governance by committee" model, then that's probably less important.

Maybe it would make sense to determine how much interest still exists in this project. Maybe the enthusiasm I sensed from before has completely died, in which case this conversation could be a waste of time.

If there are still people interested, though, we could schedule a discussion (possibly async, possibly via Slack/Zoom) to discuss how to organize, and come to an agreement on how to move forward.

@neelance:

Just give me someone who says in this thread "I want to be the primary maintainer of GopherJS and will spend the time necessary to keep it in a good shape" and I'll happily try to make the transition happen.

@flimzy:

I am willing to take on the "head" role

As a used-to-be-interested observer / user, I think that's as good as y'all are going to get. (And, just to be clear, I think it's pretty good.)

Don't get stuck in paralysis by analysis. Turn over the reins and move on. If the maintainers here don't or can't adequately serve the community of users, some other fork will get nominated by default and acclimation. Or maybe it won't and the entire project will die. But better a clear transition than a prolonged limbo.

@theclapp I agree with what you are saying. What still bothers me a bit is that it seems like it is not clear that if this transition does not work well enough, then it is me who is still on the hook. People will complain to me that the project is still in limbo. I do not want that and I believe that this is my decision to make. Sure, I could simply ignore the project and all complaints in my direction entirely, but I don't think that this is what anybody wants.

@flimzy I've given you full access. Go ahead! :)

@flimzy Thank you for stepping up.

we could schedule a discussion (possibly async, possibly via Slack/Zoom) to discuss how to organize, and come to an agreement on how to move forward.

I haven't had a chance to chime on this thread because it's a busy week for me, but please include me in that meeting.

I've seen this exact situation happen with several projects recently and it never makes sense to me why, if there's so much interest in continuing development, the people who are interested don't just fork the project and continue on merrily? Why do people covet GitHub repos so much? If you can prove your fork has a good history of fixing bugs and stuff actually works, then maybe that should be the condition to give over the maintainer badge on the old repo.

Why do people covet GitHub repos so much?

Because it's not about the GitHub repo. In the same way that it's not about owning the facebook.com or ebay.com domain name. What matters is the existing community, and discoverability. Someone might fork gopherjs (or facebook, or ebay, etc) and even have a 100x better version tomorrow. But if the community doesn't know about it, and they're going to the old location instead, it doesn't matter.

Just my thoughts:

• The cost of changing the primary repository is non-zero and responsible community members want to minimize that, if possible.
• If there are several forks and one of them is not a clear favorite, that could be a problem.
• Just forking a project and ignoring the founder's wishes can be seen as hostile, and especially if you've built up a rapport with said founder, or the community has such a rapport, you want to minimize that, if possible.

These are all hurdles, not insurmountable obstacles. But hurdles can still trip you and sometimes that's enough to make you say "eh, fuck it".

I have created a public Google Doc, where those interested in volunteering to help maintain this project may indicate their interest: https://docs.google.com/document/d/1QwKCO2LJdSmkrCmWB6VCS626Dy41lhCBM-_lV2x4FdA/edit?usp=sharing

Let's see what kind of response we get. Then we can decide on next steps, possibly including a real-time meeting.

I am too interested in keeping GopherJS active and up to date, and, like many other folks, I don't have enough time to achieve this on my own. Over the past few months I've been experimenting with ways to simplify GopherJS codebase so that less upstream features have to be reimplemented from scratch. I can't boast great achievements in this area yet, but if my ideas work out I'll be happy to contribute them to whichever fork is active.

At this stage I am, unfortunately, no longer comfortable using GopherJS for any kind of mission-critical projects (read: at work), but I hope this might change, and I'd like to help. I've added myself to @flimzy's doc.

cc @visualfc in case you are interested

He already has write access to this repository

This access was granted on 12 Nov 2018. I originally opened #799 in Apr 2018, around the time I was granted further access to the Go project (golang/go#24596).

The conversation in #855 is relevant here FWIW.

As a brief point of history. I started seriously using GopherJS in Oct 2016 when I created some React bindings (that were then used in Camlistore in 2017). I properly started interacting with the GopherJS project in ~March 2017. Indeed I arranged a session to go through major outstanding issues with Richard and Dmitri in Apr 2017.

In early 2018 I exchanged messages with Dmitri, expressing my frustration that things weren't moving forward quickly enough (not a complaint directed at an individual, more a reflection on the state of the project). Out of courtesy I contacted Dmitri to let him know I'd be creating a fork organisation, the name of which might have been gopherjsnext. Dmitri asked me to hold off creating this organisation until he had had time to write an issue about the future of GopherJS. We had a follow up conversation in July 2018: that is the conversation referenced in #855 (comment). After that session it was concluded that I would work in a fork (because of Dmitri and Richard's decision to sunset the project), merging all of my changes that were still open in the main repo, along with initial module support following in Aug 2018.

Therefore as of July 2018 the official position was: nobody new will be added to maintain the project, and GopherJS would be sunset (save for Go 1.11 support that Dmitri was working on).

So whilst it is true that I was subsequently given access to the repository, hopefully it's understandable why my enthusiasm and energy levels had wained by that point.

Why do people covet GitHub repos so much?

@flimzy and @theclapp are spot on here with their answers: #894 (comment) #894 (comment)

What still bothers me a bit is that it seems like it is not clear that if this transition does not work well enough, then it is me who is still on the hook. People will complain to me that the project is still in limbo

My issue here is that we haven't really tried a transition. So we are in this position by default.

I can not just give write access to everyone and hope for the best

Nobody is suggesting you should do this. Nor does it mean however that you need to go to the other extreme of not handing over the reins to anyone (although I should point out that it remains your and Dmitri's prerogative). Hopefully you can see, however, doing nothing leaves us in a state of paralysis. Furthermore, it ignores the efforts that folks other than myself (@hajimehoshi, @flimzy and @theclapp to mention three people in particular) have made towards the project.

That more people are not directly involved as (lead) maintainers project is broadly a function of two things: the existence of such people and their willingness/ability/etc (although I would argue someone's ability is something that should be encouraged and nurtured so this should not be a blocker), and your decision (as project owners) as to whether and when to grant them access and handover in a meaningful way.

In my opinion, there are a number of people who have, over the years, shown sufficient willing and ability to take this project forward.

I totally understand your and Dmitri's desire to remain "close" to this excellent project that you have worked extremely hard towards, and nurtured from the beginning. Those efforts are greatly appreciated. These sorts of transitions (assuming that's what you want) are hard. But I think it's important to recognise there have been opportunities in the past to address this.

we could schedule a discussion (possibly async, possibly via Slack/Zoom) to discuss how to organize, and come to an agreement on how to move forward.

Unfortunately I no longer have the time to be involved with GopherJS. But I wish those who take the project forward every success.

Sure, I could simply ignore the project and all complaints in my direction entirely,

I thought this was one of the valid options: I'd make this project archived and notify the people to see the other forked projects if I were you.

Sure, I could simply ignore the project and all complaints in my direction entirely,

I thought this was one of the valid options: I'd make this project archived and notify the people to see the other forked projects if I were you.

I was talking about doing nothing at all, which includes not freezing/archiving the project.

There are too many words in this thread and not enough action. A transition needs both, "push" and "pull". The "pull" side means "I am now doing X unless you stop me to". Don't wait for my approval, don't wait for @dmitshur's approval, just do it and show that it is good.

I am not and was never opposed to any transition, as long as the new maintainer is not as inactive as I am. In fact, there was already a transition from me to @dmitshur and it worked well for a while. Now his priorities also shifted and we need another transition. This is what I am trying to do. Honestly it really does not feel nice that it sounds like I am against some transition. Sure, there may not have been much "push" from my end, but this is exactly the point. I don't want to spend much time on it any more. So there needs to be enough "pull".

There is a community of active GopherJS users. This community does not include @dmitshur and me any more. We are still happy to help occasionally if requested, but otherwise we just want to see it evolve nicely without our involvement. So now you, the remaining GopherJS community, need to decide what you want and how you will make it happen.

To prove my point: I did encourage new maintainers even before this recent discussion:

@nevkontakte I haven't talked to @dmitshur yet, but would you be open to being a maintainer of this project? You seem to be invested in GopherJS and I appreciate your code review.

#964 (comment)

I'd love for @visualfc to get write access (if he agrees). He's put in so much unrewarded hard-work.

The "pull" side means "I am now doing X unless you stop me to". Don't wait for my approval, don't wait for @dmitshur's approval, just do it and show that it is good.

Sorry, but I disagree this is a course of action that someone who wants to contribute to a project should have to take. The "I'm going to create a fork" ultimatum, should not be necessary.

That said, at the beginning of 2018 I looked to take this course of action, and out of courtesy notified Dmitri of my intentions. Others have also created forks.

What we are talking about here is how, for the reasons @flimzy and @theclapp laid out above, the changes in such forks can be incorporated back into the project for the benefit of everyone, and active owners/maintainers can take the project forward.

I've already laid out above how I believe a number of people have shown serious commitment and intent towards the project since 2017. Whether that be helping with issue gardening, creating PRs, working on large new features (@nevkontakte, @visualfc and others). To my mind it's unreasonable to consider the only way for progress to be made with GopherJS is to fork and then present an ultimatum to the project owners - that's not in the spirit of open source.

In fact, there was already a transition from me to @dmitshur and it worked well for a while. ... Honestly it really does not feel nice that it sounds like I am against some transition.

My comments were directed at the project owners/lead maintainers. Since my involvement with the project, I had understood that to be both you, @neelance, and @dmitshur. It sounds like that is not the case.

Just to be clear, how long has @dmitshur been the primary maintainer? And when this transition happened, I presume you transferred all decision making?

Sure, there may not have been much "push" from my end, but this is exactly the point. I don't want to spend much time on it any more. So there needs to be enough "pull".

That anyone (including you personally) may want to step back is of course fine. Knowing now that you handed over completely to Dmitri at some point in the past makes that even clearer - that transition indeed worked well (notwithstanding the apparent confusion on who the primary maintainers/owners are/were).

But I don't agree with your conclusion that the reason things haven't transitioned again (or worked well since) is because there hasn't been enough "pull". As I said above, there have been a number of people who have demonstrated more than enough interest, ability and enthusiasm.

We are still happy to help occasionally if requested, but otherwise we just want to see it evolve nicely without our involvement

This is a welcomed. A useful step to my mind would be clarifying who the primary owners and maintainers now are. That's not to say those individuals will act without reference to others, but it should be clear that they have the authority to act. I would also encourage whoever does take up this role going forward to continue to seek out new people to help run the project: look to make yourself redundant from day 1 (in the best possible way).

To my mind it's unreasonable to consider the only way for progress to be made with GopherJS is to fork and then present an ultimatum to the project owners - that's not in the spirit of open source.

I never said "only way" and I never said "ultimatum". Please don't exaggerate what I am saying. I am just saying that if a fork runs well for a while, then everyone can clearly see that it runs well. This might have helped with some decision making. Sure, it is not the best way forward, but it is one that involves more concrete action instead of words.

Just to be clear, how long has @dmitshur been the primary maintainer? And when this transition happened, I presume you transferred all decision making?

Honestly I am not fully sure. I think the initial transition was somewhat fluent. According to my Slack history in April 2018 I said to him "You are the primary maintainer of the project right now, so I'm okay with whatever you decide." 🤷‍♂️

But I don't agree with your conclusion that the reason things haven't transitioned again (or worked well since) is because there hasn't been enough "pull". As I said above, there have been a number of people who have demonstrated more than enough interest, ability and enthusiasm.

That's possible. I did not follow it closely enough (not primary maintainer). I only got involved now (and somewhat took back control) because the voices got loud enough and I am a bit annoyed that the project is still in limbo.

This is a welcomed. A useful step to my mind would be clarifying who the primary owners and maintainers now are. That's not to say those individuals will act without reference to others, but it should be clear that they have the authority to act. I would also encourage whoever does take up this role going forward to continue to seek out new people to help run the project: look to make yourself redundant from day 1 (in the best possible way).

I have given @flimzy full access, because he asked for it first. This "authority" was not given to him in particular, it was just to make myself "redundant". I am fine with whatever government model you decide to use.

I don't think the "primary maintainer" role was ever assigned in the past. It was effectively determined in retrospect through action. Looking at https://github.com/gopherjs/gopherjs/graphs/contributors you can see that Richard was the primary maintainer since 2013 to about 2017. I was most active between 2016-2018. Whenever I was unsure about a big decision, I asked for Richard's opinion, but otherwise I gained autonomy by acting, learning from mistakes and fixing them. I sent many PRs that went through code review before being granted push rights (I was fortunate that the maintainer at the time had bandwidth to review my PRs). I admit did not do as good a job of onboarding new people as I could've, especially at the time when my personal life became so busy that I stopped having enough bandwidth to do it effectively, but it wasn't due to a lack of caring or trying on my part.

Any PR can be merged as long as it's in scope and gets a +2 from one of the maintainers. This was communicated to me by Richard when he added me to the project (I forget when exactly, but around 2015-2016), and I communicated this to Hajime and Paul when onboarding them.

It was a mistake not to write this down somewhere for other people to see. I've tried to correct that now by documenting the effective guidelines for merging PRs on the Developer Guidelines wiki page, see https://github.com/gopherjs/gopherjs/wiki/Developer-Guidelines#guidelines-for-merging-prs. As I noted there, those guidelines are what this project has used to get to this point, and they might change as part of the work being done in this issue.

To be clear: I fully trust Jonathan (@flimzy)'s judgement and he should feel comfortable making changes as part of improving the process. I trust he will ask me (or anyone else in that list of people with +2 access to the project) if he feels he needs to, or will not ask and just do it otherwise.

I think successfully onboarding new people to lead a project needs to be done at a time when both the new and previous contributors have bandwidth to communicate and make forward progress (I was unfortunately not successful at this in the past). I'm trying to make time to assist Jonathan and make this as successful as possible. I've said it before but I will repeat it, thank you @flimzy for stepping up and helping. I think you're doing a great job already.

Hi GopherJS community,

After a period of inactivity the GopherJS project is resuming development with @flimzy and @nevkontakte assuming the role of coordinators. We would like to thank @dmitshur, @neelance and all former contributors for their work that got GopherJS as far as it currently is, and we respect their desire to step away from the helm.

Looking forward, there is a lot of catching up to do. The latest Go version GopherJS supported is 1.12, meanwhile the Go Team just announced Go 1.16 release. A lot of new features have been added to the Go language, standard library and build tooling, which GopherJS needs to implement as well. Even more changes are on the horizon (generics and GOPATH deprecation being the most notable ones). And, of course, there are plenty of GopherJS-specific problems to address: ECMAScript 6 support, reducing output size, cleanups, documentation improvements, etc.

We will be honest and admit that the time the two of us currently have is probably not enough to deliver all of that as quickly as it needs to be. So here's our call for help and invitation to participate: we will focus on maintaining the existing core functionality and making it easier for the community to contribute the missing bits. If there is a particular feature you'd like to have, open an issue and we'll do our best to suggest the best way to implement it. If you want to help, but not sure how, come chat with us in the #gopherjs channel in the Gophers Slack, and we'll give you pointers 🙂

Finally, here are the things that we want to get done as soon as possible (and welcome help with):

1. GopherJS can be built with Go 1.16 and supports Go 1.16 standard library, with the exception of Go Modules and File embedding (see Go 1.16 standard library support #989).
2. GopherJS can build projects that use Go Modules, i.e. outside of GOPATH (see module-aware building #855).
3. Fully support file embeddings and the embed package.

Cheers,
@flimzy and @nevkontakte.