wouldn't we still need a custom Transport implementation? If we defined a js,wasm specific client presumably it'd still need to have all the same fields as the normal client.

I think we'll need to think more about this and make some decisions. It's a fact that not all of the standard library functionality can be implemented in browsers, because in general browsers expose relatively high level APIs and not low level ones. As an example, the net package is not supported in browsers (there's no way to do low level TCP/UDP sockets in browsers), so if one tries to compile/run the following Go code in a browser:

conn, err := net.Dial("tcp", "golang.org:80")

It's clear that it can't work. But in what way would it not work? Viable choices are for net.Dial to always return a non-nil error, or the code can fail to compile.

This becomes trickier when you're dealing with a package like net/http, where a part of it should work, but a part of it cannot. We want code like this to work:

resp, err := http.Get("https://example.com/")

But we know the HTTP server can't be implemented inside the browser, so this Go code wouldn't work (either it always returns a non-nil error, or fails to compile because ListenAndServe identifier is missing for js/wasm):

err := http.ListenAndServe(":8080", nil)

The question that comes up is what to do when the Go code tries to use an http.RoundTripper in ways that the browser can't implement (e.g., trying to deal with redirect status code).

I'm more concerned with more code working by default without changes, so I think this is okay to violate for now in Go 1.11. We can revisit in Go 1.12 & later.

I've recently realized an important data point regarding exactly this.

Right now, the net/http package exposes the low-level transport as an interface http.RoundTripper, but the high-level client as a concrete struct http.Client. As a consequence, it's very common to see Go code that overrides some behavior by passing around a pointer to an http.Client with a custom http.RoundTripper that wraps the underlying transport. It's not possible to override the http.Client behavior because it's not an interface (there's no Doer interface).

For example, here's Go code I wrote that works on frontend (via GopherJS) for creating an http.Client that performs authentication with an access token (i.e., it sets the "Authorization" header for each HTTP request):

import "golang.org/x/oauth2"

// httpClient gives an *http.Client for making API requests.
func httpClient() *http.Client {
	accessToken, err := ... // get it from a Cookie, if set
	if err != nil {
		// Non-authenticated client.
		return http.DefaultClient
	}
	// Authenticated client.
	src := oauth2.StaticTokenSource(
		&oauth2.Token{AccessToken: accessToken},
	)
	return oauth2.NewClient(context.Background(), src)
}

It would indeed nice to have code that like continue to work under js/wasm, and it requires being able to override the http.RoundTripper interface (since there's no other choice of an interface to override).

Would it be a good or bad idea to have a Doer interface, allowing such behavior to be implemented without dealing with the http.RoundTripper?