Vugu: Experimental library for web UIs written in Go and targeting WebAssembly | Hacker News Reader

Vugu: Experimental library for web UIs written in Go and targeting WebAssembly

github.com

95 pointsbradpeabody25 comments

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. 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.

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/

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 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.

> No node_modules folder competing with your music library for disk space.

Love it already

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

Have any insight?

What version of Go are you using? It sounds like an older one. Try the latest (1.12.x).

The syscall/js API is still in development and undergoing API changes. It’s not stable like the rest of Go’s standard library.

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'll take a wild guess and say there might be a typo on the word _RotData_

Appears that way. `root.go` is a file generated by the framework. Thought passing the errors along would be of some value...

Another option to consider is Blazor:

https://blazor.net/

https://www.youtube.com/watch?v=0RfUPr0KrSM&t=836s

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.

JS framework battle has been settled from a while. React has won and I dont see that changing soon. Vue and Angular are fighting for second place.

That is regional. Here on the office battle takes place between Angular, Vue and vanilla JS.

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.

Just like I use a C++ library with a C#, VB, F#, JS, Python, Component Pascal, Eiffel.... UI library....

Some demos would be great

It seems their website at http://www.vugu.org is a demo as it contains some of those vg attributes in the source code.

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.

13MB [1] for a static site (vugu.org)?

[1]: http://www.vugu.org/main.wasm

Yup. That's part of the "experimental" experience. :) (Although that wasm file should be gzipped, will double check what's up with that). More info on the size of Go's wasm binaries here: https://github.com/golang/go/wiki/WebAssembly#reducing-the-s...

The doc site is a prototype and proof-of-concept using Vugu. First attempt, just wrote it last week. Lots of optimizations still needed for sure.

Reply on news.ycombinator.com