6 ms·

I don't like it. It looks like early php. This doesnt mean it is bad. I'm working on a web framework as well based on wasm in the browser. It's perfect except

I don't like it. It looks like early php. This doesnt mean it is bad. I'm working on a web framework as well based on wasm in the browser. It's perfect except it's not really usuable/production ready due to high memory consumption of the go->wasm implementation. My hope is that one day there will be support for GC in wasm and somehow the issue will go away.

cube2222 4y ago
Have you looked into using TinyGo[0]? It's a Go-for-embedded compiler and can compile Go to WASM as well. It's supposed to result in much smaller artifacts. [0]: https://tinygo.org/docs/guides/webassembly/ https://tinygo.org/docs/guides/webassembly/
- TobyTheDog123 4y ago
  In my experience, TinyGo is far from ready for prime time, mainly because of its lack of support for JSON marshaling/unmarshaling. I run Go code in Cloudflare Workers, and just use the regular-ol' WASM targets (GOOS=js/GOARCH=wasm)
  - oefrha 4y ago
    Huh, CF Workers used to limit the payload to 1MB, and any slightly nontrivial golang js/wasm artifact (not tinygo) I’ve ever built was >2MB compressed, so the idea of running those on CF Workers was dead on arrival. However, apparently the limit was raised to 5MB for paid plans some time last year.
- thefounder 4y ago
  I'm using a lot of reflection and I believe tinygo has had some issues with the reflect package. I'm not really ready to dig into Tinygo issues. I've spent a lot of time dealing with Go's own reflect issue(i.e [0]) in its default implementation. https://github.com/golang/go/issues/15924 https://github.com/golang/go/issues/15924
  - TachyonicBytes 4y ago
    TinyGo does indeed have problems with the reflect package, as well as many others, one which I've managed to help with [1]. The developers have been very helpful, but the reflect package is still a big missing piece. Your framework sounds interesting. Do you develop it in the open? [1] https://github.com/tinygo-org/tinygo/issues/3274 https://github.com/tinygo-org/tinygo/issues/3274
    - euroderf 4y ago
      Lack of reflection also creates issues for (for example) XML decoding, but I found that it's possible to delete reflection code from the source and compile it with basic decoding support. No annotations - but this is OK because Go's XML annotations are evil.
paulsmith 4y ago
Since Pushup is a compiler, one thought I've had is giving the ability to demarcate server-side and client-side code in a Pushup page, and compiling down to WASM for the client-side code. Then the compiler would generate the network code to do the hand-offs.
aatd86 4y ago
Interesting! Do you have a link?

cube2222 4y ago

Have you looked into using TinyGo[0]? It's a Go-for-embedded compiler and can compile Go to WASM as well. It's supposed to result in much smaller artifacts. [0]: https://tinygo.org/docs/guides/webassembly/ https://tinygo.org/docs/guides/webassembly/

TobyTheDog123 4y ago
In my experience, TinyGo is far from ready for prime time, mainly because of its lack of support for JSON marshaling/unmarshaling. I run Go code in Cloudflare Workers, and just use the regular-ol' WASM targets (GOOS=js/GOARCH=wasm)
- oefrha 4y ago
  Huh, CF Workers used to limit the payload to 1MB, and any slightly nontrivial golang js/wasm artifact (not tinygo) I’ve ever built was >2MB compressed, so the idea of running those on CF Workers was dead on arrival. However, apparently the limit was raised to 5MB for paid plans some time last year.
thefounder 4y ago
I'm using a lot of reflection and I believe tinygo has had some issues with the reflect package. I'm not really ready to dig into Tinygo issues. I've spent a lot of time dealing with Go's own reflect issue(i.e [0]) in its default implementation. https://github.com/golang/go/issues/15924 https://github.com/golang/go/issues/15924
- TachyonicBytes 4y ago
  TinyGo does indeed have problems with the reflect package, as well as many others, one which I've managed to help with [1]. The developers have been very helpful, but the reflect package is still a big missing piece. Your framework sounds interesting. Do you develop it in the open? [1] https://github.com/tinygo-org/tinygo/issues/3274 https://github.com/tinygo-org/tinygo/issues/3274
  - euroderf 4y ago
    Lack of reflection also creates issues for (for example) XML decoding, but I found that it's possible to delete reflection code from the source and compile it with basic decoding support. No annotations - but this is OK because Go's XML annotations are evil.

paulsmith 4y ago

Since Pushup is a compiler, one thought I've had is giving the ability to demarcate server-side and client-side code in a Pushup page, and compiling down to WASM for the client-side code. Then the compiler would generate the network code to do the hand-offs.

aatd86 4y ago

Interesting! Do you have a link?