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

71–72 of 72 posts

Re: A JavaScript parser and interpreter written in Go

#71

Post by yeukhon »

Loic wrote: post #27
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.

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?

Re: A JavaScript parser and interpreter written in Go

#72

Post by furyofantares »

yeukhon wrote: post #71
Loic wrote: post #27

Earlier quoted context omitted.

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.

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?

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.

Post reply on HN