Hacker News Reader

Comment by brundolf | Hacker News Reader

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

View on HN

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.

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

Yeh but if you already know go then this is perfect.

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.

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.

Reply on news.ycombinator.com