Remember there are 2 sides to “web” development.
Browser development is of critical importance. JavaScript is the language sites will continue to be built on in 2020, even if a transpiled language is used to produce it. Node.js has never been used in the browser (it’s a runtime, not a language), but it is the dominant runtime in the build tooling space. I doubt we’ll see tools like webpack overtaken by a Go alternative in 2020.
Backend development is a little different. Both Node.js and Go are solid for building API’s, server rendered templates, etc. Node doesn’t hold a huge market share in this space, nor does Go. I think both will continue to see further adoption in 2020. Both are a safe bet.
In my own personal opinion, Go is better suited for building infrastructure components, like proxies, TLS/SSL terminators, gateways. JavaScript is often significantly easier to use when creating API’s where business logic is important, primarily because it is alot easier to handle JSON in such an environment. I regularly build platforms with both technologies.
It is incredibly rare to see a single-runtime/language system these days. Any “____ vs ____” language decisions are almost irrelevant these days, because the “I can only use one language” perspective is incredibly outdated. Plenty of people want a singular language, but desire alone doesn’t mean it’s practical or even advisable.
—
Update (2021)
This answer is still relevant, but I mentioned “doubting tools like webpack will be overtaken by Go alternatives in 2020”. While I wouldn’t say tools like webpack have been completely overtaken, the world is well on its way with significant traction in tools like esbuild.
I’ve been happily using esbuild for quite awhile now, and it makes a significant difference in the pace of development. When the average webpack build takes 42–55 seconds, it is hard to ignore esbuild (which takes 0.37 seconds on average).
There are other tools, like NVM for Windows, which I wrote using Go over 5yrs ago for managing Node.js runtime installations.
Furthermore, some folks use Docker to build their web applications. With Docker (written in Go), it is possible to share a common development environment no matter which operating system a developer uses. This can be a powerful capability for teams.
These types of tools aren’t used in frontend development, i.e. you won’t be using Go to manipulate HTML elements, but they are used to build frontend (and backend) code. In this space, Go is proving formidable.
I think Go will continue to play an increased role in build tooling for the JS community. Go is a little easier to get started with than languages like Rust, C++, and even Java. I wouldn’t be surprised to see more Go-based tooling in JavaScript’s future. I just don’t think we’ll see it in the browser for awhile. Even though Go can be compiled to web assembly, the output is still very large (5+MB). The Go team is working to reduce the size of WASM output, so this may change… but for now, that’s too big to really be used in web apps.