How does it compare with duktape: http://duktape.org/ ?
One immediately apparent difference: duktape has a more liberal and commercial friendly license (MIT), while MuJS has a much more restrictive license (AGPL).
MuJS: an embeddable JavaScript interpreter
11–20 of 57 posts
Re: MuJS: an embeddable JavaScript interpreter
#12If 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.
Re: MuJS: an embeddable JavaScript interpreter
#13Maybe 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?
Re: MuJS: an embeddable JavaScript interpreter
#14I 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 reser…
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. :-)
Re: MuJS: an embeddable JavaScript interpreter
#15Strange that the example has 'js_dofile("config.lua")'... Is there lua in here?
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.
Re: MuJS: an embeddable JavaScript interpreter
#16Strange that the example has 'js_dofile("config.lua")'... Is there lua in here?
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.
Re: MuJS: an embeddable JavaScript interpreter
#17I 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 reser…
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.
Re: MuJS: an embeddable JavaScript interpreter
#18I 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 reser…
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…
> 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?
Re: MuJS: an embeddable JavaScript interpreter
#19I 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 reser…
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.
Re: MuJS: an embeddable JavaScript interpreter
#20Maybe 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 lik…
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