I like Lua very much, and in my mind, if the stars had been aligned just a little differently, it would now occupy the space inhabited by Javascript.
I cannot help but wonder, tough: A Lua VM implemented in Javascript? Is the performance hit not enough to make this useless for anything beyond proof-of-concept-sites/apps?
A Lua to Javascript compiler would have made sense. Given all the languages you can compile to Javascript these days, it would have made sense. And in terms of semantics, both languages are close enough that I think it would not be that big a problem.
Still, it is an impressive piece of work. Implementing a bytecode VM a) in Javascript, b) running in the browser must make debugging rather ... interesting.
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.
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
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
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.
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.
I planned to extend dillo with lua. I so far I have patch with the includes and the lua interpreter init.. annnnd that's it. I know nothing about interfacing interpreter with the browser components (dom, etc) so I stopped.
Dillo specifically avoids scripting, so I doubt the internals are well-suited to that sort of integration. You could try extending NetSurf[1], though. It uses Duktape[2] as its Javascript engine and its API is pretty similar to Lua's.
Thanks, I should look how others did it. It's true that dillo never cared about scripting, I felt like plugin lua in would force a rewrite of every part..
Thanks, I looked at it, I wanted a crude web browser, not a modern html5/css3/js(6).
The point was to make an extremely light, yet programmatic access to web data and almost static html.
When I use dillo I don't miss much, maybe a few css fix here and there. What I feel is that I want some emacs-ish capabilities in it so I can do more with less. And I love the ridiculous resource consumption of dillo, 30 dillo tabs = half a chromium one; and without parsing js and fetching scripts .. network + rendering is hard to measure.
I like Lua very much, and in my mind, if the stars had been aligned just a little differently, it would now occupy the space inhabited by Javascript.
I cannot help but wonder, tough: A Lua VM implemented in Javascript? Is the performance hit not enough to make this useless for anything beyond proof-of-concept-sites/apps?
A Lua to Javascript compiler would have made sense. Given all the languages you can compile to Javascript these days, it would have made sense. And in terms of semantics, both languages are close enough that I think it would not be that big a problem.
Still, it is an impressive piece of work. Implementing a bytecode VM a) in Javascript, b) running in the browser must make debugging rather ... interesting.