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?
And JavaScriptCore actually has very solid API, if not simpler.
MuJS: an embeddable JavaScript interpreter
21–30 of 57 posts
Re: MuJS: an embeddable JavaScript interpreter
#22How 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).
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).
Re: MuJS: an embeddable JavaScript interpreter
#23Coming from the Artifex people, I suspect MuJS will be used by MuPDF to implement PDF embedded JavaScript forms.
Re: MuJS: an embeddable JavaScript interpreter
#24Strange 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 key…
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).
Re: MuJS: an embeddable JavaScript interpreter
#25Maybe 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
Well, that's just Oracle being Oracle. They did the same nonsense with Opensolaris, if I recall correctly.
Re: MuJS: an embeddable JavaScript interpreter
#26Maybe 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…
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.
Re: MuJS: an embeddable JavaScript interpreter
#27Maybe 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…
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.
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.
Re: MuJS: an embeddable JavaScript interpreter
#28Earlier quoted context omitted.
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…
>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.
Re: MuJS: an embeddable JavaScript interpreter
#29Earlier quoted context omitted.
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.
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.
>> What's would you do instead of the stack-based API?
Did not see you answer the question here. You have a strong opinion, what would you like to see instead?
Re: MuJS: an embeddable JavaScript interpreter
#30So 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?
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."
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.