I can't comment on Wails but Vugu is for building front-end code that runs in-browser, written in Go and running via WebAssembly. You can make calls to the backend however you like, it doesn't impose much at all in this regard except as it relates to updating the UI/DOM.
There is nothing in the Vugu project which will prevent proper accessibility standards from being used (as others here have mentioned it will output whatever you ask it to). It's a valid point that examples should include such features where relevant.
This is more or less the exact discussion I had with a co-worker recently on structuring large database-driven projects in Go. It would be interesting to hear how other people have decided to represent their database entities and corresponding relationships in Go.
Yeah, I still need to write a lot more docs and examples (not to mention implement a lot more feature), but the site does have some useful stuff. I'm also making a "playground" and will link to it prominently from the github readme when it's avail.
Yeah the data marshaling is definitely a big topic. For now you have to just http.Get() stuff from the wasm code to an API on a server. No doubt some solutions with a lot less boilerplate would be really handy.
Thanks for the tip, I agree. I'm thinking of making a "playground" also, which would help with quickly showing how it works and allowing people to fiddle with it easily.
I put this together as a prototype of what it would look like if we had something like .vue files that were converted to Go, built to WebAssembly. So far I don't hate it.
It's basically a go-generate-time tool that parses a .vugu file similar to a vue file but the expressions in it are Go code. It spits out a big function that, when run, produces the resulting virtual DOM - with conditionals, loops, etc.
Some tooling helps with this so you can rebuild automatically on page load and so forth, but the above is the basic idea. Curious what people think.