You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the GopherJS playground allows one to import and use the standard Go library and a few select external packages (e.g., github.com/gopherjs/gopherjs/js). I propose we add support so that snippets can import and use all Go packages.
Background
The GopherJS playground today is capable and useful. It serves many different needs for different types of users.
Newcomers to GopherJS can try out simple snippets of Go code and see that it GopherJS actually works.
It is technically impressive - by existing - it conveys the message that GopherJS is written in Go, that it can self-host (compile itself using itself) and is actually useful by being able to run arbitrary snippets of Go code in your browser.
It can help answer the question if a certain piece of Go code is supported and compiles/runs.
It is also useful for people finding and reporting issues in GopherJS compiler, as they can often be reproduced in the playground.
Finally, it's helpful for general sharing of Go code via snippets, not unlike the official Go playground.
Proposal
I propose we expand the usefulness of the GopherJS playground, and also take advantage of its key strength - that the code is compiled and executed in the user's own browser (which is already a protected execution environment) and on their own computer, therefore minimizing the danger of malicious users trying to abuse, overload or exploit remote servers with arbitrary remote code execution. The GopherJS playground can perform some things that the Go playground is unable to, like make XHR requests to remote servers that have CORS enabled via net/http package. See example here.
Here's an example of such a prototype GopherJS playground that I created and tested locally:
The key usefulness of being able to import small 3rd party packages is that when working with local code, you often have various helpers you use for debugging or pretty printing. Whenever you want to share a piece of code, you often end up having to do extra work to factor these out or remove them. By allowing 3rd party packages to be imported, this becomes unnecessary.
Finally, I think it'd be really cool and a cool way to try out Go packages that you don't have locally, as well as test out if various Go packages will work okay with the GopherJS compiler.
Implementation
There are two ways to implement this that I've considered.
Initially, I was going to have a backend server that simply serves Go package source code (in a friendly way). The playground would ask for a Go package via an import path, and it would receive (over HTTP) a build.Package with a build.Context that allows it to be built and used.
Another approach, as I've realized when I started implementing this, is to use GopherJS compiler to compile requested Go packages on the server, and simply serve the output .a.js archive file. The backend server would need to compile the Go packages via GopherJS. No arbitrary user code needs to execute on the backend server, it only needs to be compiled. In this case, the frontend changes are very minimal, as nothing changes except the sources where .a.js archive files are loaded from (previously, it was only statically available ones in the pkg folder).
In both cases the backend server would need to be able to fetch Go packages on demand. I already have much of this functionality done, e.g., it was needed for gotools.org to operate.
Discussion
Primarily, I'm interested in hearing people's thoughts on this. Is this an exciting, desired addition? Or is it unwelcome and unwanted?
I can volunteer to implement and host the backend component to make this possible, as well as frontend changes (of course, I welcome collaboration and help too), if this feature is wanted.
The text was updated successfully, but these errors were encountered:
dmitshur
added a commit
to shurcooL/play
that referenced
this issue
Jun 1, 2015
Abstract
Currently, the GopherJS playground allows one to import and use the standard Go library and a few select external packages (e.g.,
github.com/gopherjs/gopherjs/js
). I propose we add support so that snippets can import and use all Go packages.Background
The GopherJS playground today is capable and useful. It serves many different needs for different types of users.
Proposal
I propose we expand the usefulness of the GopherJS playground, and also take advantage of its key strength - that the code is compiled and executed in the user's own browser (which is already a protected execution environment) and on their own computer, therefore minimizing the danger of malicious users trying to abuse, overload or exploit remote servers with arbitrary remote code execution. The GopherJS playground can perform some things that the Go playground is unable to, like make XHR requests to remote servers that have CORS enabled via
net/http
package. See example here.Here's an example of such a prototype GopherJS playground that I created and tested locally:
The key usefulness of being able to import small 3rd party packages is that when working with local code, you often have various helpers you use for debugging or pretty printing. Whenever you want to share a piece of code, you often end up having to do extra work to factor these out or remove them. By allowing 3rd party packages to be imported, this becomes unnecessary.
Finally, I think it'd be really cool and a cool way to try out Go packages that you don't have locally, as well as test out if various Go packages will work okay with the GopherJS compiler.
Implementation
There are two ways to implement this that I've considered.
Initially, I was going to have a backend server that simply serves Go package source code (in a friendly way). The playground would ask for a Go package via an import path, and it would receive (over HTTP) a
build.Package
with abuild.Context
that allows it to be built and used.Another approach, as I've realized when I started implementing this, is to use GopherJS compiler to compile requested Go packages on the server, and simply serve the output
.a.js
archive file. The backend server would need to compile the Go packages via GopherJS. No arbitrary user code needs to execute on the backend server, it only needs to be compiled. In this case, the frontend changes are very minimal, as nothing changes except the sources where.a.js
archive files are loaded from (previously, it was only statically available ones in thepkg
folder).In both cases the backend server would need to be able to fetch Go packages on demand. I already have much of this functionality done, e.g., it was needed for gotools.org to operate.
Discussion
Primarily, I'm interested in hearing people's thoughts on this. Is this an exciting, desired addition? Or is it unwelcome and unwanted?
I can volunteer to implement and host the backend component to make this possible, as well as frontend changes (of course, I welcome collaboration and help too), if this feature is wanted.
The text was updated successfully, but these errors were encountered: