4 ms·

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

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.

rolleiflex 8y ago
This is cool. I have an app that uses Vue and Go (in Electron, communicating via gRPC) and this looks like this could make it a lot simpler. You should consider adding a small bridge so you can run the resulting code in a native app box (i.e an Electron bridge), that would be a winner combination.
kej 8y ago
This is cool, it's kind of like Blazor [0] in the .Net world although I bet the resulting code is a lot smaller. If I can make a suggestion, though, the "root.vugu" code snippet from step 3 on the Getting Started page should be one of the first things in README.md and on the vugu.org page. It gets the core idea across right away, just like the code editor at the top of golang.org quickly shows what the language is like. [0] https://blazor.net/ https://blazor.net/
- bradpeabody 8y ago
  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.
biomcgary 8y ago
I hope this takes off. If I had an example of how to use Vugu with gRPC that doesn't need a proxy or intermediate conversion to JSON, I would adopt my new project to this in a heartbeat. It would make CRUD so easy. You could almost generate everything from a single proto file.
- bradpeabody 8y ago
  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.

rolleiflex 8y ago

This is cool. I have an app that uses Vue and Go (in Electron, communicating via gRPC) and this looks like this could make it a lot simpler. You should consider adding a small bridge so you can run the resulting code in a native app box (i.e an Electron bridge), that would be a winner combination.

kej 8y ago

This is cool, it's kind of like Blazor [0] in the .Net world although I bet the resulting code is a lot smaller. If I can make a suggestion, though, the "root.vugu" code snippet from step 3 on the Getting Started page should be one of the first things in README.md and on the vugu.org page. It gets the core idea across right away, just like the code editor at the top of golang.org quickly shows what the language is like. [0] https://blazor.net/ https://blazor.net/

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

biomcgary 8y ago

I hope this takes off. If I had an example of how to use Vugu with gRPC that doesn't need a proxy or intermediate conversion to JSON, I would adopt my new project to this in a heartbeat. It would make CRUD so easy. You could almost generate everything from a single proto file.

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