
MuJS: an embeddable JavaScript interpreter - Fenume
http://mujs.com/
======
chubot
How does it compare with duktape: [http://duktape.org/](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).

~~~
yellowapple
This is a pretty big deal for me. MuJS is a non-starter if I can't even use it
in GPL'd software (let alone copyfree-licensed software; my preference for my
own projects is the MIT license, so being able to include something without
having to change that - as duktape offers - is ideal).

~~~
LukeShu
Sure you can use it with GPL'd software[0] or MIT licensed software! It
doesn't stop the GPL from applying to any GPL'd code, nor the MIT license to
any MIT'd code. The AGPL does say that when it is used, the sources must be
available to the users; but that doesn't mean that when someone takes your
(MIT or GPL) code and changes it, and uses it [without MuJS or other AGPL
code], that the AGPL applies.

[0]: GPLv3, that is. Fortunately, most GPL stuff is "v2, or at your option,
any later version." Unfortunately, there is quite a bit of just v2 stuff out
there.

~~~
yellowapple
AGPL code can be dynamically linked to GPLv3 code. That's about the extent of
their compability. Statically linking MuJS in even a GPLv3-licensed program
would be a violation of at least one or the other, and virtually all other
cases of linking - dynamic or static - with AGPL code would also be a
violation of at least the AGPL (and possibly the other license, depending on
its terms).

So yeah, sure, you can incorprate MuJS in an MIT-licensed project, but by
doing so, you're effectively required to license the entire work (your code +
MuJS) under the AGPL (or a license - like the GPLv3 - that's explicitly
authorized for dynamic linking; this, again, doesn't apply for static
linking).

------
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

~~~
justincormack
(a) Tessel produced a pretty complete open source JS to Lua converter, which
runs node[1]

(b) People are not dumb, they can learn Lua. It is easier than learning
JavaScript.

[1] [https://github.com/tessel/colony-
compiler](https://github.com/tessel/colony-compiler)

~~~
Aldo_MX
> (b) People are not dumb, they can learn Lua. It is easier than learning
> JavaScript.

I was not saying that people is dumb, I was saying that learning it requires
extra time and effort, and that increases the cost of a project.

------
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. :-)

~~~
nothrabannosir
Guys, it's _double licensed_. You are describing exactly the point: they don't
want companies to use this without paying. Pay, and you can redistribute it to
your clients.

This is basically for-profit code from a for-profit company, with a side dish
of "open source for open source projects." It's like... like Github. Like
Travis-CI. Like QT.

~~~
ralmidani
> Guys, it's double licensed. You are describing exactly the point: they don't
> want companies to use this without paying. Pay, and you can redistribute it
> to your clients.

Or you can release your code under the AGPL and keep all your money.

> This is basically for-profit code from a for-profit company, with a side
> dish of "open source for open source projects." It's like... like Github.
> Like Travis-CI. Like QT.

This is not like Github. Github does not release all of the source code
powering their app.

------
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).

~~~
sesquipedalian
I don't believe non-stack based APIs prevent the implementation of the
features you just mentioned. You don't necessarily have to expose the
underlying stack manipulation routines as your defacto API although it is
easier to do so. My gripe with this technique is that it makes it much harder
for the compiler to catch errors. Personally, I think it would be better to
expose the API as helper functions that compose (and hide) the underlying
stack routines.

------
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."

~~~
xavel
About 'correctness' and 'small size' ... as soon as they'd add unittests as
extensive as V8, JSCore, or SpiderMonkey, it'd grow big quite dramatically.
:-)

I'd be interested to see how ES5-compliant MuJS really is. My guess is
probably different from what they claim.

~~~
anentropic
surely unit tests don't get compiled in?

------
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.

~~~
kodablah
Because they have to be contacted to determine a price instead of making
pricing clear. (I am not saying that they will not price consistently, I'm
just saying it's a bit off-putting)

~~~
chc
That's pretty common in enterprise sales. It's a way to have some leverage in
implementing pricing gradients. For example, you might want to charge $200k to
Microsoft for a given technology, but charge much less to an indie game
company since there's no way in hell they could swing $200k for whatever
you're selling. Different companies often even want different terms in their
contract, so it makes decent sense.

------
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.

~~~
namuol
Seeing as this was built by the creators of MuPDF [1], I'm guessing they built
this because they _need_ to use JS to support embedded JS forms.

1: [http://www.mupdf.com/](http://www.mupdf.com/) (artifex)

------
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 ;)

