UPDATE: the patch has landed, and nightly builds now get put posted here beside the Firefox nightly builds.
One of the tools I use on a daily basis is the SpiderMonkey JavaScript Shell. “But Dave,” you say, “I also use SpiderMonkey every day…in Firefox!“ Right, but I’m talking about the command-line shell. It is invaluable to my work as a browser and web developer; so much so that I want to get you using it, too. And! I’ve made it drop-dead easy…more on that below.
The first time I saw the shell used was many years ago on irc. I remember asking a question about JavaScript, and Vlad pasting a response that included output with a funny “js>” prompt in it. It blew my mind. Here was a way for me to test things quickly without having to write a whole web page. Since then I’ve always had one open in a terminal.
Another way that I use the shell is for various automated test systems we have for projects like Processing.js. Using the shell with a Makefile, we have a fast and easy way to run the thousands of parser and unit tests we have.
So if this is such a useful tool, why aren’t you using it already? The answer is that Mozilla doesn’t produce binaries. You have to build Firefox and/or SpiderMonkey to get a working shell. For all the Mozilla developers I talk to, that’s no problem–we all have build environments setup, and build this code on a daily basis. It’s as simple as objdir/dist/bin/js.
But for the web developers I work with, this is a lot to ask. Most of them think I’m crazy when I tell them to build C/C++ code in order to get this shell. Sure, there are other JS Shells you can use. But I don’t want to use Java, and ideally I want to have the same JS engine on the command-line that I’ll use in the browser. Better still, I’d like to have access to the latest and greatest fixes and new features being added to the JS engine shipping in Firefox.
To solve this, I filed a bug and wrote a patch to package the js shell binaries we build when we create nightly builds, and have this get uploaded where people can easily download them. Ted just landed it in the build-system branch, while will find its way into mozilla-central, tracemonkey, etc when there is a merge.
In the meantime, I have try server builds you can get here. I’d encourage you to read the excellent docs for the shell, which has many features not available from within the browser, and useful for automated testing, loading external programs, etc.
Python devs know how valuable it is to have an interactive shell at the ready, and now JavaScript devs can do the same.
13 Comments
Most excellent … thanks!
Quick question … is this the latest JavaScript Engine in FireFox?
I tested against the V8 benchmarks and I get vast differences in speed when running the js.exe (much,much slower) versus firefox 4?
You have to be careful how you test. When you run your code, you have to turn on the various JITs as desired (they are off by default).
# Run foo.js through the interpreter
$ js -f foo.js
# Run foo.js with TraceMonkey tracing JIT
$ js -j -f foo.js
# Run foo.js with JaegerMonkey method JIT
$ js -m -f foo.js
# Run foo.js with loop profiling for TraceMonkey
$ js -p -f foo.js
# Run foo.js with all JITs (similar to how the browser runs)
$ js -m -j -p -f foo.js
See js –help for more details.
From irc:
[billm] humph: not quite. using -p alone doesn’t do anything. it’s only useful along with -m -j. also, using -m alone doesn’t *always* use the methodjit. it may spend a lot of time in the interpreter. you can use -m -a to use the methodjit as much as possible.
Thanks David … that does the trick!
Thanks again for providing this … how/where do I get these builds on a regular basis?
I think they’ll go in https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ when this lands in mozilla-central. I’ll tweet the link when that happens.
You don’t need the ‘-f’ either! Just “js foo.js” will work.
Outstanding, thanks for doing this!
I remember using spidermonkey to do (very simple) unittests for stuff like http://mxr.mozilla.org/mozilla/source/testing/tools/pageloader/
Ubuntu/Debian provides a “spidermonkey-bin” package, but this will make it much easier for people on other platforms or who want to test with bleeding-edge stuff. Looking forward to seeing more scripts beginning with “#!/usr/bin/js”
How is that patch of yours different from what Linux distros have been doing for a long time?
$ rpm -qf $(which js)
js-1.8.5-4.fc15.x86_64
$ js
js> version()
185
js>
How about doing it non-Linux, too? I don’t remember writing “Linux Sucks” above; why the hate? Keep using your shell. I’m just giving more people what you already have.
My Javascript development experience comes mainly from using frameworks such as jQuery.
So what am I missing when I do the following?
$ js jquery-1.6.1.min.js
jquery-1.6.1.min.js:18: ReferenceError: window is not defined
Okay, so the command line SpiderMonkey doesn’t have a window, so are there times you can’t compile Javascript on the command line?
You have no DOM outside the browser. You can use things like http://www.envjs.com/ to shim a DOM replacement in, if necessary.
Glad someone’s taken the time to make the shell available to a wider audience. Well done.
One thing that would make it nicer to handle though is if the library files were packaged into the executable so there’s only one file to move around.
Also maybe it a single “use the same performance optimizations as firefox” command line argument should be added so it’s easy for people who’re interested to reliably get that?
Dave, this is so great. Exactly what I was looking for the other day. Thank you so much!