On Thu, Nov 10, 2011 at 2:20 AM, Philippe Lhoste
<PhiLho@gmx.net> wrote:
If I understood correctly each project (from their description), lua2js (official name?) translates Lua code to JS code (a bit like what Xtend compiler does to Java, or lot of compilers in general do, using often C as target language), while Emscripten translated the C code of the Lua VM to _javascript_, interpreting Lua on the fly (would be like rewriting another JVM, to continue the analogy).
Yes.
So, if I am not mistaken, Emscripten is able to run Lua code typed in the browser without assistance from a server, while lua2js would need to send the script to a server with a Python module to translate the code and send it back to the browser. Right?
Both approaches are interesting. As I believe the Emscripten was generated (by LLVM?), it should have a complete support of Lua features, but need to run a heavy machinery, not necessarily optimized for its target language (C idioms/pattern/tricks used in the Lua code might not be optimal for JS) to run the scripts, while lua2js probably generate a lighter JS and this code can be heavily optimized by the browser's engine.
The non-runtime restriction is not there anymore since Lua code can now be compiled at runtime, of course.
It's much, much, much lighter. You don't have to take my word for but consider that using the Emscripten method executes Lua code by running in a basic Lua interpreter running in an environment that partially simulates executing LLVM bitcode running in a _javascript_ interpreter. It might be fine for projects that don't require much speed, but I needed something faster.
Lua and _javascript_ are obviously still very different languages, but the resemblance is close enough that I can use local variables and functions in almost the exact same way. If not, this manner of running Lua code would not work. I'd say the only two major differences are the api and the use of metatables in Lua.
Two interesting approaches.
I recall a failed attempt, some years ago, to make Lua to run natively (or with a plugin) in browsers, but the modern approach of using JS as the assembly language of browsers is probably saner, now that we have HTML5 (canvas and other facilities).
By saner, I don't mean it is a good idea, just that we don't have a choice (no standard bytecode here), if we want high compatibility, and well, it becomes usage, given the recent progress in JS engine speed.
My project emphasizes speed over compatibility, since I needed speed more and emscripten couldn't give me that, but a much faster emscripten-less _javascript_ version that fully emulates the Lua VM could exist.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
