2 ms·

I fail to see how Go would help to solve the lack of complexity. You would still need a package manager. You would still need a view library (React), a router

I fail to see how Go would help to solve the lack of complexity. You would still need a package manager. You would still need a view library (React), a router (react-router) and some sort of model or storage (Redux). React originally took a mix-and-match approach, but other popular frameworks like AngularJS and vue.js tried to bundle everything together. You might also need a style library (not necessarily bootstrap nowadays) or create your own styles from scratch. And you will need an bundler like Webpack or Browserify, unless you want to make your own with Gulp/Grunt (like people used to do). You may want a collections utility library such as Lodash or Ramda, though many people go without them nowadays. Let's so how go would fare here: There's a new view framework (Vecty) which could eventually grow to bundle its own router, standard components and store (just like the more mature Angular and Vue). Store, Router, UI components and Styles: MIA? There are at least 6 widespread competing package management mechanisms: go get, vendored dependencies, godep, Glide, dep and vgo. Hopefully the community will standardize on something (vgo?), but for now, npm and yarn look absolutely fabulous compared to the mess we have to deal with in Go. Bundler - could possibly be obviated by WebAssembly, but we would need something else that matches what's currently being offered by Webpack (e.g. live reload). Collection utilities: Fear not! The lack of generic makes it impossible to do with Go, so you'll just have to write boilerplate code. (The reasoning that a language with a good standard library can obviate the need for Lodash is correct though) --- My point is that you'll just be getting the same thing again and there is no guarantee you will have a more consolidated standard with Go. The Go community rarely tends to unite around a single solution, unless it's coming from Google. If you are looking for a language that gives you a single story and a bundled set of tools for doing everything above, there's already one: Elm. And it's been here for quite a while, and still most frontend developers chose Javascript and React, even while they imported Elm's reducer-based data flow model to React (as Redux).

tankenmate 8y ago
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.

tankenmate 8y ago

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.