Why we rewrote Lua in JS (2017)

The list of niceties of lua from the article:

First class functions and closures

A versatile data structure: the table

Vararg expressions

Lexical scoping

Iterators

Coroutines (see below)

Well, looking at modern day js:

* First class functions and closures, check

* the table: a combination of `Array`, `Map` and `Map` can prettify much cover typical usecases of lua tables, so js is close in this regard

* Vararg expressions, check

* Lexical scoping, check

* Iterators, check

* Coroutines, with libraries and abstractions on top of generator functions

In addition, in js land, other paradigms of concurrency exists, such as CSP (goroutines), FRP (Rxjs and co). Of course, these can be implemented in Lua as well, but the libraries may not quite as battle-tested.

The author also mentions a sane coercion system; this still true, but ever since "use strict", unexpected coercions can mostly be avoided in js.

On the other hand, js has:

1. Typescript and static typing (a bit unfair to consider this js, but ts gets access to a large portion of high quality npm packages), flow is also great

2. Multiple mature echosystems of UI frameworks (React) - for instance if you need a date picker or an autocompleter, it's just `yarn add` away; I doubt enough such libraries exist for browser side lua yet

3. Tooling support - webpack, prettier, postcss and so on

I like lua, but I feel it does not offer much in addition to what modern js already provides. Of course bring more languages to the browser is always a good thing, on the other hand I do feel this is a tough sell to the larger community.

It’s interesting to me that people are pumped about async/await.

If we time travel back to when Node caqme out, the single most common reason I saw cited for its success was something like: “JavaScript’s simple event-based programming model is a natural fit for a server coordinating I/O from different places”.

Back then we had callbacks and closures and it was just powerful enough you could do almost anything, but simple enough that you were never truly lost.

Now I see developers pumped about a world where callbacks, promises, and async/await are all mixed together in an NPM soup.

I wonder if that mixture might be the thing that finally pushes JavaScript out of reach for beginners (if it’s not there already).

And maybe that opens a door for something like Lua, if it really can embrace async functions without the baggage of Promises and callbacks spread throughout public repos.

Even if that works out though, I do wonder about that original reaction to Node. Maybe Ryan Dahl really hit on a good control flow model that the JS community then threw away. I do think that platform devs sometimes try too hard to make async “disappear” instead of trying to make it inspectable.

Initiatives like this make me really excited, but the biggest problem is always long term maintainability and interoperability with the rest of the browser ecosystem. Without a huge company backing the effort, it becomes really risky to use this long term because development could drop off or never gain traction.

If you don't have a huge open source community, you need one to push the ball forward and keep things going. That's really hard to get without users, which is a great catch 22. I'd almost suggest building a "killer web app" on Fengari just to demonstrate it, or at least to indicate that its development effort won't go the way of Moonshine.

I love Lua, and I would love to use this. The risk, however, is pretty high in anything but an experimental context -- at least for me.