Show HN: CandyJS – transparent bridge between Go and JavaScript
1–10 of 16 posts
Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#2cool! why and how are the Go methods called with camelcase names?
var engine = gin.default();
engine.get("/back", CandyJS.proxy(function(ctx) {
var future = time.date(2015, 10, 21, 4, 29 ,0, 0, time.UTC);
var now = time.now();
ctx.json(200, {
future: future.string(),
now: now.string(),
nsecs: future.sub(now)
});
}));Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#3cool! why and how are the Go methods called with camelcase names? var engine = gin.default(); engine.get("/back", CandyJS.proxy(function(ctx) { var future = time.date(2015, 10, 21, 4, 29 ,0, 0, time.UTC); var now = time.now(); ctx.json(200, { future: future.string(), now: now.string(), nsecs: future.sub(now) }); }));
the method and field names are converted to lowerCamelCase to be compliant with the JS coding style. Let's see if this transformation becomes a headache.
BTW this behaviour is undocumented, I will fix that.
Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#4I built a package to bridge spidermonkey/Go last year[0]. I ended up doing most of the communication via JSON (after several less stable versions using reflect) which was fine for the use-case I had. Unfortunately since it builds spidermonkey and some wrapper code it ruined any chance of "go get" working cleanly which doesn't make it a very attractive package.
CandyJS looks much simpler. Good work.
Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#5cool! why and how are the Go methods called with camelcase names? var engine = gin.default(); engine.get("/back", CandyJS.proxy(function(ctx) { var future = time.date(2015, 10, 21, 4, 29 ,0, 0, time.UTC); var now = time.now(); ctx.json(200, { future: future.string(), now: now.string(), nsecs: future.sub(now) }); }));
the method and field names are converted to lowerCamelCase to be compliant with the JS coding style. Let's see if this transformation becomes a headache. BTW this behaviour is undocumented, I will fix that.
got it!
Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#6This is pretty interesting, although I don't know if it's... necessary.
What do you think are some of the pros/cons between Go and JavaScript? When would you prefer to use JavaScript instead of Go, or vice versa?
I think Go can be more performant than Node.js, but I remember seeing some conflicting benchmarks where V8 can actually manage more RPS.
The other thing that comes to mind is how React Native uses JavaScript to manipulate UI Components on iOS. If Google ever supports Go on Android, then this kind of thing could be pretty interesting.
Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#7This is pretty interesting, although I don't know if it's... necessary. What do you think are some of the pros/cons between Go and JavaScript? When would you prefer to use JavaScript instead of Go, or vice versa? I think Go can be more performant than Node.js, but I remember seeing some conflicting benchmarks where V8 can actually manage more RPS. The other thing that comes to mind is how React Native uses JavaScript…
Duktape is good for scripting. My particular app is a simple rule engine for smart home applications which runs on relatively low-powered ARM board. It would hardly be practical to have Go compiler there, and duktape is resource-efficient ECMAScript engine which serves this purpose just fine.
Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#8This is pretty interesting, although I don't know if it's... necessary. What do you think are some of the pros/cons between Go and JavaScript? When would you prefer to use JavaScript instead of Go, or vice versa? I think Go can be more performant than Node.js, but I remember seeing some conflicting benchmarks where V8 can actually manage more RPS. The other thing that comes to mind is how React Native uses JavaScript…
Duktape is good for scripting. My particular app is a simple rule engine for smart home applications which runs on relatively low-powered ARM board. It would hardly be practical to have Go compiler there, and duktape is resource-efficient ECMAScript engine which serves this purpose just fine.
Oh I see, that's pretty cool!
Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#9I built a package to bridge spidermonkey/Go last year[0]. I ended up doing most of the communication via JSON (after several less stable versions using reflect) which was fine for the use-case I had. Unfortunately since it builds spidermonkey and some wrapper code it ruined any chance of "go get" working cleanly which doesn't make it a very attractive package. CandyJS looks much simpler. Good work. [0] https://github…
Hi Chris, thanks for your support.
Your packages looks like very interesting, I couldn't find it before.
About the pool of workers, they share the stack? Or how you keep the same status on each.
Re: Show HN: CandyJS – transparent bridge between Go and JavaScript
#10Nice project! One little remark: I see you're being slightly lazy and using JSON to save some value conversion work. One problem is that this is not very good from a performance standpoint. The other, more serious issue is that your code will not work if someone tries to pass around a data structure containing NaN value, like []float64{math.NaN()} Got bitten by this problem, had to fix it: https://github.com/contactless/wb-rules/commit/067ff7564f16a...