10 ms·

MuJS: an embeddable JavaScript interpreter

100 points by Fenume 12y ago

jszymborski 12y ago
Oh, is this from the ghostscript people?
kodablah 12y ago
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 12y ago
  How is that disingenuous? It seems pretty forthright about its licensing to me.
  - kodablah 12y ago
    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 12y ago
      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.
vgrichina 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      surely unit tests don't get compiled in?
- chj 12y ago
  And JavaScriptCore actually has very solid API, if not simpler.
chubot 12y ago
How does it compare with duktape: http://duktape.org/ http://duktape.org/ ?
- vortico 12y ago
  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 12y ago
  One immediately apparent difference: duktape has a more liberal and commercial friendly license (MIT), while MuJS has a much more restrictive license (AGPL).
  - yellowapple 12y ago
    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 12y ago
      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 12y ago
0x0 12y ago
Strange that the example has 'js_dofile("config.lua")'... Is there lua in here?
- xavel 12y ago
  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.
- passthefist 12y ago
  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.
  - yellowapple 12y ago
    I'm personally not a fan of Lua at all (nor am I a fan of Javascript...). That said, there are plenty of other options out there. Even for JS embedding, there are projects like duktape that already address this need (supposedly; I haven't personally used duktape in any of my projects).
  - namuol 12y ago
    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)
nothrabannosir 12y ago
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 12y ago
  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. :-)
  - nknighthb 12y ago
    > And what if those companies wish to provide their software to customers? They can abide by the free license, or pay for a different license. Or, yes, switch to a different library. They are not entitled to use this library, nor any other library. > No, the GPL, especially the AGPL is inherently bad for libraries. If this library were not available under any sort of open-source license, would you be making the same post, insisting it's "bad" for them not to give you free stuff?
    - xavel 12y ago
      >They can abide by the free license, or pay for a different license Or... use a library that suffers none of these issues. :-) My point is about the clause in the GPL that enforces developers to enclose the source of their entire software, not just the library. The LGPL however, does not require that, which is why the LGPL is also occasionally called "GNU Library License" (though the 'L' in LGPL stands for 'Lesser'). And lets not nitpick here, the GPL isn't exactly subtle about these things. >If this library were not available under any sort of open-source license, would you be making the same post, insisting it's "bad" for them not to give you free stuff? No. It's their right to choose whatever license they wish, but it's also my right to not choose their software.
robmccoll 12y ago
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 12y ago
  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 12y ago
    (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
    - j_s 12y ago
      Tessel also implemented a JS runtime incorporating LuaJIT, though they since chosen V8. https://github.com/tessel/runtime https://github.com/tessel/runtime https://tessel.io/blog/102381339917/a-new-engine-for-your-tessel https://tessel.io/blog/102381339917/a-new-engine-for-your-te...
    - Aldo_MX 12y ago
      > (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.
xavel 12y ago
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?
- anjbe 12y ago
  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 https://en.wikipedia.org/wiki/Berkeley_DB#Licensing
  - xavel 12y ago
    Well, that's just Oracle being Oracle. They did the same nonsense with Opensolaris, if I recall correctly.
- chubot 12y ago
  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.
  - xavel 12y ago
    The grand majority of programming language APIs do not use a stack-based API. Really, stack-based APIs are an exception in just about every way, but not in a good way. If your question is about cheap memory storage, linked list algorithms already exist, so there's really no good reason to use a faux stack to store data.
vorbote 12y ago
Coming from the Artifex people, I suspect MuJS will be used by MuPDF to implement PDF embedded JavaScript forms.
Julio-Guerra 12y ago
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 ;)
dmytrish 12y ago
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

100 points by Fenume 12y ago

Oh, is this from the ghostscript people?

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 12y ago
How is that disingenuous? It seems pretty forthright about its licensing to me.
- kodablah 12y ago
  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 12y ago
    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.

vgrichina 12y ago

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 12y ago
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 12y ago
  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 12y ago
    surely unit tests don't get compiled in?
chj 12y ago
And JavaScriptCore actually has very solid API, if not simpler.

chubot 12y ago

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

vortico 12y ago
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 12y ago
One immediately apparent difference: duktape has a more liberal and commercial friendly license (MIT), while MuJS has a much more restrictive license (AGPL).
- yellowapple 12y ago
  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 12y ago
    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 12y ago

0x0 12y ago

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

xavel 12y ago
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.
passthefist 12y ago
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.
- yellowapple 12y ago
  I'm personally not a fan of Lua at all (nor am I a fan of Javascript...). That said, there are plenty of other options out there. Even for JS embedding, there are projects like duktape that already address this need (supposedly; I haven't personally used duktape in any of my projects).
- namuol 12y ago
  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)

nothrabannosir 12y ago

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 12y ago
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. :-)
- nknighthb 12y ago
  > And what if those companies wish to provide their software to customers? They can abide by the free license, or pay for a different license. Or, yes, switch to a different library. They are not entitled to use this library, nor any other library. > No, the GPL, especially the AGPL is inherently bad for libraries. If this library were not available under any sort of open-source license, would you be making the same post, insisting it's "bad" for them not to give you free stuff?
  - xavel 12y ago
    >They can abide by the free license, or pay for a different license Or... use a library that suffers none of these issues. :-) My point is about the clause in the GPL that enforces developers to enclose the source of their entire software, not just the library. The LGPL however, does not require that, which is why the LGPL is also occasionally called "GNU Library License" (though the 'L' in LGPL stands for 'Lesser'). And lets not nitpick here, the GPL isn't exactly subtle about these things. >If this library were not available under any sort of open-source license, would you be making the same post, insisting it's "bad" for them not to give you free stuff? No. It's their right to choose whatever license they wish, but it's also my right to not choose their software.

robmccoll 12y ago

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 12y ago
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 12y ago
  (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
  - j_s 12y ago
    Tessel also implemented a JS runtime incorporating LuaJIT, though they since chosen V8. https://github.com/tessel/runtime https://github.com/tessel/runtime https://tessel.io/blog/102381339917/a-new-engine-for-your-tessel https://tessel.io/blog/102381339917/a-new-engine-for-your-te...
  - Aldo_MX 12y ago
    > (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.

xavel 12y ago

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?

anjbe 12y ago
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 https://en.wikipedia.org/wiki/Berkeley_DB#Licensing
- xavel 12y ago
  Well, that's just Oracle being Oracle. They did the same nonsense with Opensolaris, if I recall correctly.
chubot 12y ago
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.
- xavel 12y ago
  The grand majority of programming language APIs do not use a stack-based API. Really, stack-based APIs are an exception in just about every way, but not in a good way. If your question is about cheap memory storage, linked list algorithms already exist, so there's really no good reason to use a faux stack to store data.

vorbote 12y ago

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

Julio-Guerra 12y ago

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

dmytrish 12y ago

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