Split out from MuPDF, MuJS is AGPL v3 licensed and can be found at mujs.com and source in the ghostscript.com repository.

It claims to be similar to Lua in that it's "as simple as possible to use" and about ~10K lines of C to include. Seeing as how successful recommending Duktape became I thought I'd pass along another "small" embeddable JS engine. It's very clearly not optimized for speed, but it looks similarly as simple as Duktape if the examples are any indication.

Like Duktape, I hate that it's C and not C++, as I'd love to see this objectified simply instead for simplicity. Seeing all those .c files bugs me, and I'm pretty sure there could be some combining happening. I may attempt it as a summer project or something.

edit - corrected GPL to AGPL +neo

Haha, you hate C and I hate C++.  I feel like C++ is one of those "jack of all trades, master of none" type languages.  It tries to be too many things at once and, in my opinion, doesn't really do any of them well.  Besides that the C header/source dichotomy doesn't lend itself very well to encapsulation.  There's something very wrong about having to put private class members in the public header--sure, you have the pimpl idiom, but that's a hack.  It really should be built into the language.

I'll stick to C thank you. :-)

If you want C++ for it's classes and OOP, I'd just use C# and Mono.

MuJS looks neat, but now I worry about performance. Games we now know are very demanding. All of our newer engines have no issue with graphics, sound and input but you don't have a fast JS engine, you can say goodbye to some effects, unless they are provided through an interface to a more powerful native language.

For what it's worth, I haven't really had any performance complaints with Duktape.  I was starting to feel the crunch in Sphere 1.5 because of the old Spidermonkey engine, but even without a JIT, Duktape seems plenty fast enough for an engine like Sphere.  I mean yeah, I guess if you're doing physics or something in script, sure, but for the most part modern games don't tend to be particularly CPU-bound.  There's no way Sphere 1.5 would have survived this long otherwise!

I mean look at Lua:  that's fully bytecode interpreted, and was specifically /designed/ for use in games.

I mean look at Lua:  that's fully bytecode interpreted, and was specifically /designed/ for use in games.

Yeah, I've seen Lua used in games. It rather is used to drive the logic of game states, not the game itself. These are the types of games whose physics and core game animations (etc.) are coded in C++ but gameplay nuances are programmed in Lua. It's used on a more complementary level than the JS in Sphere. The JS in Sphere could be more like that, but then we'd really have to flesh out a fully-featured gaming library that handles all you can throw at it engine-wise in C++, while keeping games strictly to JS. Particle Engine, Physics, Spriting, and IO are the four really main areas to keep native-side, with the first one being a fusion of the middle two, but separated due to it's complexity.

Take Magic the Gathering Duels of the Plainswalkers game. The core engine is C++ but the AI for card behavior is all Lua, since they didn't need that to be unreasonably fast and in a scripted language I guess the developers felt it could more easily be changed and adapted. Many games are like this like the MMO Tibia, which I know with hands on experience with it's game code (don't ask how).

Actually, I think that a proper physics library and particle system native-side could easily top off Sphere. It's the area I'm usually worried about in terms of performance script side and to see that carried off in native would be really nice. Especially physics, all good games respect good physics, from anything like hitting an enemy in a zelda styled game to jumping off a 2D platform, from space shooters to puzzle games.

So after derailing the topic , I finally clicked the link to look at this.  I have to say, the API is ridiculously simple, even simpler than Duktape, and would be trivial to get started with.  I'm kind of glad this wasn't pointed out to me before Duktape, or I probably would have built minisphere with this.

As for why that would be bad: Looking at the Git repo for MuJS, the developer is clearly a lot less active than Duktape's dev.  The latter literally responds to almost all issues within 24 hours.  That's how I got several hotfixes to let me improve minisphere's error reporting, which was subpar when I started due to Duktape limitations/bugs but now works awesomely.  If what I'm seeing is any indication, I doubt I'd get that kind of response from this guy...

Edit: Also, the AGPL license is a killer for me.  Every single component of minisphere is MIT/zlib licensed right now and I rather like it that way.  I despise "viral" copyleft licenses like the GPL.

This is really one of the keys to the Sphere engine. It puts script as the first class citizen. Almost no other engine really does that. We need powerful JS engines because we use powerful JS

We actually are in a really good position for the more powerful JS engines, like V8 and SpiderMonkey. When I was learning about SM, I had a look at 0 AD. They use SM like you would Python or LUA, and they have horrible performance issues. They constantly create and destroy contexts, and do relatively little inside each individual one.

Sphere tends to actually use a JS engine more like the browser engines are intended to be used, with each context being a single presentation. In this way, you can kind of think of Sphere's JS compared to how 0 AD and many other games use script as how Windows and Unix handle threads and processes. LUA and Python are like Unix, where starting a new process/context is cheap, and threads/calls are pretty cheap too. Browser-based JS engines are like Windows, a process/context is very expensive, but threads/calls are cheap.

That's how I visualize it, at least.

I actually talked to the 0 AD folks. Some knew that they were using SM in a way it wasn't meant to be used. Others told me it was silly and unrealistic to use a context for more than a single operation because JS in totally incapable of preventing name collisions. Perhaps they are just set in their ways and don't want SM to be any different from LUA, perhaps they just don't like having to protect the global namespace. In a situation where you are in total control of what JS runs in your game, I don't even see that as a real argument. It's like saying C is useless because it has no name mangling.

EDIT:
Re physics, I've run Box2D in TurboSphere using Emscripten, both in V8 and SM. It honestly is too slow to do in script just yet. Maybe a simplified physics model would work, but for something more intense you still need native.

Holy crap MuJS is slow.  Look at these benchmarks done by Duktape's dev:
https://github.com/svaarala/duktape/issues/138#issuecomment-86065937

Most of them are an order of magnitude difference in Duktape's favor, sometimes 2(!).