I only ask because WASM comes with some extra limitations and build complexity, especially when you're shipping a garbage collector
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.
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
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.
I hope browsers don't fall for this and keep WASM blobs working on the background as modules and accelerators as they should.
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!
(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.)
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.”
Read more about it here:
>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.
> Why doesn't Vugu use Go templates (html/template)?
> Short answer: Because templates do not provide type safety or other compile-time checks.
In any case, this is amazing. I love both Go and Vue! I am going to spend some time with it.