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
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
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.
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.
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
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
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.)
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.”
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
>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.
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.
I only ask because WASM comes with some extra limitations and build complexity, especially when you're shipping a garbage collector