[HN Gopher] Goja: A Golang JavaScript Runtime
___________________________________________________________________
Goja: A Golang JavaScript Runtime
Author : mihaitodor
Score : 47 points
Date : 2024-09-04 13:45 UTC (2 days ago)
(HTM) web link (jtarchie.com)
(TXT) w3m dump (jtarchie.com)
| throwaway13337 wrote:
| This is the runtime pocketbase uses to allow javascript interop.
|
| Pocketbase is the framework that makes me want to switch to
| golang. It just makes a lot of sense.
|
| One thing that concerned me, though. How do I debug goja? It
| doesn't seem like I can set breakpoints as usual.
|
| https://pocketbase.io/
| thangngoc89 wrote:
| Actually I decided to learn golang for extending using Golang
| for better DX (type hints and compiler errors)
| throwaway13337 wrote:
| It's certainly a good idea to know golang while using
| something like pocketbase.
|
| However, one of the strengths of pocketbase, I think, is that
| the creator chose to add bindings for a very well known
| scripting language (js) to allow projects to be rapidly
| developed. It feels like django rethought.
|
| Using go for the base of your project and then gluing things
| together via scripting seems like a good idea. It's quite a
| big feature of the framework.
| skeeter2020 wrote:
| performance seems pretty solid too, removing one of my
| prime motivators for switching to Go for extension work.
| PocketBase just seems to have made a lot of great decisions
| based on the conceptual integrity of the project goals.
| nine_k wrote:
| 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.
| chrsig wrote:
| It's definitely cool, and and accomplishment. I think it's a
| bit strange to compare it to "no cgo overhead" though
|
| I say that because it's an interpreter rather than a jit, and
| doesn't have nearly as many person hours put into it as v8.
|
| I can see the argument that if you just need to evaluate a
| quick expression or maybe some user supplied script or
| something, it could be very handy, but I have a hard time
| believing that the cgo overhead is a factor when using cgo to
| invoke v8 compared to the parse/jit overhead that v8 will do.
|
| This is all armchair speculation of course. I use go regularly,
| but have no taste for javascript, so I have no dogs in that
| race. Definitely cool that there's an interpreter focused on
| correctness though.
| mappu wrote:
| 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.)
| siamese_puff wrote:
| Great article. I was looking for something like this last week.
| nchmy wrote:
| 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?
| dialogbox wrote:
| The name looks a obvious choice but... Ouch. It's a very funny
| name for Korean. It means eunuch. Lol
| alixanderwang wrote:
| 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...
___________________________________________________________________
(page generated 2024-09-06 23:01 UTC)