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

A JavaScript parser and interpreter written in Go

github.com

Post reply on HN
Print view View original

21–30 of 72 posts

Re: A JavaScript parser and interpreter written in Go

#21

Post by gyepi »

jzelinskie wrote: post #3
jchrisa wrote: post #2

We use this for the sync function interpreter in Sync Gateway. Robert has been very helpful and responsive with pull requests etc. thanks! Edit to add link to example code using Otto https://github.com/couchbase/sync_gateway/blob/master/src/gi...

Thank you for being one of the few gophers that put newlines between standard, third party, and local imports. I wish gofmt forced that standard on people.

It is a useful convention in C and C++ to group includes, but I don't see the benefit in Go.

Since gofmt sorts imports, the grouping is soon undone.

In any case, it is quite easy to distinguish the three kinds of imports if local imports share a common prefix or set of prefixes.

Am I missing something here?

Re: A JavaScript parser and interpreter written in Go

#22

Post by mushroomhead »

recuter wrote: post #18

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

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

2) https://duckduckgo.com/goodies

Re: A JavaScript parser and interpreter written in Go

#23

Post by mushroomhead »

ChronosKey wrote: post #8
scosman wrote: post #7

the perfect hacker news title

Show HN: How a JavaScript parser and interpreter written in Go allowed my startup to succeed and Why your company should switch to Go

Show HN: A JavaScript parser and interpreter written in 30 lines of Go

Re: A JavaScript parser and interpreter written in Go

#25

Post by raverbashing »

Goranek wrote: post #24

Can someone explain to me whats wrong with using V8 in Go? I mean what's the point in building js interpreter in Go, when you already have a better one made.

Well, maybe they will come with a better Google Closure in Go

Because Google Closure Compiler is unbelievably slow

Re: A JavaScript parser and interpreter written in Go

#26

Post by BMorearty »

Goranek wrote: post #24

Can someone explain to me whats wrong with using V8 in Go? I mean what's the point in building js interpreter in Go, when you already have a better one made.

What's the point of starting anything new, when something like it already exists? Why become a doctor when there are already good doctors? Why write a book when there are already good books? Why sing a song when somebody else already sings it better?

Re: A JavaScript parser and interpreter written in Go

#27

Post by Loic »

recuter wrote: post #18

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

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.

Re: A JavaScript parser and interpreter written in Go

#28

Post by agentS »

gyepi wrote: post #21
jzelinskie wrote: post #3

Earlier quoted context omitted.

Thank you for being one of the few gophers that put newlines between standard, third party, and local imports. I wish gofmt forced that standard on people.

It is a useful convention in C and C++ to group includes, but I don't see the benefit in Go. Since gofmt sorts imports, the grouping is soon undone. In any case, it is quite easy to distinguish the three kinds of imports if local imports share a common prefix or set of prefixes. Am I missing something here?

Note that gofmt sorts within groups. So if you leave spaces between groups of imports, it'll sort them all separately. Presumably, this sort of grouping is the reason it does it this way.

Re: A JavaScript parser and interpreter written in Go

#29

Post by patrickg »

recuter wrote: post #18

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

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.
Post reply on HN