Yes, this difference is on purpose.

The core packages of normal Go in GOROOT are already compiled when you install it, so go build only has to compile the packages in GOPATH and most likely you got all 3rd party libraries with go get, so they are also already compiled. This means that go build has very little to do and is fast.

GopherJS on the other hand has to compile everything. Most users will use gopherjs build a lot for building scripts for their sites. I want this to be fast. In the past I had a warning message that you had to run gopherjs install -all once to make gopherjs build fast, but at some point I decided that this is cumbersome (you have to repeat this every time you update GopherJS), so I simply dropped the -all flag and made go build save package archives to GOPATH for reuse on next go build.

Do you see a downside in this behaviour?

I see now that you try to install the core packages (i.e., from GOROOT). I thought it was installing the actual package you're building too.

This was primarily a problem because of the other issue #60. Once that's fixed, this behavior may be okay as is.

In the past I had a warning message that you had to run gopherjs install -all once to make gopherjs build fast, but at some point I decided that this is cumbersome (you have to repeat this every time you update GopherJS), so I simply dropped the -all flag and made go build save package archives to GOPATH for reuse on next go build.

How do you find out whether the existing files need to be updated (e.g., because of a newer GopherJS version) or can be safely reused instead?

Timestamps. See build.BuildPackage.