It's probably cheating a little to just grab an existing Javascript interpreter written in C++, compile that with emscripten and call it a Javascript interpreter in Javascript. When you compile C++ code, do you say that the program is in Assembly?

Agreed, it's partially cheating, although a lot of work went into getting it to compile to LLVM and patching it work with Emscripten. That's not where it stops though. The plan is to make the library work just like the SpiderMonkey JS API, which will require wrapper scripts in JS.

This appears to be the same goal as https://github.com/mozilla/narcissus/ but substantially less clever.

Isn't Narcissus primarily for developing Harmony features?

Other than prototyping new JS features (or to say you did it), what's the use? It will never come close to being fast enough to be a viable alternative, like PyPy is.

err... what's the goal of the featured link, js.js? It's even worse--all of Spidermonkey compiled to llvm and then to javascript.

Any thoughts as to applications for this? At ~65MB, I don't see this getting used client side.

I don't even think the worst part is the download (which can be cached). The worst part is the fact that you're running your script, interpreted by a weirdly generated unoptimized script, interpreted by a scripting engine which only then runs on metal. I'm shooting in the dark, but I'd bet the performance and memory usage would be a disaster for anything but Hello, world.

Actually, right now, even Hello world is a disaster. My guess is that this will drive some interesting improvements to emscripten and LLVM so there may be some benefits down the line.

There's also going to be an enormous startup time as it has to parse and compile all that code, even if it's already cached.

65MB is our current unoptimized, uncompressed version. I expect the final version to be around 5-10MB. Still large, but not quite as bad.

I'm not super familiar with Narcissus in practice, but on paper your projects sound very similar. Were there any interesting reasons why you opted to make this project instead?

We wanted the full power of the SpiderMonkey JS API and maximum browser compatibility.

i can see some possible for this where you could add support to your application for plugin development or even macro-type scripting within a sandbox.

I believe this is how Cobb and Saito slipped into Limbo.

Or how another cheap "Yo dawg" joke started.

The best part is that the blob is too big to explore on github.

There are plenty of things I've done in my life that didn't make a lot of sense, but I did them just because I could. I'll happily put js.js in the same bucket and give props for creativity over usefulness.

Page seems to be missing a "why?" section. Seriously, why? What does it do that eval() doesn't?

It's similar to the metacircular Scheme interpreter in Scheme in SICP. It's not that interpreting JavaScript in JavaScript (especially if that JavaScript is running on a full-blown and more efficient interpreter itself) is a practical end, but that it demonstrates a concept: language as data and data as language. As an implementation, it is merely interesting -- but imagine writing code in a language closer to the problem domain you're working with that just happens to run on JavaScript.

These kinds of things always make me think of PyPy and its snake-eating-itself (ouroboros) logo.

so eval() written in js?

Not quite. It will support everything that SpiderMonkey's API supports when embedding the interpreter into a C++ application. Much more powerful than eval().

A very good example of Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.

Somehow I don't think this really counts as "written in JavaScript."

> Instead of trying to create an interpreter from scratch, SpiderMonkey is compiled into LLVM and then emscripten translates the output into JavaScript.

Heh, this is pretty much the epitome of hacking: needlessly complicated, ultimately pointless, but still awesome, clever and inspiring.