Lua to Javascript translator
github.com
github.com
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.
There are more than a few language X -> Y translators (not compilers), and I suspect they all miss some aspects of the source or target language.
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"])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.
If the only progress that occurs are incremental improvements to existing platforms, then the web is in "maintenance mode".
The web is pretty much our only complete platform that is standards-based. Fragmenting it risks killing it. Remember when sites were "best viewed in IE" and people without Windows basically could not browse the web?
> If the only progress that occurs are incremental improvements to existing platforms, then the web is in "maintenance mode".
How about WebGL, 10x faster JS than just a few years ago, typed arrays, video and audio tags, WebRTC, etc. etc. ..?
I was not implying that innovation had ceased. On the contrary, I love seeing stuff like this appear. Even if doomed from the outset to not become standard or widespread, the potential from experimentation is what keeps things interesting.
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.
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.
How about unicode and regexp support?
As for unicode, I also rather like their approach: we give you the low level tools, and you are free to implement whatever sort of encoding support you like on top of that. I used Ruby 1.8 when a string was just a bucket-o-bytes, and now I use Ruby 1.9 where every string MUST HAVE AN ENCODING OR ELSE! Based on my experience with both, I'd much rather not have encoding forced on me. That said, it would be nice to see a unicode implementation "blessed" by the core team (but the seem loath to "bless" any libraries).
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.
Javascript is a simple language. Compile(translate) other language seems good. But complicated things.
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.