4 ms·

Hello there, I’m the creator of https://go-app.dev https://go-app.dev, a similar project based on Go and wasm. Here are some thought of doing it with Go: - Th

Hello there, I’m the creator of https://go-app.dev 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 https://murlok.io and https://lofimusic.app https://lofimusic.app. Can really do cool things with it.

brundolf 5y 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
- russdpale 5y ago
  Yeh but if you already know go then this is perfect.
- dimitrios1 5y ago
  Not exactly. It's been said enough times, but compile time type checking has a big asterisk besides it with Typescript.
  - brundolf 5y ago
    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.
    - dimitrios1 5y ago
      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.

brundolf 5y 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

russdpale 5y ago
Yeh but if you already know go then this is perfect.
dimitrios1 5y ago
Not exactly. It's been said enough times, but compile time type checking has a big asterisk besides it with Typescript.
- brundolf 5y ago
  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.
  - dimitrios1 5y ago
    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.