Lua.CodeCompared.To/JavaScript

Like Lua's print, console.log appends a newline and accepts any number of arguments — though it separates them with a space rather than a tab.

The separator differs: Lua writes a tab between values and JavaScript writes a space. Note also that console.log shows a string without quotes at the top level but with quotes when it is nested inside an object or array, which Lua never does.

Neither language's block comment nests, so wrapping a region that already contains one ends it early. Lua at least offers an escape — extra equals signs, as in --[==[ … ]==] — which JavaScript has no equivalent of.

Lua ends a statement only where the parse is unambiguous. JavaScript's automatic semicolon insertion has famous corner cases — most notably a return followed by a newline, which silently returns undefined. That asymmetry is why JavaScript style guides argue about semicolons and Lua's do not.

const freezes the binding, not the value: a const array can still be pushed to. That is the same distinction Lua has between a local holding a table and the table's own contents — the difference is only that JavaScript can enforce the binding half.

JavaScript grew a fix: "use strict" makes an undeclared assignment a ReferenceError, and it is implied inside every module. Lua has no equivalent in the language, so projects reach for a strict.lua that installs a metatable on the globals table to catch it.

The failure differs: reading inner outside its block gives nil in Lua and throws a ReferenceError in JavaScript, which is why the example has to use typeof to ask about it safely. var is the exception that behaves more like Lua here, and is the reason let exists.

Destructuring is the more general tool — it also pulls fields out of objects by name (const { x, y } = point), which Lua has no syntax for at all. The leading bracket does need care: without a semicolon ending the previous line, JavaScript reads it as an index.

So if count then in Lua is true for a count of zero, and if (count) in JavaScript is not. Any guard written around a number or a string changes meaning when carried across, and neither language will warn you. Test explicitly — if (count !== undefined) — rather than relying on truthiness.

The convention worth adopting is that undefined means the language produced it and null means a programmer chose it. They are not equal under ===, though they are under ==, which is one of the few places the loose operator is genuinely useful: value == null tests for both at once.

Setting a property to undefined leaves it present and enumerable, so it still shows up in Object.keys and in a spread. Removing it takes the delete operator. This asymmetry is a common source of surprise when a Lua habit is carried over.

Lua's == corresponds to JavaScript's ===, and that is the one to write by default. The looser == has exactly one idiomatic use, testing value == null to catch both empty values at once.

JavaScript has two better answers. Default parameters apply when the argument is undefined, and the nullish coalescing operator ?? falls through only for null and undefined — which is precisely the semantics Lua's or has, restored.

Number.isInteger asks whether a double happens to have no fractional part, which is a different question from Lua's math.type. If you need Lua's integers, JavaScript's BigInt is the closest thing — and like Lua's subtypes, it arrived late.

The rounding is silent, which makes it dangerous for identifiers — database keys and snowflake IDs are the usual casualties. The n suffix creates a BigInt, which is exact but cannot be mixed with ordinary numbers in arithmetic without an explicit conversion. 🚨 The Lua column is anchor_norun because this build cannot honestly demonstrate its own point: Fengari uses 32-bit integers, so running it prints 2147483647 and 9007199254741000.0 — Lua appearing to lose precision too, which is the opposite of what the row teaches. The code shown is what a desktop lua prints.

So + is the one arithmetic operator that prefers concatenation, and every other one coerces to a number. That inconsistency is why converting explicitly with Number(…) is the habit worth keeping, exactly as tonumber is the safer spelling in Lua. One browser caveat: Lua 5.3 makes string-to-number coercion produce a float, so Fengari prints 15.0 where a 5.4-or-later desktop lua prints 15. The coercion happens either way; only the subtype differs.

Lua's tonumber returns nil for unparseable input, which is easy to test. JavaScript's Number returns NaN, which is truthy-adjacent, propagates silently through arithmetic, and needs Number.isNaN to detect. A failed parse therefore travels much further before anyone notices.

Template literals are the idiomatic choice: they interpolate any expression, span multiple lines without escapes, and avoid the +-versus-arithmetic ambiguity from the numbers section entirely.

The translation is not a single offset. Lua's sub(2, 3) takes characters 2 and 3; the same span in JavaScript is slice(1, 3). Both accept negative indices counting from the end, which is one convenience they genuinely share.

The method-call syntax matches too — Lua's greeting:upper() and JavaScript's greeting.toUpperCase() both dispatch through a shared table of string methods. Lua reaches it through the string metatable's __index; JavaScript through String.prototype.

The character classes translate (%a to [a-z] or \w, %s to \s, %d to \d) but the percent sign becomes a backslash, and - means a lazy quantifier in Lua where JavaScript writes *?. Alternation with | and grouping have no Lua equivalent at all.

This is a fair illustration of the size difference between the two standard libraries. Lua ships about twenty string functions on principle; JavaScript ships several dozen and adds more each year.

For text inside the Basic Multilingual Plane the JavaScript count looks right. Outside it — emoji, musical symbols — one character occupies two code units, so length over-counts. Spreading the string into an array iterates code points and is the closest equivalent to Lua's utf8.len.

An array is technically an object with numeric keys, so the mixed table on the left has a literal translation — but length counts only the numeric part and every array method ignores the rest. Split the two roles apart rather than reproducing the Lua shape.

Because JavaScript arrays are objects, reading past the end gives undefined rather than an error, exactly as Lua gives nil. So an off-by-one does not crash in either language; it quietly produces an empty value, which is why both communities favor the iteration forms in the next row.

The trap is for…in, which looks like pairs and is not: it walks inherited enumerable properties too, and on an array it yields string indices. Use for…of with entries() for arrays and Object.entries for objects, as above.

An array's length is always one more than the highest integer index ever assigned, and assigning to it truncates. So the JavaScript answer is predictable where the Lua one is not, which makes sparse arrays merely wasteful here rather than genuinely unsafe.

The four names map cleanly: push and pop at the end, unshift and shift at the front, with splice covering Lua's positional insert/remove in the middle.

This is the clearest day-to-day consequence of Lua's minimalism. Lua's whole standard library is smaller than JavaScript's Array.prototype, which is a design choice — Lua is meant to be embedded, and every kilobyte is paid for in the host binary.

Map is the structure that behaves like a Lua table here: it preserves key identity, accepts objects and functions as keys, and remembers insertion order. Reach for it whenever the keys are not naturally strings.

Remember from the truthiness section that the condition does not translate as directly as the syntax does — a bare if (value) means something different here when value can be 0 or "".

JavaScript's ? : selects a branch rather than evaluating a boolean chain, so it has no equivalent hole. It is one of the few places where the JavaScript spelling is unambiguously safer than the Lua one.

Writing the test explicitly means the inclusive/exclusive choice is yours: <= 5 matches Lua here, while the far more common < values.length pairs with zero-based indexing.

Translating until attempts >= 3 into while (attempts < 3) requires flipping the test. Forgetting to is a silent infinite loop, which is why it is worth a row of its own.

JavaScript has the keyword outright, and also supports labeled break and continue for jumping out of nested loops, which Lua can only approximate with more gotos.

The arrow form has no Lua counterpart in syntax, but it is the same idea as function(…) … end used as an expression. It differs in one respect that matters later: an arrow function does not bind its own this.

Returning an object instead — return { low, high }, destructured as const { low, high } = … — is often better, because the caller names the fields rather than relying on position. Lua's ordering has no such escape.

That is a genuine simplification: no packing step, and length answers the count directly. The spread operator ... in argument position is the inverse, matching Lua's table.unpack.

Lua calls the captured variable an upvalue and JavaScript calls it a closed-over binding; the semantics are the same. Note the naming convention does change — Lua uses snake_case and JavaScript camelCase, which is the only difference visible above.

Destructuring in the parameter list names the fields and supplies defaults in one place, so the body does not repeat the or fallbacks. The trailing = {} is what lets the whole argument be omitted.

JavaScript keeps the discarded arguments reachable through the arguments object in a non-arrow function, which Lua has no counterpart to — though rest parameters have made it largely obsolete.

That distinction is invisible while you write object.method() and becomes the next three rows the moment you do anything else with the function.

In JavaScript the receiver comes from the call expression, so a detached function has none. Passing a method as a callback is the usual way to hit this. The fixes are call/apply as above, bind, or wrapping it in an arrow function.

Arrow functions solved it at the language level: they have no this of their own and use the enclosing scope's, so the capture is unnecessary. This is the main reason to prefer an arrow for a callback and a regular function for a method.

The correspondence is exact: Animal.__index = Animal is what Animal.prototype already is, setmetatable is what new does, and Animal:speak is a method on the prototype. Having the syntax mostly means everyone writes the pattern the same way.

The Lua version needs two setmetatable calls and an __index on each level, and getting one wrong produces a silent nil rather than an error. extends does the same wiring, and super.speak() reaches the parent method, which in Lua means calling Animal.speak(self) directly.

The parallel extends to introspection. Lua's rawget reads a key without consulting __index, which is exactly Object.hasOwn, and getmetatable corresponds to Object.getPrototypeOf. The one structural difference is that Lua's metatable is a separate table holding the hooks, while a JavaScript prototype IS the fallback object.

Proxy is that mechanism, and it is strictly more powerful: it can trap reads, writes, deletion, key enumeration and function calls. It also arrived in 2015, roughly twenty years after Lua had __newindex.

The nearest things are Symbol.toPrimitive and valueOf, which only control how an object converts to a number or string before a built-in operator runs. Anything richer becomes a named method, as above.

One practical difference: Lua's print calls tostring and so honors __tostring, whereas console.log shows an object's structure rather than calling toString. That is why the example uses String(point) to force it.

So the pattern Lua reaches a metamethod for is the default state of affairs in JavaScript. This is one of the few places where JavaScript's object model is the simpler of the two.

Because pcall returns rather than branching, Lua code tends to check a boolean where JavaScript code tends to nest a block. JavaScript's finally clause has no direct Lua equivalent — the nearest is <close> variables in 5.4, which Fengari does not implement.

JavaScript convention is to throw an Error (or a subclass) anyway, because only those carry a stack trace. Lua has no such class; the equivalent is a table with a __tostring metamethod so the message still reads well if it escapes.

An Error has a message that is exactly what you passed and a separate stack carrying the position. That separation is why JavaScript code can match on a message reliably, while Lua code that does so has to cope with a prefix that varies with the level.

JavaScript has no built-in assert in the language — Node ships one in a module, and browser code throws directly, as above. Note the guard is written !(amount > 0) rather than amount <= 0 so that a NaN amount also fails.

The differences are in the wrapping. A generator is declared with function* rather than created from any function, calling it returns the object rather than starting it, and next() returns a { value, done } record where coroutine.resume returns a status plus the yielded values.

The mechanism is identical down to the detail that the first resume's argument is discarded, because there is no suspended yield waiting to receive it yet. A Lua programmer needs to learn no new concept here, only new spelling.

So both languages use the same trick to make a suspendable function drive a loop. The JavaScript version needs no wrapper because a generator object is already iterable, and it also stops the loop cleanly when the function returns rather than yielding nil.

Resuming a Lua coroutine runs its body right now, and nothing else can run in between. An await hands control back to the event loop, which may run any amount of other work before resuming. The printed order above is the proof: the last line of the JavaScript column runs first.

JavaScript builds the scheduler into the runtime and exposes it as promises, so composition operators like Promise.all come for free. Porting Lua code that assumes a synchronous world is usually the hardest part of the move.

The done flag on each result is all you get, and it is the only distinction that matters in practice. Resuming an exhausted generator is harmless and simply reports done again, whereas coroutine.resume on a dead coroutine returns false with an error message.

The export lines are commented out because this page's runner evaluates each example as a standalone script — a real module file would end with one of them. Note that JavaScript has two module systems, the older CommonJS require and the standard import, and they interoperate imperfectly.

This parallel is close enough that the hot-reloading trick is the same in both: delete the entry from the cache and require again. Standard ES modules are the exception — their bindings are resolved statically and there is no supported way to evict one.

JavaScript's destructuring makes the same operation a single line, and the ESM import { … } form additionally lets the tooling see which names are used, which is what makes tree-shaking possible. Lua's dynamic require gives a bundler nothing to analyze.

In Lua the guard is meaningless — #items is a number and every number is truthy, so the branch always runs. In JavaScript the same expression is the idiomatic emptiness test. Code ported in either direction changes behavior silently.

So [10, 9, 100].sort() gives 10, 100, 9. A comparator is required for numbers, and it returns a negative, zero or positive number rather than the boolean Lua's optional comparator expects — passing a boolean-returning function silently produces a wrong order.

The spread form is JavaScript's table.unpack idiom and is equally shallow — nested tables and objects are still shared. For a genuine deep copy JavaScript now has structuredClone, which Lua has no counterpart to at all.

In Lua the two entries coexist and the table quietly grows two records for one logical key. In JavaScript they overwrite each other. Both outcomes are wrong and neither is reported — use a Map, or normalize the key before storing it.

Integer-like keys come first in ascending order, then string keys in insertion order, then symbols. Relying on that is safe in JavaScript and unsafe in Lua — which means code moving from JavaScript to Lua is at greater risk here than the other way around.