

Lua to Javascript translator - Bambo
https://github.com/mherkender/lua.js

======
leafo
This is a cool project, but sadly it's not a complete Lua. It's missing two of
Lua's most powerful features:

A lot of the metatable functionality just won't work:
<http://www.lua.org/manual/5.1/manual.html#2.8>

Second, it's missing co-routines. Which is a way to suspend the execution of a
piece of code.

These features aren't possible in a compiler that simply translates from Lua
to JS because JS doesn't have the ability to reproduce these concepts in its
own constructs. You would have to output significantly different code to
simulate these features.

Without these you're just writing JavaScript in another dialect.

~~~
ufo
Looks like the only metatable stuff they don't dupport is weak references and
garbage collection hooks (finalizers/destructors) Other then that t looks like
the support most of the other stuff since table access and things like tha
through intermediate functions such as lua_tableget and so on.

------
snprbob86
Very cool project!

I know that this is somewhat off topic, but I'm thinking about this from the
perspective of the ClojureScript compiler. The translation snippets in the
Lua.js README make me really thankful for the design of Clojure. It's highly
amenable to compilation. As a result ClojureScript is able to produce
extremely well optimized output. For simple cases, the translation is no more
unreadable than CoffeeScript. But even for complex cases, the performance is
excellent because most forms compile to relatively plain & boring javascript.

    
    
        Lua      init(1, 2, 3)
        Lua.js   lua_call(lua_tableget(lua_script, "init"), [1, 2, 3]);
        CLJ      (init 1 2 3)
        CLJS     cljs.user.init.call(null, 1, 2, 3)
    
        Note that cljs.user is the default namespace in the ClojureScript REPL.
    
        Lua      local numActive = activeChars.count
        Lua.js   var numActive = lua_tableget(lua_tableget(lua_script, "activeChars"), "count")[0];
        CLJ      (let [num-active (.-count active-chars)])
        CLJS     var num_active__10317 = cljs.user.active_chars.count;
    
        Lua      local distFromCenter = get_distance({x=1, y=2})
        Lua.js   var distFromCenter = lua_call(lua_tableget(lua_script, "get_distance"), [lua_newtable(null, "x", 1, "y", 2)])[0];
        CLJ      (let [distance-from-center (get-distance {:x 1 :y 2})])
        CLJS     var distance_from_center__10322 = cljs.user.get_distance.call(null, cljs.core.ObjMap.fromObject(["\ufdd0'x", "\ufdd0'y"], {"\ufdd0'x":1, "\ufdd0'y":2}));
    
        Lua.js wins on that last example, but if you need more speed, you can get it. All of the JavaScript primitives are exposed with highly performant macros:
    
        CLJ      (aget (js-obj "x" 1 "y" 2) "x")
        CLJS     ({"x":1, "y":2}["x"])

------
jballanc
Lua is a better language than Javascript in every possible way. I have half-a-
mind to hack LuaJIT into Webkit, but I'm afraid that it may be futile at this
point. The biggest shame in all of web development is the "type" attribute on
the HTML "script" tag...

~~~
gruseom
_I have half-a-mind to hack LuaJIT into Webkit_

I've been thinking for a while that Lua and especially LuaJIT are so good that
there might exist a strategy to do an end run around vendors and get LuaJIT
into browsers as (initially) a plug-in. It's possible that there's a killer
app waiting to be written that could run well in LuaJIT (but not JS) and that
this could drive installation of such a plug-in.

~~~
azakai
> I've been thinking for a while that Lua and especially LuaJIT are so good
> that there might exist a strategy to do an end run around vendors and get
> LuaJIT into browsers as (initially) a plug-in. It's possible that there's a
> killer app waiting to be written that could run well in LuaJIT (but not JS)
> and that this could drive installation of such a plug-in.

Please don't create yet another plugin. Plugins are bad for the web, they
fragment it and if they end up de-facto standards that causes many problems
too.

> It's possible that there's a killer app waiting to be written that could run
> well in LuaJIT (but not JS) and that this could drive installation of such a
> plug-in.

If you think there is something that needs improving in the web platform,
contributing to that would be the best thing. If you have such a killer app
that does not run well enough in current JS engines, you can contribute to one
of the three open source JS engines to make it able to run your killer app.

~~~
gruseom
If the web is so moribund that its health relies on convincing individual
hackers not to do things they think would be cool, then the web is doomed. I
don't think it is; I think your argument is self-defeating. It makes me want
to make a LuaJIT plugin more, not less. LuaJIT is seriously cool.

If it were merely a question of some minor incremental improvement, such as
could be obtained by "contribut[ing] to one of the three open source JS
engines", then I agree it wouldn't be worth the fragmentation. But then it
wouldn't meet the definition of a "killer app" either. Nor would it be likely
to gain traction. It would just be a gnat.

What I'm talking about is only interesting if it might be disruptive. I think
there's a chance that Lua as both language and implementation is good enough
that it might enable things that simply aren't doable (performantly) in other
ways. Perhaps I underestimate how many tricks the V8 people have left in their
bag. I hope so. But at some point they're going to reach a wall caused by JS's
design limitations that simply can't be drilled through. I take the existence
of Dart to be a tacit admission of that wall. And what is so amazing about
LuaJIT is that it has already proven it does not know that wall.

At the same time Lua is so similar semantically to JS that it is not likely to
mess with the things that made JS great, so integrating Lua into the web would
arguably be a conservative design choice – more conservative, perhaps, than
many proposals to "fix" JS by making it more static and proper-like.

~~~
azakai
> If the web is so moribund that its health relies on convincing individual
> hackers not to do things they think would be cool, then the web is doomed. I
> don't think it is; I think your argument is self-defeating. It makes me want
> to make a LuaJIT plugin more, not less. LuaJIT is seriously cool.

Well, hack all you want (not like you need anyone's permission ;), my concerns
were not with that part, but with

> a strategy to do an end run around vendors [..] drive installation of such a
> [LuaJIT] plug-in

Hack it up if you want. But if you make a serious effort to drive adoption of
a new plugin - that I have a problem with.

> Perhaps I underestimate how many tricks the V8 people have left in their
> bag. I hope so. But at some point they're going to reach a wall caused by
> JS's design limitations that simply can't be drilled through. I take the
> existence of Dart to be a tacit admission of that wall.

I also take Google's focus on Dart as partial admission of not being able to
get V8 performance to where they want. But (luckily for the web), V8 is not
the only game in town.

Competitors to V8 have introduced new approaches that show a lot of promise -
background compilation in IE, full-program type inference in Firefox - with
many more ideas remaining.

So I really doubt there will be a LuaJIT killer app. Lua might be faster on
some benchmarks now, but it likely loses on others (like on any language
comparison), and in any case the difference will become smaller over time.

------
haberman
Very cool! Ignoring the relative strengths/weaknesses of the languages
_themselves_ , JavaScript's killer feature is that it is ubiquitous in web
browsers and Lua's killer feature is that it has an extremely small and easy-
to-embed implementation. With a project like this you could write code in Lua
and get the best of both worlds.

When it comes to actually comparing the languages though, Lua is the language
that you'd get if you had 10 years to refine JavaScript's design and throw out
the cruft, IMO.

~~~
bsg75
Don't you lose the compact advantage of Lua in the conversion?

~~~
haberman
Sure, but it could allow a single code-base to be portable to _both_ to the
tiny Lua VM _and_ the web.

------
fshen
Javascript is an usable language, just need an open mind to learn it.

Javascript is a simple language. Compile(translate) other language seems good.
But complicated things.

~~~
ufo
Lua is simpler though

------
daurnimator
What abilities does it have to interact with the DOM?

------
RageKit
Hum, i think everyone love javascript, but no one wants to actually write some
...

~~~
RageKit
(thats what i can deduct from all these lib to convert whatever into js)

~~~
freehunter
Javascript has the benefit of being able to easily run natively on the web.
Lua is more complex to get running in a browser, as other languages are as
well.

Javascript has the disadvantage in that some people know and love and feel
more comfortable in other languages. If you can convert from a language you
love to a language that makes it easy to get into a browser... that's the
dream.

~~~
RageKit
Yup, that's my case, i miss the easy workflow of other languages with "more
feature". I miss native namespace and packaging, class, a code completion that
works... etc

