Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MuJS: an embeddable JavaScript interpreter

mujs.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: MuJS: an embeddable JavaScript interpreter

#41

Post by sesquipedalian »

jaen wrote: post #37
xavel wrote: post #13

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

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

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.

Re: MuJS: an embeddable JavaScript interpreter

#42

Post by Aldo_MX »

robmccoll wrote: post #12

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.

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

Re: MuJS: an embeddable JavaScript interpreter

#43

Post by nknighthb »

xavel wrote: post #33
nknighthb wrote: post #31

Earlier quoted context omitted.

> My point is about the clause in the GPL that enforces developers to enclose the source of their entire software, not just the library. I'm well aware of it. Everybody is. It's a term of the license. Just like "You must pay us $5000 to use this library" would be. > And lets not nitpick here, the GPL isn't exactly subtle about these things. Nitpick about what? Subtle about what? What are you talking about? > No. It's…

> Nitpick about what? Subtle about what? What are you talking about? The clause I mentioned. I'm sorry if I was ambigious, but there were discussions in the past hovering about how the GPL still allows commercial software, and such. Yes, of course the GPL allows you to make good money, but in just about every example given, the actual bulk of the money isn't made from the software, but from the hardware the software…

If your problem is one of semantics, please be honest about that up-front, instead of instigating drawn-out arguments.

Re: MuJS: an embeddable JavaScript interpreter

#44

Post by ralmidani »

nothrabannosir wrote: post #34
xavel wrote: post #14

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

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.

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

Re: MuJS: an embeddable JavaScript interpreter

#46

Post by anentropic »

xavel wrote: post #30
chc wrote: post #6

Earlier quoted context omitted.

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.

surely unit tests don't get compiled in?

Re: MuJS: an embeddable JavaScript interpreter

#47

Post by copx »

nothrabannosir wrote: post #10

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

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

Re: MuJS: an embeddable JavaScript interpreter

#48

Post by justincormack »

Aldo_MX wrote: post #42
robmccoll wrote: post #12

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.

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…

(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

Re: MuJS: an embeddable JavaScript interpreter

#49

Post by amelius »

Aldo_MX wrote: post #42
robmccoll wrote: post #12

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.

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…

Also, how can we run Lua in the browser? And how does it compare to "native" javascript in terms of performance?

Re: MuJS: an embeddable JavaScript interpreter

#50

Post by j_s »

justincormack wrote: post #48
Aldo_MX wrote: post #42

Earlier quoted context omitted.

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…

(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

Tessel also implemented a JS runtime incorporating LuaJIT, though they since chosen V8.

https://github.com/tessel/runtime

https://tessel.io/blog/102381339917/a-new-engine-for-your-te...

Post reply on HN