This is a possible way to close issue #1129

I'm working on a PR that will introduce QuickJS as an option (new qjs or new qjavascript).

We could replace Duktape with QuickJS if all the JS carts will work.

It should be possible to add functions to a global scope instead of inside a module using JS_GetGlobalObject(), JS_SetPropertyStr(), and JS_NewCFunction(). In that case, all JS carts should still work perfectly.

my fork at https://github.com/Kozova1/TIC-80.git uses the ES6 module system, and hides away all the builtin TIC-80 functions inside the tic80 module.
Unfortunately, my fork has some memory bugs because of my shitty implementation, so until they're solved it should not be merged (since it just crashes immediately if it doesn't get a JS exception).

Duplicate #874

Agree. Recommend we close as dup.

Edit: Keeping this thread instead since it has more content.

@Kozova1 Did you ever make any more progress? Anything specific you need help with?

Didn't really make any more progress. Some help with how exactly to use QuickJS would be great since last time I checked the docs aren't really great.

Yeah seems you'd have to read and learn from the examples. If you had a very specific question feel free to ask here.

I'm interested in this as a way to make using CoffeeScript easier. Currently I'm using Babel and Rollup and some magical incantations just so I can require() a module of code shared amongst my various toys.

If this moves forward I might be tempted to contribute a hack to make CoffeeScript work in TIC 'natively': write CoffeeScript in the editor, translate it to JS behind the scenes.

I personally don't think we should support transpiled languages... gotta draw the line somewhere.

Moonscript is in there 🤷... CoffeeScript is pretty old tho lol

Yeah, maybe too old is a better argument. :-). I think we need SOME criteria though. I don't think "add every language someone writes a PR for" is a maintainable long-term strategy since already we can see where this is falling down with languages like JS not getting updated... we have no one/few willing to do the hard long-term maintenance work.

Yeah, maybe too old is a better argument. :-). I think we need SOME criteria though. I don't think "add every language someone writes a PR for" is a maintainable long-term strategy since already we can see where this is falling down with languages like JS not getting updated... we have no one/few willing to do the hard long-term maintenance work.

Wasn't there an idea to leave only WASM interpreter in TIC-80 and thus have support for any language that supports compiling to WASM without having to maintain each language interpreter in TIC-80?

Wasn't there an idea to leave only WASM interpreter in TIC-80

No, I don't think the goal was ever "WASM only"...