GopherJS user survey results — 2021

It is that time of the year when everyone is reflecting on the achievements of the past and making plans for the future. GopherJS is no exception — this has been an eventful year for us, and the future looks even more interesting (generics?! 🎁).

This year we ran a user survey to help us better understand what our users value the most in GopherJS, and what they wish was available. It was also important to us to evaluate technical decisions, for example whether we can part with our ECMAScript 5 compatibility policy and take advantage of the newer features. It is time for us to share the data we got from the survey, and the decisions we make based on it.

Before we dive in, it is important to say that we’ve received 53 responses (thank you all who took time!). This is enough for us to discern general trends, but we are aware that this is only a small fraction of our userbase.

There are three popular ways to run Go in a browser: GopherJS, Go WebAssembly and TinyGo WebAssembly. We wanted to understand whether there is an overlap between users of these projects. We asked which, if any, of these projects are you using.

Percentage of survey responders who reported using different client-size Go technologies at the same time.

This plot tells us a few important things:

• The results are naturally biased towards GopherJS — this is to be expected, since our users are more likely to respond to our survey.
• Almost half of GopherJS users also use Go WebAssembly.
• TinyGo seems to be less popular among survey responders, but not insignificant. Smaller output size is likely a factor here.
• Among responders who reported not using GopherJS, Go WebAssembly appears to be approximately twice as popular as TinyGo WebAssembly.

Another important thing for us to understand is where our users run their code. JavaScript (for better or worse) can run almost anywhere, but each environment has its own subtle differences, and we need to know where to focus our attention. We also asked the same question to the WebAssembly users in case it reveals unexpected differences, but the picture is quite similar:

Number of responders who reported targeting each runtime environment (multiple selections were allowed).

• Browser is by far the most popular environment. This makes sense: almost anywhere where NodeJS can run, native Go can too.
• NodeJS usage is not insignificant. We would like to know the exact use cases, but we are guessing it might be gopherjs test and special cases like custom GitHub Actions.
• We were really surprised to see React Native appear in two different responses — this is a use case we never though of. But we would like to read a blog post about it one day 😉

Next question we wanted to settle is whether we should stick to our current policy of ECMAScript 5 compatibility for the generated code. In the past this has been an important feature of GopherJS, ensuring that generated code can run in almost every browser. However, recently requests for ECMAScript 2015+ features became more frequent, for example better integration with ES6 modules.

Plot shows number of respondents selected corresponding options to each question. The results only include respondents who reported using GopherJS.

We filtered results of this plot to GopherJS users, since the biggest concern here is breaking compatibility for existing users targeting old browsers. This reduced the number of data points, but is still enough to draw some conclusions:

• Looks like most of our users set their compatibility requirements relative to the browser or NodeJS age, rather than specific ECMAScript versions. Most appear to be targeting at most 5 years old versions.
• There still are folks who need ES5 compatibility. Although there are only a few of them in the survey, this means that when we decide to begin using ES6 features, we need to provide a well-documented path to transpile GopherJS output into ES5.
• Overall, it seems that it is ok for GopherJS to use newer ECMAScript features, as long as they have been supported in popular browsers for 5 years and there is a documented fallback or polyfill for older versions.

Finally, we’ve asked a few open-ended questions to understand what is important to our users. We won’t go into a lot of detail here, and highlight some common trends:

• Output size is by far the most common request for improvement — almost 80% of responders brought it up. This is not a surprise to us — the corresponding GitHub issue is probably one of the longest in our tracker. This isn’t an easy problem to solve, but clearly an important one.
• Support for “embed” package, ES6+ features and in-browser test support are other popular requests each getting around 30% of votes.
• Preference for Go as a language (70%) and ability to share libraries with the backend (60%) are the biggest reasons for people to choose GopherJS. To us it means that code portability between regular Go and GopherJS is important, and we need to keep up with language features the best we can.
• Interacting with native JavaScript libraries is a very common use case. 80% of responders named js field tags the most valuable feature in GopherJS. Questions about using GopherJS output as a ES6 module and importing ES6 modules into GopherJS programs are also frequent occurrences in our issue tracker 🙂
• Quite a lot of folks expressed interest in contributing to the project, but lack of documentation on GopherJS internals is making it hard for them.
• 50% of responders report adopting a new Go release within 6 months and 90% — within a year. So I guess we should get going on Go 1.18 support 😅

We would also like to take a moment and say thank you for all the words of support that you put in the survey! 🙏 Reading them it a massive source of motivation for us to keep moving GopherJS forward.

That’s about it for the survey. It was incredibly useful for us, and we plan to keep it open as an ongoing channel of feedback. Happy holidays and see you next year!

— Nevkontakte and Jonathan Hall on behalf of the GopherJS project.