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.
This is really cool, I'd love to write frontends in Lua. For side project backend development, I've been using Apache and mod_lua[1] (Openresty is Lua for nginx[2]) for a couple of years now. In particular Lua with Luajit is such a kick ass platform, I've always wondered why it hasn't gotten more attention than it has. There are at least two high quality event loop http servers written with it [3][4] and some quite mature web application frameworks [5][6]. Really seems like the Lua backend story is set to explode.
Learning that itch.io is powered by Lua was pretty cool. There's a [write-up] about how they leveraged coroutines for async programming which is super nice to read.
iirc, Cloudflare uses mod_lua for a lot of its packet filtering stuff because Luajit is basically magic.
I really like 'plain' Openresty and Lua and use it to power my backend. It is very straightforward and minimal. Nginx is always in the mix and using homogenous technology in the stack simplifies things even further. Also experimented with using it as a websockets server and worked quite pleasantly out of the box.
Lua is one of the few popular programming languages originated from the South Hemisphere - other example is Elixir (not sure if it was also created here in Brazil,
but I think Jose Valim is Brazilian).
While it's not as popular as Lua or Elixir yet, I believe Crystal (crystal-lang.org) will be "the next big thing" in a few years. It's also from the Southern Hemisphere.
No need to do that, you can use wasm to build lua[1], although the API definitely needs some clean up. This looks much nicer from a JS integration perspective.
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.