ECMAScript Shells

This file is a link farm for command-line ECMAScript implementations, with some comments.

ECMAScript 262-{1,2,3}


See or

It is a C implementation. The Mozilla/Netscape interpreter is based on this.

To run: "js -s -w myfile.js"

The only reference for its global functions seems to be the js.c source code, or from running the top-level function help():


Note that it is possible to enable some dead code in jsfile.c via JS_HAS_FILE_OBJECT=1 and adding jsfile.c to makefile. See



Same base code as SpiderMonkey, but it adds the ability to load xpcom components, a few of which are builtin.

To run: "mozilla-dir/ mozilla-dir/xpcshell -w myfile.js" (various environment variables have to be set by the wrapper shell script.)

For its global functions see mozilla-source/js/src/xpconnect/shell/xpcshell.cpp

  static JSFunctionSpec glob_functions[] = {
    {"print",           Print,          0},
    {"load",            Load,           1},
    {"quit",            Quit,           0},
    {"version",         Version,        1},
    {"build",           BuildDate,      0},
    {"dumpXPC",         DumpXPC,        1},
    {"dump",            Dump,           1},
    {"gc",              GC,             0},
    {"clear",           Clear,          1},

xpcshell is allegedly distributed with all debug builds of Mozilla.

In theory, it is supposed to be possible to build xpcshell without the rest of the Mozilla tree:

Otherwise you can just build/download the entire Mozilla.

The "jslib" has been separated from xpcshell. See and It contains javascript libraries that utilize builtin or external xpcom components.

For some discussion of file IO using xpcshell, see



It is a Java implementation. It is used in the ICE browser.

To run: "java -jar js.jar myfile.js"

Its global functions are: and found in mozilla/js/rhino/toolsrc/org/mozilla/javascript/tools/shell/

Its default optimization level is -opt 0, which means that it converts to Java byte codes, but does not optimize them. Optimization level -1 means interpret without converting to java byte codes at all.

There is also a compiler to java class files, jsc:

The Apache Cocoon project has a forked version which adds continuation support: There is much discussion about this; see for example:

WSH (Windows Scripting Host)


If you have Windows, you probably already have it installed, though you might want to download a newer version.

To run: "cscript.exe" to run in console, "wscript.exe" to run in a dialog.

You might need to run "cscript //h:cscript" to change the default script engine.

The runtime host objects are at documented at:
         Scripting.Dictionary, Scripting.FileSystemObject
         WScript, ...

Note that the version of WSH jumped from 2.0 (in 1999) to 5.6 (in 2002).



KJS is the interpreter used in Konqueror and Safari. It is in C++, licensed LGPL.

You can download "JavaScriptCore" from the web page to get the source for the interpreter. With about a dozen minor changes (mostly missing #include) I was able to get it to build on linux. There is a testkjs.cpp that may be compiled into a command-line interpreter. The only non-standard global it seems to define is kjsprint(), and then only if not NDEBUG (see internal.cpp).



This is an LGPL implementation in Java, that seems not to have changed in several years. By Jean-Marc Lugrin. Uses a JavaCC grammar. It also appears not to implement edition 3, only edition 1. It seems that Rhino has eclipsed it.



This is an LGPL implementation in C primarily by Brian Bassett. Not terribly active, but implements edition 3.



C++, LGPL. It claims to have a javascript interpreter (circa 2001).



LGPL, apparently starting and ending without completion in 2000. Uses SableCC with a grammar modified from FESI. By Etienne M. Gagnon (same as author of SableCC) and Pedro Vale Lima . See

Kawa gnu.ecmascript

See . Kawa is a Scheme implementation in Java. There was a start at an EcmaScript by Per Bothner that was abandoned when Rhino came out. Modified GPL.

XWT org.xwt.js

XWT is a java-based client-side web application toolkit. It includes an ECMAScript implementation. By Adam Megacz. See and . GPL.



LGPL. Translates javascript to scheme. Written in scheme. Seems to have died in 2000.


This is a commercial implementation available in Java or in C++ . See



MIT license, written in C++.

It parses JavaScript using the C++ Boost Spirit library. Not yet a complete JavaScript library for runtime.



It is a recent (2004) parser of JavaScript written in JavaScript. MPL/GPL/LGPL triple license. It is reliant on some SpiderMonkey extensions such as "const" and __proto__.

According to this 2004 June 15 post by Brendan, Narcissus is where JS2 is going:

  The new JS2 plan is to bootstrap off of the JS-in-JS project I started under js/narcissus. 
  More on that soon, but it's important to sync with the ECMA folks, 
  because Edition 4 may not be what was drafted last year.

Darron Schall's unnamed project

An apparently abandoned effort to make an ActionScript 1.0 compiler. See:

JavaScript 2.0 / ECMAScript 4.0

(There is no ECMA standard as of July 2004, so these implementations are just based on drafts.)

JScript .NET jsc

jsc is the JScript .NET compiler. It can produce a dll or exe from js files. The /fast option controls whether it forces variable declaration and other strict constraints.

It produces executables; you can run it like an interpreter via:

   jsc my.js && my.exe

For Windows, you can download the .NET SDK (which requires the redistributable .NET "Framework") from:

There is also the "Rotor" source release (under a "Shared Source" license) at It is buildable on Windows, FreeBSD, and MacOSX. Here is a recipe for building it (which includes getting some patches to make it work):

   curl | tar zxf -
   cd sscli
   # or the patch from
   tar zxf ssclipatch*.tgz
   patch -p1 < ssclipatch*.diff
   # this directory depends on what platform you are building on 
   cd build/v1.ppcfstchk.rotor
   # run the jsc compiler
   ./clix jsc.exe

On Mac OSX, you'll want to make sure you have the latest Apple gcc. You'll also want to make sure that there is no residue of Mono in your path (so it doesn't use the wrong "gacutil").

There is another project to maintain a Linux port of Rotor available from It seems targeted at RH 7.2, not 9.0. For me, it failed to compile with gcc-2.95 or gcc-3.3. It also failed with gcc-3.2, but it got further.

There is an early linux port of the "beta refresh" (earlier than 1.0) is at But I believe it is now a subset of the macadamian port.

Mono JScript

The Mono project ( ) has an antlr-based JScript .NET compiler, written by Cesar Octavio Lopez Nataren ( ) (see mcs-0.25/class/Microsoft.JScript/Microsoft.JScript/jscript-lexer-parser.g ) based on Steve Newman's Janet ( GPL, written in C#, at )

... except that in 2004 it seems they are now going to use a port of Rhino:

As of this writing (July 2004), they don't seem to have a JScript implementation fully working or released.

DotGNU JScript

The DotGNU project ( ) has a JScript .NET implementation by Rhys Weatherley: It is GPL, in C#. It relies on treeCC:

Packages may be found at The command line utility is called "jsrun". You need pnet-tools, pnet-interpreter, pnetlib.

As of this writing (July 2004), jsrun failed on the first three javascript files I tried it on, with spurious syntax errors, so I'd say it isn't yet ready for prime time.

ActionScript 2.0

Macromedia ActionScript 2.0 implements a much smaller subset of the JavaScript 2.0 draft than does JScript .NET, so there is no chance of source compatbility at the moment.

Amazingly, out of the box, the Macromedia development products such as Flash MX 2004 Pro apparently do not include a command-line ActionScript 2.0 compiler. There is an independent effort by a MM developer relations manager to supply this, called "FlashCommand":

  Windows -
  OSX -

The Flex product presumably does include some sort of command-line compiler.

Kinetic Fusion

See This apparently includes an ActionScript 2.0 compiler. It is a commercial product, written in Java.



It is an ECMAScript 4.0 implementation. It may be abandoned; see the note on "Narcissus" above.

It has a trees() top-level function to dump its parse trees.



It is being migrated to compatibility with EcmaScript Edition 4. It is LGPL, written in Java.