https://pluto-lang.org/web/#env=lua%3A5.4.6&code=if%20_PVERS...
But interoperability with the DOM is the missing key.
Still, if lua was used instead of javascript, I could see myself saying... man, I wonder what browser development would be like if we replaced lua with x.
I can see people liking or disliking Lua and JS both, depending on taste, but it's hard to see someone liking one and disliking the other.
My main example is self in lua which is just the first argument of a function with some syntactic sugar vs this in javascript which especially before 'bind' often tripped people up. The coercion rules are also simpler largely by virtue of making 0 true.
The things I do not like about Javascript can easily be shot down in an argument. Some of it was having to work with Javascript (and it's evil cousin JScript) in the 90s and early 00s.
The type coercion and in the early days people used '=='. I think === did not even appear until ie6?
[] == ![] // true
The lack of a lot of easy helper functions in the standard lib. That now are provided by people writing a bunch of stuff in the npm ecosystem.
The npm ecosystem itself. Lack of security. Lack of... curation? (Also, all this would have probably happened anyway if Lua was in the browser)
I also think javascripts long history has created a legacy of different paradigms
variable declaration var, let, const
function declaration
function f1() {}
const f2 = function() {};
const f3 = () => {};
const obj = { f4() {} };
There is a lot of stuff like this in javascript. I could probably make a blog post about it. But the above gives the general idea of my complaints.
The implicit conversions is a definite footgun tho.
Lua also has operational advantages compared to javascript. You can build it from source in at most a few seconds and run it anywhere that has a c compiler. The startup time is negligible even compared to a compiled c program so you can run entire scripts that do very useful things faster than most js engines can print hello world. There is also the benefit that in spite of what this article discusses, it is possible for most problems to write a lua solution that works for all lua >= 5.1. This is wonderful because it means if I stick to the standard library, the bitrot is essentially zero.
Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).
Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.
Of course Lua is far from perfect, but while there are some similarities, the differences are quite significant and meaningful.
As a scripting language for browsers this is an antifeature, and the fact Lua comes by default with a bunch of features that allow loading arbitrary binary code in the process makes it pretty annoying to properly use it as a sandboxed scripting language.
That was not my experience when I was working with lua. Did anything change since? Asked google. Answered :
> In Lua, if a variable is assigned a value inside a function without being explicitly declared with the local keyword, it will automatically become a global variable. This is because, by default, all variables in Lua are global unless explicitly specified as local.
All of that is trivial when you consider the Lua reference implementation. It is beautiful.
Otoh, missing ++, +=, ..= operators really bothers me.
But that's just personal taste, not objective by any means.
I love ++, but you know what? I was shocked when a co-worker pointed out that it is frowned upon to use ++ in javascript. It some big companies, their linter settings mark ++ as something that should be changed.
Appearently its really confusing if you put a bunch of newlines between the ++ operator and its ophand. No kidding.
From JavaScript: The Good Parts (May 2008):
> The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling viruses and other security menaces. The JSLint option plusplus allows the use of these operators.
Needless to say, I'm with you and hackthemack on this.
One killer feature of Lua (that surprisingly few scripting languages have) is stackful coroutines, i.e. you can yield across nested stack frames. Unlike JS or Python, there is no artificial split between generators and async/await and no need for function coloring.
If Lua had zero-based indexing, it would be close to perfect :)
"But, just write good code" you will say. Just like with Perl, some languages are designed in a way to discourage writing good code...
> No static typing to rest your eye on.
That goes for any dynamically typed language. How is that an argument against Lua in particular?
> Have you read large Lua codebases written by others?
No, because I use it as a scripting language, as intended. I totally agree that one shouldn't use dynamically typed languages for building large applications. But again, this is not specific to Lua.
But once that project gets passed to next maintainer — I'm not sure I'd pick Lua over Forth or Scheme.
Even the fact that people really want to write object oriented code, but every project rolls its own class system is a problem.
When I write lua is just tables of data and functions. I try to keep it as simple as possible.
I've been enjoying writing games for the Playdate, and in Love2d.
There are parts about the language I really enjoy. I like dynamic languages; I don't run into type issues so often it bothers me, but the tooling around Lua still leaves me wishing for me.
Part of this is really my own ability, or lack thereof, but I feel slow and constrained in lua. I have a hard time debugging, but I don't feel these things in other languages.
Lua's metatables also cover a fair bit more ground than JS. For example, indexing, math operations (including bitwise), comparisons and equality can be overriden.
https://github.com/fengari-lua/fengari-web
I don’t know if this can access the DOM in Lua, but considering that Fengari is in Javascript, adding a _DOM global variable should not be too hard (if it hasn’t already been done).
local js = require "js"
local window = js.global
local document = window.document
window:addEventListener("load", function()
local el = document:getElementById("main")
el:addEventListener("click", function(evt) js.console:log(evt.target) end
document.body:appendChild(el)
endLua has improved substantially from version to version because it’s been able to break compatibility. That wouldn’t be possible in the browser, so today we’d still be stuck using (an augmented version of) the outdated Lua 2.x.
https://web.archive.org/web/20191024193930/https://twitter.c...
“Lua in 1995 was very different, no coros e.g., and no one would be happy if it flash-froze and then slow-forked on a different path from Lua's. See https://news.ycombinator.com/item?id=1905155 and yes, wasm is the right long-term plan. In 1995 it was supposed to be Java, but that didn't pan out!”
It is a Lua reimplementation in JS.