Go already has a built in router in it's standard library, sure it's more targetted at the server side, but extending to the client side wouldn't be a huge effo

Go already has a built in router in it's standard library, sure it's more targetted at the server side, but extending to the client side wouldn't be a huge effort. With gowasm you don't need a view library, the "view" library is Go, you can choose to use Go's templating if you want, or you could use a more idiomatic Go system of interfaces that implement a view, with different implementations of those interfaces for different components of your single page app. With storage Go offers either client side with HTML5 local storage, or backend with simple map[]s for temporary in memory storage all the way to full blown SQL / NoSQL or even distributed decentralised raft options like tendermint. Go offers a much wider ecosystem for storage (client and server side) than even the best JS offerings. Bundlers / Collections are a red herring in the golang world, golang generally uses monolithic binaries (that tend to be statically compiled where possible) and then use networking to talk between them as a mirror to goroutines and channels internally. golang's package system along with it's tooling (go run vs go build/install) handles "bundling", it's done by the linker / compiler; linking is a well understood problem. Styles is something that golang would never attempt to handle, it's a CSS thing. Sure there will be libraries that 3rd parties will write to interact with style frameworks (like bootstrap et al), but you just as easily handle that in your own view interfaces. golang does have a standard vendoring system, true that not everyone uses it; maybe one day it will converge? And it is very unlikely that go will ever have generics, go has an idiomatic way of handling that with interfaces; probably not everyone's cup of tea, but there it is. You can live without generics. A lot of the way that Go handles these various issues runs against the grain with a sizeable portion of the programming community, there will always be other options. Ask 10 developers get 11 opinions. The biggest takeaway though is that WASM is opening up the browser programming interface to more than just JS and its plethora of libraries / frameworks / solutions.