wasmws VS goja

Thanks for writing this! I found it really great to use when I wrote https://github.com/tarndt/wasmws

Before looking at the readme, I thought this was an alternative to using https://github.com/tarndt/wasmws which lets you use gRPC over websockets so that you can use gPRC via WASM without needing an http to gRPC gateway. Now I'm understanding a bit differently. It looks like this uses protobufs but doesn't have anything to do with gRPC at all, instead implementing some of the communication parts of gRPC while ignoring the generation of services but instead focusing a bit more on message routing and pub/sub that you would probably still need NATS.io for if you were using gRPC.

The hijacking a websocket works very well, live in the future today! https://github.com/tarndt/wasmws

Everything said above is valid, but if you do think you have a need to transpile... consider running any Go frontend code as WASM rather than Javascript. A few years ago I started doing my frontends and backends all in Go and its been wonderful. I even wrote a library so I could use gRPC from my WASM/Go frontends rather than REST: https://github.com/tarndt/wasmws . Extra wonderful, at least for my tastes. Once caveat is if your brotli compressed, CDN/browser cached, etagged Go WASM is still to big, you can usually make it even smaller by using tinygo rather than the std tool chain for the compiling to WASM.

A while back I was writing a pure Go frontend app (WASM) and I wrote this so I could use gRPC rather than REST to talk to my backend: https://github.com/tarndt/wasmws

dop251/goja

Your comment was posted 4 minutes ago. That means you still have enough time to edit your comment to change it so it contains real URLs:

<https://github.com/PuerkitoBio/goquery>

<https://github.com/dop251/goja>

(Please do not reply to this comment—I won't be able to delete it once the previous post is fixed if it contains replies.)

Apparently "not depending on Node or V8" means depending on some random Go JS engine instead.

Goja https://github.com/dop251/goja

Either call a JavaScript interpreter like node with exec.Command and read its stdout, or use a pure Go JavaScript interpreter like goja or otto.

Just to also say this is implemented in pure Go we aren't including V8 or any external dependencies we instead use https://github.com/dop251/goja which is a JS VM written completely in Go.

If you want to serialize a function to JSON one idea may be to embed a scripting language like JavaScript into your program. The goja package is a very good solution: a native ES5 JavaScript (with some ES6 syntax support as well) natively implemented in Go so you can get tight data bindings to your Go types and funcs. For your JSON marshalling you could serialize a JavaScript function source (text) and when reloading that, parse that text with goja to be able to run it dynamically in your Go program. Basically you'd need to get away from pure Go for this and towards something that is JSON compatible to (de)serialize to text.

Not really. It was built in-house and I don't know of anything about it that went public. I recall it using Goja for the JS runtime. Code was embedded into the binary (think embed package). There was some kind of sorcery to convert what would be HTTP network calls in the browser into local function calls during SSR, but I'm hazy on how it worked I'm afraid.