Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goja: A Golang JavaScript Runtime

jtarchie.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Goja: A Golang JavaScript Runtime

#11

Post by alixanderwang »

I work on the D2 project ([0]) and we switched from other Javascript runners (v8go) to Goja. Using a JS runtime with a dependency on cgo means your Go program loses the (huge) benefit of cross-compiling to different architectures, since at build time it gets linked to the current system's libc.

If you're interested in some production code with Goja, this is our code for calling RoughJS ([1]) from Go in order to produce the hand-drawn diagram look: [2]

[0] https://github.com/terrastruct/d2

[1] https://roughjs.com/

[2] https://github.com/terrastruct/d2/blob/master/d2renderers/d2...

Re: Goja: A Golang JavaScript Runtime

#12

Post by mappu »

nine_k wrote: post #3

In short: Goja is an ES5 interpreter written in pure Go and seamlessly integrating with it. You pass a struct, the JS side receives an object, you update it, and the Go side seamlessly gets an updated struct. No cgo overhead.

Calling a C function with Cgo has a certain overhead if you compare it to calling a Go function. But cgo overheads are completely negligible as soon as the function does any kind of real work. (A bigger reason to avoid cgo would be if you want easier cross-compilation.)

Re: Goja: A Golang JavaScript Runtime

#15

Post by nchmy »

I just dug through a lot of the issues and PRs in Goja, and eventually found that the grafana/k6 team recently forked Goja as Sobek [1], because the Goja dev has not been able to dedicate sufficient time to their PRs - namely ES Modules support [2], which was one of the only modern (ES6+) JS features outstanding [3]

So, Sobek seems to be the way forward...

[1] https://github.com/grafana/sobek/

[2] https://github.com/dop251/goja/pull/430

[3] https://github.com/dop251/goja/milestone/1

Re: Goja: A Golang JavaScript Runtime

#16

Post by BobVawter »

nchmy wrote: post #9

The examples in the article seem awfully contrived. Can someone please explain what a real-world use case for something like this would be? Why not just do it all in Go? Or is the point of it to be able to use existing JS scripts within a Go application?

I've been using goja in a logical replication tool to make it field-programmable by the end users. No two deployments look alike, so a great deal of flexibility is needed for ETL uses. There's a tendency for configuration languages to become Turing-complete, so we started with a Turing-complete language for configuration.

JS, or in Replicator's case, TypeScript (shout-out to esbuild), is sufficiently well-known that any dev group will have some experience with it. On the whole, I've been very impressed with how straightforward it's been to have user-scripts integrated into the processing pipeline.

https://github.com/cockroachdb/replicator/wiki/User-Scripts

Re: Goja: A Golang JavaScript Runtime

#17

Post by randomdata »

mappu wrote: post #12
nine_k wrote: post #3

In short: Goja is an ES5 interpreter written in pure Go and seamlessly integrating with it. You pass a struct, the JS side receives an object, you update it, and the Go side seamlessly gets an updated struct. No cgo overhead.

Calling a C function with Cgo has a certain overhead if you compare it to calling a Go function. But cgo overheads are completely negligible as soon as the function does any kind of real work. (A bigger reason to avoid cgo would be if you want easier cross-compilation.)

cgo execution overhead is a nothingburger, but the programmer overhead to convert between Go types and C->Javascript types, and vice versa, as required by the use of a third-party engine (v8, etc.) is still significant as compared to what Goja offers. That is what the parent is talking about.

Re: Goja: A Golang JavaScript Runtime

#18

Post by nchmy »

BobVawter wrote: post #16
nchmy wrote: post #9

The examples in the article seem awfully contrived. Can someone please explain what a real-world use case for something like this would be? Why not just do it all in Go? Or is the point of it to be able to use existing JS scripts within a Go application?

I've been using goja in a logical replication tool to make it field-programmable by the end users. No two deployments look alike, so a great deal of flexibility is needed for ETL uses. There's a tendency for configuration languages to become Turing-complete, so we started with a Turing-complete language for configuration. JS, or in Replicator's case, TypeScript (shout-out to esbuild), is sufficiently well-known that…

Ah, that makes a lot of sense - far easier to expose a JS api for user-extension than Golang (which is probably not even all that possible, except for via wasm, which would still be challenging)

And, I suppose my initial hunch is probably correct - for the dev/application to be able to use existing JS libraries (be it part of your broader application/system or external) within a Go app.

Check out my other comment [1] in this post for a newer, better version/fork of Goja - from the grafana/k6 team.

[1] https://news.ycombinator.com/item?id=41470601

Re: Goja: A Golang JavaScript Runtime

#19

Post by jtarchie »

donatj wrote: post #14

I've been a pretty happy Otto[1] user for a number of years now. The article makes no comparisons seemingly? I don't think there's even a never. I find that pretty odd. I'm curious if there'd be any reason to switch. https://github.com/robertkrimen/otto

I just wanted to share the details of my experience with Goja. It was not relevant to compare Otto.

Re: Goja: A Golang JavaScript Runtime

#20

Post by jtarchie »

nchmy wrote: post #9

The examples in the article seem awfully contrived. Can someone please explain what a real-world use case for something like this would be? Why not just do it all in Go? Or is the point of it to be able to use existing JS scripts within a Go application?

Not doing it all, Go allows my API endpoint to accept sandboxed javascript code to enable users to run more complex queries against my data. It is also faster because they don't have to make individual API calls for each data set. Therefore, more data is required to be sent over the wire to them.
Post reply on HN