An ES5-compliant JavaScript interpreter, written in Java | Hacker News Reader

An ES5-compliant JavaScript interpreter, written in Java

github.com

37 pointsneeleshs8 comments

https://en.m.wikipedia.org/wiki/Rhino_(JavaScript_engine)

Written in Java and compiles to JVM

Nowadays one would probably use the GraalVM based implementation instead of Rhino: https://www.graalvm.org/latest/reference-manual/js/

I would guess that depends on the licensing context in which it will be running, since Rhino is MPLv2 <https://github.com/mozilla/rhino/blob/Rhino1_7_14_Release/LI...> and OP's repo is MIT whereas Graal is UPLv1 <https://github.com/oracle/graaljs/blob/graal-23.1.2/LICENSE>. GitHub's license gizmo claims it is OSI/FSF approved, but Oracle gonna Oracle and they for sure have more lawyers than you do

Well, I know what my first PR would be to this repo: it's missing the ScriptEngine plumbing <https://docs.oracle.com/en/java/javase/11/docs/api/java.scri...>, which I think is a prerequisite for use in any sane JVM setup

One will also want to watch out for the "yes, but" in their parser around reserved words: https://github.com/TopchetoEU/jscript/blob/v0.9.6-beta/src/j... I'm not an ES[0-9] ninja enough to know what the practical implication is of those decisions, but nor do I think hiding them in some comments down in the Parser is the correct way to advise folks of that choice

> I'm not an ES[0-9] ninja enough to know what the practical implication is of those decisions

Well, it makes it non-compliant and makes it unable to run some (horrible, yet compliant) ES5 scripts. "undefined", "arguments", "globalThis", "window" and "self" are just variables which can be aliased and overwritten, so considering them keywords is broken.

Disallowing "const" and "let", which only became reserved in ES6, isn't a big deal as any modern interpreter uses them, but does also limit valid ES5 scripts from running.

(And yes, it's very weird that "undefined" is just a property on the global object that has not been assigned a value. Feels like someone trying to be "smart" instead of just giving it a keyword...)

Cool, I wonder how more JS interpreters would affect the ecosystem.

JavaJavaScript

> THE GOAL OF THIS ENGINE IS NOT PERFORMANCE. My crude experiments show that this engine is 50x-100x slower than V8

This should be obvious given that it's written in Java. A C++ implementation like V8 is always going to be much more performant.

I think it'd be fascinating to see if a JavaScript engine written in Rust or Zig could compete on performance with V8. But Java, as I believe even its biggest advocates would acknowledge, is not a good language choice for performance sensitive programs.

Reply on news.ycombinator.com