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.
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.
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.
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.
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.
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.
I think WebAssembly frameworks are the next step in the evolution of web ui. I don't think React / Vue / Angular are likely to be unseated by another JavaScript framework, as everyone is mostly satisfied with at least one of the 3. A new framework needs to offer significant advantages to justify the switch, and WebAssembly can do this with better performance and better languages. It's exciting to watch the first experimental releases of these new frameworks!
Not just web. There are a lot of efforts getting WebAssembly to run outside the browser. This could be an alternative to Electron for cross platform desktop applications.
Depending on use case, WebAssembly might even be an alternative to Java on servers. Go already supports cross platform compilations, so the use case for Go on WebAssembly on a server isn't as obvious. At least, not for those of us who value simplicity or performance. On the other hand, most of us didn't see Javascript on servers coming either, so I wouldn't rule it out.
This is absolutely fascinating. I think the world has come a full circle! While HTML5 and Javascript are great tools, I remember how back in the day you had a wide choice of which language you wanted to use to build an app. The world would be a much better place if that kind of choice were to become available again and this project gives me hope that we are headed in that direction.
I'm intrigued by this as I've been teaching myself some Go recently (to see if I could get over my initial distaste for it).
I've been enjoying the process, so this subject interests me but I'm running into a long series of errors when starting the tutorial dev server.
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:23:16: undefined: js.Func
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:28:15: undefined: js.FuncOf
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:107:34: js.Global().Get("document").Truthy undefined (type js.Value has no field or method Truthy)
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:152:19: mountParentEl.Truthy undefined (type js.Value has no field or method Truthy)
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:165:16: mountChild1.Truthy undefined (type js.Value has no field or method Truthy)
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:309:8: n.Truthy undefined (type js.Value has no field or method Truthy)
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:680:8: el.Truthy undefined (type js.Value has no field or method Truthy)
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:759:19: oldKeyJSVal.Truthy undefined (type js.Value has no field or method Truthy)
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:810:7: v.Truthy undefined (type js.Value has no field or method Truthy)
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:813:51: firstChild.Truthy undefined (type js.Value has no field or method Truthy)
github.com/vugu/vugu@v0.0.0-20190329041623-36c2913f3f3c/env-js.go:813:51: too many errors
I'm on Go 1.11.5. I'll try updating and see if it will work then.
edit: Updatd to 1.12—no dice. Many of the errors did go the way of the buffalo, but a couple remain:
2019/03/29 11:08:37 Error from compile: exit status 2 (out path="/var/folders/lp/d1rds9q57wqdmgchmzjjrh3hfsm71q/T/main_wasm_237110380"); Output:
# example.com/test/testapp
./root.go:11:13: undefined: RotData
./root.go:37:30: data.Toggle undefined (type *RootData has no field or method Toggle)
./root.go:47:8: data.Toggle undefined (type *RootData has no field or method Toggle)
I didn't try it yet, but it looks very promising and I hope I will be able to use C# or F# for client side programming, because it's hard to master a new JS framework every 3 months or so and I already have JS fatigue.
Webassembly seems like the solution that could bring all communities together.
Imagine i could use a C++ library, to use with a Rust UI library. All in the same runtime environments.
This could be the dream.
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.
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.