JLua: Yet another Lua implementation in JavaScript(github.com)
github.com
JLua: Yet another Lua implementation in JavaScript
https://github.com/hsiaosiyuan0/jlua
23 comments
@op I run the newsletter Lua Digest, what's your email?
hi, this one: [email protected]
The GitHub profile of the user has an email.
I would name this project yajslua instead of jlua.
I'm really not interested in "Lua now implemented in x", what Lua needs is the new Luajit finished with the advanced garbage collection.
Everyone scratches their own itch. There is value in multiple implementations when they explore different approaches. This just means either a "perfect answer" has not been found or that the journey itself is seen as worthwhile.
Why take the time to comment then?
To be fair, they did at least mention an alternative direction to pursue, so it's probably more useful than many of the dismissive comments that I see. I'm not convinced every comment on a project needs to be supportive of the project and its goals.
The description of the project begs the question: how is this different from other Javascript implementations of Lua?
I’ve recently compiled a Lua-based project into WASM with Emscripten, but transpiling Lua into JS to avoid the engine overhead is compelling. I wonder how these approaches compare. For me it’s very alluring to use most of the same codebase as other deployment targets. This also has the potential to add better contextual intelligence to a web-based Lua editor- I’ll have to race it against Regex to see which is faster/better at pulling lists of locals/globals/functions out of Lua input for use in auto-complete.
Honestly I'd love to go the other way, the Lua VMs are so far ahead in terms of portability, ease of integration and speed(luajit is still a marvel of engineering) but so many people are turned off by parts of the language it'd be great to present a JS interface to these runtimes.
I still remember shipping the entire game logic for a title on the PSP inside of a 400kb block and that's was before the days of luajit. It's really an incredible language and I really wish it saw more mainstream use.
I still remember shipping the entire game logic for a title on the PSP inside of a 400kb block and that's was before the days of luajit. It's really an incredible language and I really wish it saw more mainstream use.
That’s super cool. Lua’s footprint has always been enticing to me because of that. Which game did you work on?
Me too! I think it’s gaining a little extra appreciation lately. For us the wow-factor was the ease of tying it together with a C host program in lieu of some conf file based alternative. For example our Keybow (Raspberry Pi-powered mechanical macro keyboard) product uses Lua to let users easily define and share macros. Not only does this trivially exceed any effort I could have made to design a domain-specific configuration file format, but it’s allowed users to try things I’d never conceived.
This is what it was initially designed for.
Why do people put time and effort into a project and then name it as if its a generic, disposable, piece of garbage? Very strange
I have no idea, maybe those people are unaware of others will turn a blind eye to what are in the project but complain a lot about the project name. Weird.
It's a tradition, apparently: https://en.wikipedia.org/wiki/Yet_another
Interesting, I didn't know Yahoo! was based on this. +1
I have a different objection: the 'J' prefix is standard for projects in Java, not JavaScript. 'JSLua' would have been better.
Turns out there's already a Lua-in-Java project that goes by LuaJ: https://github.com/luaj/luaj
Turns out there's already a Lua-in-Java project that goes by LuaJ: https://github.com/luaj/luaj
The problem with the name is that it's almost identical to the Java implementation of Lua which is called LuaJ.
\tangent Time was, a J prefix initialized Java.
that's some beautiful javascript code and great project structure here. got me thinking about a few things:
1. is the "index.js" in subfolders a nodejs thing?
2. does that turn subfolders into modules?
3. can you write and run that kind of javascript without nodejs?
1. The "index.js" thing is due to how module resolution is handled with CommonJS and ES modules. If you have a file at "./lib/index.js", then you can omit the "index.js" and just write "require('./lib')" from another file.
2. Not exactly. In JS, every file with an "import" or "export" statement somewhere is its own module.
3. You can write code like this for the browser. Most browsers support ES modules now. However, you do need a bundler tool like Webpack if your code depends on other node modules.
2. Not exactly. In JS, every file with an "import" or "export" statement somewhere is its own module.
3. You can write code like this for the browser. Most browsers support ES modules now. However, you do need a bundler tool like Webpack if your code depends on other node modules.