MuJS: an embeddable JavaScript interpreter

[chubot]

How does it compare with duktape: http://duktape.org/ ?

[robmccoll]

One immediately apparent difference: duktape has a more liberal and commercial friendly license (MIT), while MuJS has a much more restrictive license (AGPL).

[vortico]

I was wondering the same. It's nice having an alternative though. I consider there to be two C embeddable Javascript interpreters, Duktape and MuJS now. V8 and Spidermonkey are great, but they are not acceptable for small projects where a simple scripting language to extend functionality is needed.

[robmccoll]

If you are considering using this, please consider using Lua instead. Lua has decent performance on its own, great performance for a scripting language when using LuaJIT, plays well with others, is insanely embeddable, and is much easier to learn and work with. No language is perfect, but Javascript is a bit mediocre.

[Aldo_MX]

You are making assumptions about the needs of a project to endorse your favorite language.

Remember that languages are tools, not sport teams.

There are needs that completely disregard any of the benefits you mentioned with lua, for example:

  a) How can Lua help me run existing JavaScript code?

  b) Why is Lua more cost-effective than embeddable JavaScript interpreters considering the
     following:
     1. the cost of learning how to embed and work with the Lua interpreter
     2. the cost of learning the scripting language with all its implications: a different
        syntax, a different way to work enforced by its standard library (ex. 1-indexed
        arrays), new quirks (ex. commenting nested arrays), etc.
     3. the cost of training people from other areas which are already accustomed to
        JavaScript

[vorbote]

Coming from the Artifex people, I suspect MuJS will be used by MuPDF to implement PDF embedded JavaScript forms.

[nothrabannosir]

I see hate for the licensing model they chose. But think of it this way: who is their target audience? Who would want a small, embeddable JS engine? I think they're targeting businesses who want to deploy node.js code on micro to small devices. Routers, NASes, that sort of thing.

In that light, it's great they even decided to publish the source under AGPL at all. They could just as well have kept it "all rights reserved".

[xavel]

And what if those companies wish to provide their software to customers? Enter a terrible hell of "how are we going to relicense our stuff", that'll most likely end up with said companies switching to a different library.

No, the GPL, especially the AGPL is inherently bad for libraries. Libraries, mind you, not software in general. Like I've written in my other comment, the LGPL solves this issue painlessly.

Besides that, node.js won't run with MuJS, because node.js depends on V8 and libevent. Unless some poor sod actually reimplements the entire nodejs stack... but I hope people are smarter than that. :-)

[rossy]

The AGPL is a pain though. MuJS was going to be used to add JS scripting to mpv, but the patch has been put on hold since the devs realised it was AGPL licensed and it could cause license compatibility issues with compiled binaries or libmpv users. I don't think MuJS will be used by anyone outside of GhostScript until they change their license to a more reasonable one.

[maemre]

Routers already use GPL'd software (Linux for example). However, I don't know effects of using AGPL over GPL in this case. I can see that without a linking exemption saying that _linked_ JS code is not subject to license terms, it wouldn't allow using proprietary JS code. But, what are the consequences of choosing AGPL over GPL?

An irrelevant anecdotal note: Router firms can make distribution of source code harder to circumvent GPL. A router firm that a friend works distributes source code using CDs. So if you bought a router and wanting the source code for modified kernel etc., you send your request using email/telephone/mail/fax and get your own copy via snail mail.

[copx]

>I see hate for the licensing model they chose. But think of it this way: who is their target audience?

People willing to pay for a commercial license.

Many companies which want to sell software release a GPL-ed version as a kind of demo (and being able to add the "open source" buzz word to the description of their product does not hurt either).

That the (A)GPL makes this library unusable for most people is the reason why they chose that license; not because of Free Software idealism but because of commercial interests.

[xavel]

Maybe it's just me, but I'm not a particular fan of Lua-inspired pseudo-stackbased APIs.

I'm not sure why so many language devs insist on this terrible design. I fail to see anything good about it; It doesn't make the code smaller, it doesn't make the code faster, but it does make abstraction a royal pain in the buttocks.

Also, they couldn't have possibly chosen a worse license for a library that is going to most likely embedded statically in a program. Of all licenses, why AGPL? If it has to be GPL (whyever is none of my concern), why not LGPL?

[jaen]

Explicit stack-based interfaces are used for good reason: This allows simple accurate garbage collection (see eg. the Ruby API which requires somewhat error-prone conservative GC, Python which requires refcounts all over the place, or OCaml which requires annotating all local variables in a special block). A custom frame stack is also needed to have coroutines in pure ANSI C (two of the reasons Lua is popular).

[anjbe]

The intent is clearly to promote sales of commercial licenses. Similar to why Oracle relicensed Berkeley DB from BSD to AGPL: “As of July 2011, Oracle's list price for non-copyleft Berkeley DB licenses varies between 900 and 13,800 USD per processor.” https://en.wikipedia.org/wiki/Berkeley_DB#Licensing

[chubot]

What would you do instead of the stack-based API? That's the best design there is AFAIK.

Lua started out with something like Python's API (Lua 3.0 I think), but they changed it to use the explicit context and stack.

[sesquipedalian]

Agreed. The biggest drawback IMHO is you defer errors that could have been caught at compile time to runtime if you had a saner interface.

[vgrichina]

So I guess this is slower than JavaScriptCore and you have to get commercial license to actually embed it. Why would one choose it at all?

[chc]

From the linked site:

"Why? Because V8, SpiderMonkey and JavaScriptCore are all too big and complex. MuJS's focus is on small size, correctness and simplicity."

[chj]

And JavaScriptCore actually has very solid API, if not simpler.

[kodablah]

I understand the AGPL and the want to monetize the work, but it just feels so disingenuous to have to contact for commercial details.

[chc]

How is that disingenuous? It seems pretty forthright about its licensing to me.

[jszymborski]

Oh, is this from the ghostscript people?

[dmytrish]

Pretty good implementation:

    > [] == []
    false
    > [] + []

    > {} + []
    0
    > [] + {}
    [object Object]
    > {} + {}
    NaN

Although it fails in this part (should be [10, NaN, 2]):

    > [10, 10, 10].map(parseInt)
    10,0,2

[0x0]

Strange that the example has 'js_dofile("config.lua")'... Is there lua in here?

[passthefist]

Which begs the question: why not use Lua to begin with, at least when starting a project? I totally get the use for this if you've got some existing JS and for some reason you need to talk to C. I've seen crazier things.

But I'd say the solution to 'I need a scripting language to talk to C' is solved very well by Lua.

*Edit:

After looking at the example it's C API is surprisingly similar to Lua's, even using such keywords as userdata. So that's interesting, considering they're really similar languages.

The function js_dofile doesn't look like it's doing anything with lua, nor can I find any use of lua at a cursory look at the source. I'd guess that since Lua and JS share syntax they are loading a .lua file with valid JS syntax.

[xavel]

I noticed that too. My theory is that MuJS started out as a fork of Lua, with all sorts of Ecmascript-compat bolted on. Use with care, I suppose.

[Julio-Guerra]

I just embedded it on a PowerPC P2020DS processor as a baremetal program (using the newlib and by stubbing the syscalls) and it works, I get a baremetal javascript interpreter ;)