This is great to see! It's important to note that this isn't just yet another "X compiled to Y using Z", but a VM written from scratch natively in Javascript.
The result is a much smaller size, it's more understandable, hackable, extensible - all things that Lua's standard C implementation is great for. It's likely also easier to optimise this way.
I began on a similar project some years back, but as many spare-time projects go, never finished it: http://code.matthewwild.co.uk/ljs
No but seriously, if you want to write a VM in Javascript, I would suggest learning how to write a VM in a language more suited to writing a VM in. Maybe C or C++ then writing one in Javascript.
Do what you want. The nice thing about writing a managed language with GC in a managed language with GC, is that you don't have to write the GC. (Or the JIT, if you do it right.)
This is a full-blown (web-based) development environment for the MOAI Game toolkit, which just happens to be able to deploy to not only Android, iOS, Windows, Linux, OSX hosts .. but also - as demonstrated - to html5+js hosts.
So, if you've ever wanted to check out MOAI but have been put off by the need to build your own host for the OS of your choice, you can just use moaifiddle to get your project done, see the results directly in-browser, and prepare your app before even having to download the MOAI SDK. Sweet!
(More details about the cross-platform game toolkit, MOAI, are available here: http://getmoai.com/)
I've been working with MOAI for 3 years now, so I guess I'm quite biased - but I find it awesome.
Yes, the Docs - well these are generated docs, courtesy of doxygen. You really need to start at the wiki, and then work your way through all the samples in $MOAI_ROOT/samples/
MOAI does take some patience - but on the other side of that effort, is a fantastic framework that makes game development easy and fun. There's something just so elegant about it!
Maturity? Not as mature. Libraries written by the community - surprisingly there are a lot of little/efficient frameworks for MOAI already, like moaigui, Hanappe, and Flower. These are all user-contributed extensions that make working with MOAI even more joyous...
But yeah, you'll have to suit up for the task of producing a working MOAI host from sources .. this isn't done for you, it is after all free software and there's nobody to buy a license from ..
MOAI already renders to HTML5. I don't know what you find terrible about it.. but am interested, so feel free to engage me in conversation. FYI, I've been using MOAI for 3 years so I'm not really feeling any negative reactions towards it as a framework - its really done a lot for me as a developer.
Mostly: Setting it up was a pain, developers clearly have no intention of really supporting it (they made explicit that their focus is their cloud project and their gamedev projects and that moai SDK is a sort of sideproject), the forum when I was trying to setup Moai was dead, community was overall weak, documentation was wrong and outdated...
I don't doubt Moai technical capabilities, I was very impressed by it, also the fact that it is FOSS is really cool, but the barrier to start using it was too big and insane.
Never experienced any of that as a serious problem, but I'm a 'compile from source' guy anyway - but yeah, the devs are of course using MOAI to make their own products (Games) and yeah - there are a lot of forks of MOAI alas, but in the last 6 months the Forum community has really risen to the challenge of self-organizing around all these forks, and this is reflected in the current release that was made by the community. So that has definitely improved. Docs: no longer outdated. Community: very strong - See moaiFiddle, this was born from the community after all.
I honestly think if you took a new look, you'd see the issues you described are not really show-stoppers/blocking any more. A lot of us in the MOAI community are busy using the thing to do actual releases ..
Maybe, I will take a look when the next cycle of choosing tech comes.
Right now I am in middle of making a point and click adventure with Gideros (obviously, Moai being used for Broken Age was one of the reasons why I looked into it in first place, I assumed that if Tim Schafer found it good for that, maybe for us it would be too).
After I finish it and use the engine (I am making a engine to be re-used for several episodes) for a couple games, maybe who knows what we will decide.
Well, great, I'd love to know your product when its released, let me know if you don't mind! ;)
Apropros MOAI in the future, just let your game start with Lua tables. Doesn't matter what the game is describing, but just .. do it with nice tables[].
It would be nice to see other languages available as real languages, not compiled down to Javascript. I love me some javascript, but it would be nice to work in Python, in the browser.
Lua is indeed, embeddable anywhere. Its such an elegant little VM, and you can just put it wherever you want. It is some sort of mad invasive engine .. you use it once, and from that point on you pretty much can't see anywhere else you wouldn't just use it, of course .. if you had to, or wanted to, and .. the more you use the Lua VM stack, the more you just want to keep doing things that way. It is neat.
How do you envision this happening? Either the runtime would have to be written in JS or you'd have to get all the browser implementers to adopt your virtual machine — which, I mean, why would they?
I agree and used to agree very enthusiastically, but now I kind of understand the browser makers' position. Like, I don't love having my favorite runtimes locked out, but I also don't think having 15 virtual machines bundled with every browser would be a great outcome either. We've already seen how in-browser VMs turn out when they're not adequately maintained with Flash and Java, and it isn't pretty and it leads to people's money getting stolen. So I can't really blame the browser makers for not wanting to go down that road.
What we have now isn't the very best thing I can imagine, but I think it's an OK compromise. We have a set of runtimes that implement a fairly consistent Turing-complete set of instructions, so we can implement just about anything we want and express it almost any way we want. And in the end, I think that's the most important thing.
Personally, I'd like to see a Scheme or ML dialect, but I'm not one to exclude good languages: I'd love to see some way to portably, reliably, and safely extend all browsers to support new language VMs - including languages like Dart, Python, Ruby, Lisp, etc. - without resorting to huge blobs of JavaScript that half-heartedly implement a half-useful language.
Things like ASM.js are interesting, but not really helpful, in my mind, as it just adds another unnecessary layer of overhead just to be able to implement something interesting in a language suited to it. I just wish browser vendors saw this the way I do.
What is the difference between a "real language" and "compiled down to JavaScript"? Like, every language is either interpreted or compiles down to something else. I'm not clear on what the real distinction is here. Are ClojureScript, Dart and Scala not real languages since they compile to JavaScript?
...I know it's the fashion to write compile-to-js languages and js-VMs for other languages, but I really have to ask: WHY? I mean, Lua is a dynamic language with first class functions just like Javascript is, no big difference here.
I understand clojurescript, parenscript and haskell to js compilers, because these languages are really different from javascript, so they offer you a very different way of working and different tradeoffs (Clojure, CL, Haskell offer you the ability to choose a programming style that is just not possible in Javascript). Maybe even Opal or Amber - rubyan/smalltalkian oop semantics really are very different from Javascript's and you end up using very different design patterns. And I understand the wish to have static typing for large projects/teams, ergo TypeScript or Dart.
But I really don't understant why would anyone go through such pain (by pain I mean not writing the transcompiler/vm, this is the fun part, I know, but debugging it, maintaining it and debugging the code you use it on), to use a language so similar to Javascript, like Lua or Python, instead of using just plain Javascript and making some minor effort to 'use strict', avoid some dark corners and get used to living with a little less syntactic sugar?
For the people that wrote Moonshine, it was the ability to use the same language across all platforms[1]. They already have a lot of Lua code on other platforms that was unable to run on the web (without using Flash, which also has a Lua VM available for it).
Lua is very portable, I wouldn't choose Javascript to replace it for multi-platform game development. However Javascript has a monopoly on the web. I don't see why this ought to be.
WHY? I mean, Lua is a dynamic language with first class functions just like Javascript is, no big difference here.
You can use objects as keys in Lua. This makes a lot of code in Lua a pain to port to JavaScript. I have Lua code I would like to port to JavaScript that this applies to.
Because they were already using Lua as a cross-platform killer language, and wanted to just be able to share game-content with a slick, slimy, javascript layer?
This would be even more amazing if there was no dependency on `luac` to compile to Lua bytecode. I'm developing a web application with user-scriptable features, and I'd love to use Lua (to provide a better user experience for my non-webdev audience), but the dependency on a server-side compilation step is a problem for my use-cases.
There is a Moonshine extension[1] that uses Yueliang[2] to compile offline in the browser, but it's quite slow. I'm hoping to speed it up a bit in the near future, with the futures I'm working on now.
The app front-end has user-scriptable features - I should have been more specific. My app has no back-end, and it is unacceptable to set up a back-end for the sole purpose of running luac on user scripts.
Coroutines, and Lua's metatables are more powerful than what can be done in ES5 (ES6 closes the gap a bit, and generators are equivalent to coroutines).
Lua is pretty much JS done right, which actually makes it a poor choice for something like this IMO. A program written in Lua is not going to be fundamentally different from the same program written in JS, and the problems introduced by using this (worse debugging experience etc.) are very likely to outweigh the benefits of avoiding JS's warts.
How do you know? Maybe try this first? Apparently, there is a in-browser debugger you can activate just by including two files. This is theoretically a first-class debugger that doesn't even need source maps.
From my cursory evaluation, the debugging support is actually better than vanilla Lua. The only point of friction I can see if that you have to "compile" something that is normally interpreted.
Generators are equivalent to corourintes only as long as every single function you write is a generator and every single function call (to one of your own funcitons, anyway) is actually delegating to another generator. You can use a trampoline to make this less painful, but then you don't get to see your "real" call stack in the debugger...
I hate how everything is moving to JS :) I wish somehow there were multiple languages targetting a common bytecode.. but that won't happen for some reason I can't understand because I stopped in the middle of the dragon book.
It's simple. "Bytecode" is just a kind if encoding. The only thing it does is make programs marginally smaller and marginally quicker to decode. It's not enough to justify enormous switching costs. Let's talk about what functionality this new thing should have. That's where the high-value opportunities are. But, it's also where there's no easy consensus.
You know what's a perfect, concise byte code? An ast-laden ASCII blob. What's the byte code for a byte array again? Oh there isn't one.... What's the byte code for a compare and swap? Shit....
Personally, I feel that the biggest slap in the face to developers in the last decade is that V8 uses native code instead of byte code. In 10-20 years I hope we look back on Google's decision to do that and hate them for it.
Because we could then have a virtual machine that we could send bytecode to, instead of having all of these languages that compile to JavaScript, which eventually gets compiled to native code by V8.
I think the point of contention is that there isn't really such a thing as a completely language-neutral bytecode, so nobody can agree on whose language-specific-js-replacement vm to ship.
If JS ever gets finalizers we could probably consider the total feature set JS has at that point sufficient for the implementation of most other dynamic languages without resorting to writing a VM in js or using asm.js to embed a full C runtime using arraymaps for a heap.
At that point we'd probably see some subset of JS devolve to a bytecode, I'll bet.
The result is a much smaller size, it's more understandable, hackable, extensible - all things that Lua's standard C implementation is great for. It's likely also easier to optimise this way.
I began on a similar project some years back, but as many spare-time projects go, never finished it: http://code.matthewwild.co.uk/ljs