Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can just take the original Lua interpreter source code and compile that to asm.js or WebAssembly without changes. Loading dependencies from the web requires an asynchronous reimplementation of the "require" command though, but it's all quite trivial. The result is about 100 to 150 KByte compressed. The only downside (beside the added size) is that the Lua code is still running interpreted, not JITed. That's why I think that a combination of WebAssembly for performance critical code, and Typescript (compiled to Javascript) for the 'scripting part' makes more sense than WebAssembly+Lua, since this doesn't have those downside (no additional size overhead for the interpreter, and the JS will be JITed).



I have tested Lua compiled to asmjs and it is very very fast. A LuaJIT that targeted WASM would be phenomenal, but not strictly needed. Or maybe something like Terra [0] but targeted WASM. Either one would meet all of my perf needs.

Lua really is the MLIR (mid-level intermediate representation) from the future.

[0] http://terralang.org/


I've been working on a hand written Lua interpreter in WASM (using Lua as a macro assembler, ofc). Long term I'd like to have it jit wasm code: https://github.com/serprex/luwa

Currently in the process of porting the parser & codegen that's implemented in Javascript to Lua so that I can have the implementation bootstrap itself. Plus the codegen was for a bytecode I came up with in JS but which has evolved quite a bit since getting everything in place to happen in WASM


This is super cool.

It looks like you are in the process of porting the .js to .lua? Wasm will exist in many more places than Js will.

I think I would have started with many of the Lua on Js implementations and used zero Js.

Have you seen http://stefan-marr.de/2015/10/jit-data-structures-fully-refl...

Check out this paper, https://www.cs.purdue.edu/homes/rompf/papers/amin-draft2017a... Collapsing Towers of Interpreters


Yes: at the end there should only be the light rt.js layer. Manipulating DOM is not in my scope; WASM is evolving on that front still. Currently rt.js has to expose a free method for handles, that may become unnecessary as WASM's gc capabilities develop

Thanks for the links


100-150KB is still quite the downside, especially when there isn't really much of an upside for the user, who is bearing the burden of that download size.


Fengari gzipped and minified is about 75kb


IIRC, the actual reason fengari doesnt compile to webassembly is the garbage collector. You must use JS for everything if you want to avoid memory leaks when there are cyclic references between Lua and JS.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: