A funny thing about GopherJS that took me a while to figure out: struct data is actually stored in what is technically a runtime representation of a pointer-to-struct type, and the struct object itself almost never exists

You'd say, but wait, no way it works without structs, surely they do exist and are represented by a plain old JavaScript object. Well, sort of. In reality, there is a pointer to a struct type that is represented by a JavaScript object. So when you write something like this:

type S struct { f int }
s := S{} // ← non-pointer type!
ptr := &s
reflect.TypeOf(s)

...it translates into something similar to:

var S = $newType(...., function() { this.f = 0 })
var s = new S.ptr()  // ← actually uses pointer constructor!
var ptr = s; // ← noop, it's already kind of a pointer.
reflect.TypeOf(new S(s))  // ← adds a wrapper with the correct type information when interfaces get involved.

This is counter-intuitive, but also makes sense because JavaScript's pass-by-reference semantics for objects is a lot like a pointer in Go, and GopherJS actually has to take extra steps to emulate value type semantics on top of it.

#golang #gopherjs