2 ms·

> You can ingest and emit JSON in any language. How is this relevant? Serving a JS application to a client is not like serving a JSON API. > You can even co

> You can ingest and emit JSON in any language. How is this relevant? Serving a JS application to a client is not like serving a JSON API. > You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. Not in my experience. Compared to front-to-back JS, shipping your applications as WASM ends up with downloads and memory footprints that are several times larger than the same application in ordinary JS, and this matters a lot for slower networks and mobile clients. Edit: not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust.

d-z-m 4y ago
> How is this relevant? Serving a JS application to a client is not like serving a JSON API. In some JS applications, the way the frontend code communicates with the backend is via JSON API endpoints. I believe GP was just pointing out that you can write that JSON API in any language you want. > not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust. Can you elaborate on this? How is it limited in comparison to say, Rust.
- legerdemain 4y ago
  My understanding is that to get reasonable WASM file sizes, one must use tinygo (a C reimplementation). tinygo is a WIP, although I wish I could find a better updated description of what's missing than this page on their site: https://tinygo.org/docs/reference/lang-support/ https://tinygo.org/docs/reference/lang-support/
  - d-z-m 4y ago
    This page[0] seems to have some good information(on stdlib support at least). As far as file sizes go, you're right. It might be possible to get better results deploying a brotli'd or gzipped file instead[1]. [0]:https://tinygo.org/docs/reference/lang-support/stdlib/ https://tinygo.org/docs/reference/lang-support/stdlib/ [1]:https://github.com/golang/go/wiki/WebAssembly#reducing-the-size-of-wasm-files https://github.com/golang/go/wiki/WebAssembly#reducing-the-s...

d-z-m 4y ago

> How is this relevant? Serving a JS application to a client is not like serving a JSON API. In some JS applications, the way the frontend code communicates with the backend is via JSON API endpoints. I believe GP was just pointing out that you can write that JSON API in any language you want. > not to mention that Go has a very limited WASM story, so your "realistic" choices for shipping back end code to the front end are C++ and Rust. Can you elaborate on this? How is it limited in comparison to say, Rust.

legerdemain 4y ago
My understanding is that to get reasonable WASM file sizes, one must use tinygo (a C reimplementation). tinygo is a WIP, although I wish I could find a better updated description of what's missing than this page on their site: https://tinygo.org/docs/reference/lang-support/ https://tinygo.org/docs/reference/lang-support/
- d-z-m 4y ago
  This page[0] seems to have some good information(on stdlib support at least). As far as file sizes go, you're right. It might be possible to get better results deploying a brotli'd or gzipped file instead[1]. [0]:https://tinygo.org/docs/reference/lang-support/stdlib/ https://tinygo.org/docs/reference/lang-support/stdlib/ [1]:https://github.com/golang/go/wiki/WebAssembly#reducing-the-size-of-wasm-files https://github.com/golang/go/wiki/WebAssembly#reducing-the-s...