Vugu: Vue-like frontends in pure Go, HTML, and CSS(vugu.org)
vugu.org
Vugu: Vue-like frontends in pure Go, HTML, and CSS
https://www.vugu.org/
33 comments
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.
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.
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.
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.
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
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
Not exactly. It's been said enough times, but compile time type checking has a big asterisk besides it with Typescript.
Going to avoid getting into a religious argument, but it's my view that TypeScript's types are much stronger and more expressive than Go's. There are some holes, but the mere fact that you can distinguish nullable from non-nullable gives it the edge from my perspective.
I agree that TypeScript has a more expressive type system (not an advantage depending on how you view things, however).
The big asterisk I am referring to is the fact that types are defined through a side channel rather than through the language itself. Your typing files may be different than someone elses. Everyone just so happens to use the same ones, so this problem doesn't come up too often in practice, but in applications where you need guaranteed static analysis, Typescript doesn't fit the bill.
The big asterisk I am referring to is the fact that types are defined through a side channel rather than through the language itself. Your typing files may be different than someone elses. Everyone just so happens to use the same ones, so this problem doesn't come up too often in practice, but in applications where you need guaranteed static analysis, Typescript doesn't fit the bill.
Yeh but if you already know go then this is perfect.
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
The hamburger menu does not work for me on Chrome iOS... also there seems to be an overflow issue.
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!
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!
I tested it on desktop chrome while imitating a mobile device and it doesn't work there either.
Yeah the only difference on Chrome desktop is the hamburger gets a focus outline. No hamburger for anybody.
macOS firefox, doesn't work for me either. Not the best thing to have a broken website advertising a web framework lol
I had a similar thought but kept it to myself. Any project like this is ambitious and probably first showing is going to have the most visible warts. Let’s try to be constructive with feedback
Don’t you think that pointing out a broken website isn’t constructive ?
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.)
(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.)
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.”
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.”
Can you clarify ReasonML compiling to native? Native web stack?
ReasonML compiles to native binary as a dialect of OCaml (ie for server code). It also compiles to JavaScript to produce frontend code.
Read more about it here:
https://reason-native.com/docs/native-basics
Read more about it here:
https://reason-native.com/docs/native-basics
Previously discussed when the project was a few months old: https://news.ycombinator.com/item?id=20449427
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
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.
>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.
Do the templates have compile time type checking?
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
> 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
Do they have another type safe template engine then?
Thanks
Hmm, last update was on 2020-09-13. :/
Last commit was 7 days ago: https://github.com/vugu/vugu
Ah cool, I was going to check GitHub but I did not have the time. Still, they should probably add something recent on their main page, along with incrementing the year here: "Copyright (C) 2020". ^^
In any case, this is amazing. I love both Go and Vue! I am going to spend some time with it.
In any case, this is amazing. I love both Go and Vue! I am going to spend some time with it.
I only ask because WASM comes with some extra limitations and build complexity, especially when you're shipping a garbage collector