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

21–30 of 36 posts

Re: Goja: A Golang JavaScript Runtime

#21

Post by jtarchie »

nchmy wrote: post #15

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/…

I did see that. I'm going to let the fork simmer for awhile. I didn't require module support for my runtime. Since its meant to be very basic ETL runtime.

Re: Goja: A Golang JavaScript Runtime

#22

Post by jtarchie »

skeeter2020 wrote: post #8
throwaway13337 wrote: post #5

Earlier quoted context omitted.

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 b…

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.

I've used Pocketbase for some other projects. A quick small web app, but it was so easy.

Re: Goja: A Golang JavaScript Runtime

#25

Post by nchmy »

jtarchie wrote: post #20
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.

Thanks. Ive been exploring all of this for the past many hours and definitely see the appeal and various use cases for it now.

Thanks for opening me up to it all - it will definitely solve a problem that I'm about to start working on!

Re: Goja: A Golang JavaScript Runtime

#26

Post by nchmy »

jtarchie wrote: post #21
nchmy wrote: post #15

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/…

I did see that. I'm going to let the fork simmer for awhile. I didn't require module support for my runtime. Since its meant to be very basic ETL runtime.

Fair enough! Though they're quite clearly a much more serious/focused/resourced team than the goja dev, and they've fully integrated it into the K6 codebase now. I expect it'll have a bright future.

Since you're doing ETL, did you consider something like Conduit, which is written in Golang and also allows for JS processing in the pipeline? Or is that overkill for what youre doing?

https://conduit.io/docs/processors/builtin/custom.javascript

Re: Goja: A Golang JavaScript Runtime

#27

Post by nchmy »

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 just found this excellent comment in an relevant Reddit post[1], which clarifies things quite nicely for me.

---

Let’s set up the scenario. You have a program that a user can manage via a config file. That tune knobs and dials, and everything works. They then ask you one day, “I’d like to add some custom logic for they have.”

Do you add another option to the configuration file to support their one use case? Or provide a mechanism for them actually to write some code?

If it’s the latter, do you want them to have to recompile your program to be able to run that custom code? Or do you have a runtime in your application for that custom code?

The latter is what a browser does. You can write JavaScript for a website without recompiling the browser just for the website. The user doesn’t have to worry about your event loops, SDKs, APIs, wiring code in rust/C, etc. This feature allows others to add custom logic to your application's runtime.

This is the purpose of embedding JavaScript into an application. It’s not the whole program, but it allows someone to provide code in your program event loop to do something custom. Not every program needs this. Sometimes, a config file of YAML or command line arguments works, too.

[1] https://www.reddit.com/r/golang/comments/1d78d3j/what_script...

Re: Goja: A Golang JavaScript Runtime

#28

Post by artpar »

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 am using otto[0] (similar to goja) in the headless cms I maintain [1] in "actions" api [2]. So one can customize actions according to needs by writing JS. The JS is executed inside a transaction. Sort of a mini-lambda kind of api

[0] https://github.com/robertkrimen/otto [1] https://github.com/daptin/daptin [2] https://daptin.github.io/docs/actions/actions/

Re: Goja: A Golang JavaScript Runtime

#29

Post by joostdecock »

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?

For a real-worl use case, look towards the 'script' processor in Elastic' Beats family of data shippers [1] (example is from Metricbeat but it exists in other Beats too)

They can be configured to mutate the data with some basic DSL syntax, but if you have more advanced needs, you can break out to JavaScript and transform the JSON any way you want.

This is very useful because now any transformation becomes possible. And because this is the user of your product who writes that JavaScript more as configuration than code. And since there's no build step, it is just part if the configuration loaded at startup.

[1] https://www.elastic.co/guide/en/beats/metricbeat/current/pro...

Post reply on HN