4 ms·

Alright, 90 points, most comments being meta about the title so I'll be the brave one and ask: What is this actually good for? I can't think of any reasonable

by recuter 13y ago

Alright, 90 points, most comments being meta about the title so I'll be the brave one and ask: What is this actually good for? I can't think of any reasonable use case. Grab little NPM ditties and incorporate them into your Go binary - Javascript to Go becomes as Lua is to C? Somebody enlighten me. Edit: Not that this needs a use case per say, just that the intent behind it is underspecified enough for me to wonder about it.

columbo 13y ago
If it was fully functional it could be useful for automated testing. Write your tests in javascript, execute them at the point of integration in Go.
gouggoug 13y ago
Not everything needs a use case. But if you really want one, here's one: I'm a student and I want to write my own interpreter. Well, here's a good example of how to write your interpreter.
- mturmon 13y ago
  That's not a use case.
  - gouggoug 13y ago
    You nonetheless understood what I meant, and knew by reading my comment that "use case" was a mis-use of language. That's nit-picking.
mushroomhead 13y ago
We have distributed crawler written in go configurable with xpath and javascript for advanced crawling using javascriptcore-go[1] and also our knowledge engine serves various form of formatted information card scripted in javascript. Duckduckgo goodies[2] also a good example of what we've been doing. 1) https://bitbucket.org/rj/javascriptcore-go https://bitbucket.org/rj/javascriptcore-go 2) https://duckduckgo.com/goodies https://duckduckgo.com/goodies
Loic 13y ago
In the case of web application, you can have the same templating engine running in the browser and in the server. This means rendering the full HTML at the server level if needed or part of it or just at the browser level. You get a bit of freedom. It is painful to manage two different templating engines between the server and browser sides.
- yeukhon 13y ago
  I don't get it. Are you saying - okay let's replace the javascript run time in today's browser to this version in Go?
  - furyofantares 13y ago
    I don't think he's saying that. I think he's saying your Go server could execute similar JavaScript as the client executes. Imagine a highly dynamic web page, beyond the initial page load when you interact with the page javascript executes the user's actions then rewrites large chunks of the page. As a developer, you need to write code on your backend that knows how to render the initial HTML for the page, but then you have to duplicate this functionality in JavaScript since the client needs to be able to render any chunk of the page that changes in response to a request. You have a few options as a developer here. You can live with maintaining two code paths in different languages that do essentially the same thing. Or you can get rid of the backend rendering entirely, making your page less friendly to no-script users and web crawlers (and sometimes making the site flicker a bit as content gets loaded initially for all users.) Or you can use shared code on the backend and the client for rendering HTML by having a backend that speaks JavaScript.
patrickg 13y ago
I distribute a binary that can be extended via Javascript/Lua/... API by a customer. This is great. I don't want the customer to mess with the Go source but I give him the chance to mess with the program by a well defined API.
hbbio 13y ago
You can scale npm now.
jchrisa 13y ago
We use it because we have user programmable callbacks, and JavaScript provides a well-known sandboxed language. Otto makes it really easy to expose native functionality to JS.
phoboslab 13y ago
Reminds me of the early 2000s argument "why do we need another browser? IE is good enough". This project may not be the fastest JS engine or the one with the most features right now, but if nothing else, it's a really nice project for learning Go and writing interpreters. Maybe some new ideas will be explored in this engine first, because it's faster to implement them in Go than in the (huge) V8 or other JS engines. Having new alternatives to established software is always a good thing.
- recuter 13y ago
  I wasn't making any argument, simply asking.

by recuter 13y ago

columbo 13y ago

If it was fully functional it could be useful for automated testing. Write your tests in javascript, execute them at the point of integration in Go.

gouggoug 13y ago

Not everything needs a use case. But if you really want one, here's one: I'm a student and I want to write my own interpreter. Well, here's a good example of how to write your interpreter.

mturmon 13y ago
That's not a use case.
- gouggoug 13y ago
  You nonetheless understood what I meant, and knew by reading my comment that "use case" was a mis-use of language. That's nit-picking.

mushroomhead 13y ago

We have distributed crawler written in go configurable with xpath and javascript for advanced crawling using javascriptcore-go[1] and also our knowledge engine serves various form of formatted information card scripted in javascript. Duckduckgo goodies[2] also a good example of what we've been doing. 1) https://bitbucket.org/rj/javascriptcore-go https://bitbucket.org/rj/javascriptcore-go 2) https://duckduckgo.com/goodies https://duckduckgo.com/goodies

Loic 13y ago

In the case of web application, you can have the same templating engine running in the browser and in the server. This means rendering the full HTML at the server level if needed or part of it or just at the browser level. You get a bit of freedom. It is painful to manage two different templating engines between the server and browser sides.

yeukhon 13y ago
I don't get it. Are you saying - okay let's replace the javascript run time in today's browser to this version in Go?
- furyofantares 13y ago
  I don't think he's saying that. I think he's saying your Go server could execute similar JavaScript as the client executes. Imagine a highly dynamic web page, beyond the initial page load when you interact with the page javascript executes the user's actions then rewrites large chunks of the page. As a developer, you need to write code on your backend that knows how to render the initial HTML for the page, but then you have to duplicate this functionality in JavaScript since the client needs to be able to render any chunk of the page that changes in response to a request. You have a few options as a developer here. You can live with maintaining two code paths in different languages that do essentially the same thing. Or you can get rid of the backend rendering entirely, making your page less friendly to no-script users and web crawlers (and sometimes making the site flicker a bit as content gets loaded initially for all users.) Or you can use shared code on the backend and the client for rendering HTML by having a backend that speaks JavaScript.

patrickg 13y ago

I distribute a binary that can be extended via Javascript/Lua/... API by a customer. This is great. I don't want the customer to mess with the Go source but I give him the chance to mess with the program by a well defined API.

hbbio 13y ago

You can scale npm now.

jchrisa 13y ago

We use it because we have user programmable callbacks, and JavaScript provides a well-known sandboxed language. Otto makes it really easy to expose native functionality to JS.

phoboslab 13y ago

Reminds me of the early 2000s argument "why do we need another browser? IE is good enough". This project may not be the fastest JS engine or the one with the most features right now, but if nothing else, it's a really nice project for learning Go and writing interpreters. Maybe some new ideas will be explored in this engine first, because it's faster to implement them in Go than in the (huge) V8 or other JS engines. Having new alternatives to established software is always a good thing.

recuter 13y ago
I wasn't making any argument, simply asking.