Vugu: Vue-like frontends in pure Go, HTML, and CSS

https://www.vugu.org/

by kodah • 5 years ago

142 31 5 years ago

vugu.org

winrid2• 5 years ago

Do the templates have compile time type checking?

vanderZwan• 5 years ago

While reading the FAQ I stumbled upon a likely answer to your question:

Why doesn't Vugu use Go templates (html/template)?
Short answer: Because templates do not provide type safety or other compile-time checks.

[0] https://www.vugu.org/faq#stability

winrid2• 5 years ago

Thanks

spicybright3• 5 years ago

Do they have another type safe template engine then?

open-paren• 5 years ago

Previously discussed when the project was a few months old: https://news.ycombinator.com/item?id=20449427

mgerullis2• 5 years ago

The hamburger menu does not work for me on Chrome iOS... also there seems to be an overflow issue.

IggleSniggle3• 5 years ago

Also does not work in Firefox iOS or Safari iOS, which I suppose is mostly the same thing.

Also does not work in macOS Safari. Also does not work in macOS Firefox, or macOS Chrome.

Methinks the hamburger menu simply doesn’t work at all!

kodah• 5 years ago

I tested it on desktop chrome while imitating a mobile device and it doesn't work there either.

johnisgood2• 5 years ago

Hmm, last update was on 2020-09-13. :/

awb• 5 years ago

Last commit was 7 days ago: https://github.com/vugu/vugu

johnisgood2• 5 years ago

In any case, this is amazing. I love both Go and Vue! I am going to spend some time with it.

wwarner• 5 years ago

see also https://github.com/gopherjs/gopherjs for a go -> js tool.

brundolf3• 5 years ago

The big question for me: what's the advantage of doing this in Go? Is it just for people who like the language, or is it faster/a smaller build/something else?

I only ask because WASM comes with some extra limitations and build complexity, especially when you're shipping a garbage collector

oscargrouch• 5 years ago

I think WASM used in this way will turn out to be the "new flash".

People coding into this sort of platform will ask for the whole language std, which in turn will have to be compiled to WASM, which will make massive blobs. And this is exactly what GWT was about, only that it was more sane giving it was compiled to Javascript.

Sure, some specialized applications (probably the ones that use C/C++ unique libraries like MMPEG) might benefit from it, but if we are complaining about modern Javascript libraries sizes now, i guess this will make us miss the good ol' days.

I hope browsers don't fall for this and keep WASM blobs working on the background as modules and accelerators as they should.

Maxence• 5 years ago

Hello there, I’m the creator of https://go-app.dev, a similar project based on Go and wasm.

Here are some thought of doing it with Go:

- The language itself is simple, clean and straightforward

- Compile time error checking

- Standard library that cover a lot of use-cases

- Testing and profiling tools out of the box with the language

- There is not that much extra limitations, just you can’t pop a server in the browser or access filesystem (same with other languages)

- When gzipped, wasm binaries are not that bigger than combined js resources on some other websites

- Wasm is supposed to be faster but that depends on the browser implementation and also the ui package you are using

Here is 2 other projects that I built with a Go wasm codebase: https://murlok.io and https://lofimusic.app. Can really do cool things with it.

brundolf3• 5 years ago

I could say all but the first about TypeScript :)

Of course some of these things are subjective and it's perfectly valid to explore alternate approaches, but I personally don't see the value proposition yet for doing things this way with Go

theptip• 5 years ago

I’ve been idly wondering if something like this might be viable in Python now. Taking the “server-side rendering” approach further, with WebAssembly you could just write your scripting in your server language and compile to js, instead of having to split your stack and do JS plus server.

(Of course many are already solving this problem in the other direction by using node on the server. I do hear “unified full stack language” as being given as a benefit in that case.)

IggleSniggle3• 5 years ago

Are you aware of Kotlin? Or Scala? Closure? What about ReasonML (related to OCaml)?

These are all languages that (roughly speaking, there’s nuance in their differences) transpile to bytecode or to JavaScript (ReasonML can also compile to native code). Come to think of it I think Haskell might have this now too.

There are many such languages! If “unified full stack language” is the goal, I think it makes sense to explore languages that were designed from the ground up with this in mind.

If the goal is “let programmers from ecosystem XYZ program in a new context” then I’m all about these experiments! Heck, I was a front end dev before becoming a backend dev via nodejs, so I get the appeal and think folks should go for it.

I am worried about the adoption of wasm, though, and not for the reasons you might think. We already complain about bloated js on the web, but it’s a high level language running in as a highly optimized VM focused on its effective support, with an ecosystem of developers that value small efficient packages. With wasm, it feels like we are on the verge of having Flash all over again, but this time *100 or more.

As the saying goes, “Give a man high level tools and he’ll fish for a day. Teach a man how to make a match and he’ll reinvent the fishing pole from matchsticks for a lifetime.”

spicybright3• 5 years ago

Can you clarify ReasonML compiling to native? Native web stack?

jamal-kumar• 5 years ago

Don't go binaries clock in at like 8MB (at best optimized) and plus some with all the static linking? How does this translate to webassembly because that sure seems like a lot for a website

DoctorOW• 5 years ago

From the docs:

Vugu programs can alternatively be compiled using TinyGo, which produces significantly smaller output than the default Go compiler. Many Vugu programs can be compiled with TinyGo to several hundred kilobytes, as opposed to sizes measured in megabytes.

mountainriver• 5 years ago

I love this project, Go is such a great API language that for simple apps it’s wonderful to be able to jump into the browser with it after writing your API

Vugu: Vue-like frontends in pure Go, HTML, and CSS

Related Stories