Javascript as a secondary language

[CrosRoad95]

Because javascript is popular, have many benefits over lua with almost the same syntax, i decided to make an attempt of adding javascript as a secondary language to mta. I decided to use V8 https://v8.dev/ the same engine that chrome and cef in mta uses. It may bring new people to mta that already know js.

Getting sources and compiling

Sources of v8 should not be inside mta, some of them will catched by mta gitignore what will cause problems while compiling. My suggestion is to make a script that download them from https://chromium.googlesource.com/v8/v8.git/ depend on version set in config file.
Compiling process requires few extra steps over these in mta:

1. download and install https://developer.microsoft.com/pl-pl/windows/downloads/windows-10-sdk/
2. https://dev.chromium.org/developers/how-tos/depottools
3. python
4. and some other tools
   it may be hard for regular contributor to get it work, and just compiling process takes over half a our and requires good tutorial how to do this.
   But if you have .dll and .lib files compiled by someone else, compiling takes seconds - and thats approach i suggest.
   Every some time, me, or someone else just update .dll and .lib files. We could use these from eg https://storage.googleapis.com/chromium-v8/official/canary/v8-win32-rel-8.9.276.zip but the problem is that whole compilation may get more complex due required usage of https://libcxx.llvm.org/

Compilation may be done in two way:

1. compile .lib files into mta - may increase size of deatchmatch.dll up to 20-30MB and may require extra dll anyway
2. load v8 .dll ( what is handled by v8 ) - what about anticheat? i don't know if v8 check files hashes

My vision how it should be implemented

1. You can mix js and lua scripts in single resource
2. "script" tag in meta.xml, accept attribute that tell, is it lua ( default ), or javascript. <script src="foo.js" lang="js">
3. all mta functions will availiable in module, import * as mta from "mta"
4. This is a way to clean up and better organise all mta functions, that why there should be two default modules: "mta" with organised functions with improved syntax, and "mta-legacy" where you have 1:1 same functions as lua eg: eg mtalegacy.createObject(1337,0,0,0). just "mta" can be a js wrapper over legacy functions.
5. If possible, use classes. when you create object, you should be able to access eg. model, by accessing "model" property
6. ACL - because everything in javascript is a object, i can do fancy method for functions like isAllowed() what return whatever acl allows or not this function

Prototype code examples

import * as mta from "mta"

const perennial = new mta.Vehicle(404, Vector3(0,0,0));
perennial.position = Vector3(100,0,0) // change position
perennial.data["owner"] = mta.player.getRandom(); // setElementData(perennial,"owner"],getRandomPlayer())

const hash = await mta.hash.bcrypt("foo") // passwordHash("foo", "bcrypt", {}) with callback

Branch i'm working on: https://github.com/CrosRoad95/mtasa-blue/tree/Javascript-2

[fresholia]

This is awesome, but the point I don't understand is, is JavaScript will to be a transpilator to lua? Because I guess if not, all functions will need to be redefined by cpp.

[CrosRoad95]

is JavaScript will to be a transpilator to lua?

no, native javascript support with all of features. Exactly the same as chrome browser and node.js has.

all functions will need to be redefined by cpp.

new parser could handle creating a definition for lua and js at once with minimum programmer effort

[fresholia]

great, i'll be following closely

[prnxdev]

I can help implement TypeScript into it if you want.

By the way: any solid progress on it? Can you paste some example code?

Adding JS could bring great benefits into MTA especially with Promises ❤️. I wish you luck.

[prnxdev]

Catch me on Discord: Piorun#6436

[CrosRoad95]

i made working demo,
https://cdn.discordapp.com/attachments/366384007535001612/800479896388108328/unknown.png
https://cdn.discordapp.com/attachments/366384007535001612/800481538030567434/unknown.png
https://cdn.discordapp.com/attachments/366384007535001612/800597329697964082/unknown.png

now i'll leave it to discuss how it should be implemented, what features should be enabled, how it should work being organized in general

[prnxdev]

As I suggested in private chat with @CrosRoad95 I think that everything should be like in Lua version of MTA's API. So functions like addEventHandler, createVehicle should exist along with OOP classes. The one big thing I think we should talk about is if we can add support for server-side libs because that could unlock many not achivable things in current MTA's API like using MongoDB or sending email via sendmail or something like that.

[prnxdev]

IMHO prototype code should look like this:

import { passwordHash } from '@mta/functions' 
import { Vehicle, Vector3, Player } from '@mta/classes'

const perennial = new Vehicle(404, Vector3(0,0,0));
perennial.position = new Vector3(100,0,0);
perennial.data["owner"] = Player.getRandom();

const hash = await passwordHash("foo");

[prnxdev]

There should be also implemented some kind of expression throwing mechanism so we could avoid returning false or null from functions or methods because it's ugly :P

[Toliak]

Hello! That is a very cool idea to make JS available alongside with Lua in MTASA

I would like to suggest type declarations (with JSDoc comments) that has been made from parser functions from mtasa wiki: https://github.com/mtasa-typescript/mtasa-lua-types.
I maintain the repository with types for TypescriptToLua transpiler for myself, so, I think those types will be up to date and you can freely use them in your prototypes.

Declaration examples:
Function declarations example,
OOP declarations

Also I have an example resource that uses mtasa-lua-types (it works with TypescriptToLua): code, more code.

P.S. I believe, there will be not so many security issues with JS..
Good luck with JS support implementing. 🚀

[patrikjuvonen]

@sbx320 wrote on Discord dev server on March 17, 2021:

I don't consider #v8-scripting to be something I'd even remotely merge, even if it worked

To me it's very far out of scope for MTA. Not only is reviewing nearly impossible, but we'd also need to support it in the future (e.g. for new scripting functions and v8 updates)

Plus the benefit is minimal and only risks fragmenting the userbase between Lua and V8 users

I agree with sbx's comments. It would also need rigorous testing to take place in any case, compared to the current Lua scripting engine which has been tailored and worked on since the beginning and has seen the battle testing. V8 in MTA has not, and I am unfortunately very skeptical and very critical in terms of security and maintainability. I think it is too much, and MTA should stick with just Lua. I'd rather spend time updating and testing our Lua and figuring out a working migration solution.

Adding v8 to MTA does not get my support right now despite the fact that I use JavaScript daily.

[Pirulax]

I will follow up @Jusonex answer here.

• it's pretty slow, because of many context switches between JS and C++ (which are much more expensive in comparison to Lua) --> at least needs some benchmarking to disprove/weaken this theory

There's a lot of stuff in our Lua API as well which should've been written in Lua instead of C++. I think if we tried to write as many things as possible in JS we could eliminate most of the context switches.

• a second language results in a significant community fragmentation and complicates documentation and scripting help

There's definitely truth to this. But on the other hand JS has a much better ecosystem overall (Code editors / IDEs, TypeScript).
Also, I'm not quite sure why support would be any harder. Generally there's way more people with JS knowledge.

• if V8 is really going to be introduced, the chance should be used to clean up the scripting API and remove all
  inconsistencies, deprecations and unsafe functions instead of creating a copy of the Lua API

Totally agreed. We should try to make a good and consistent API, with community feedback.

• is it worth all the effort?

Definitely IMHO. JS has native support for a lot of stuff which I just can't afford in Lua because of the performance hit. Just see how much slower Lua with OOP is in MTA.
If we make any benchmarks we should compare Lua both with and without OOP.
Example: Take some resource (minimap for example) and write it in JS, Lua OOP, and Lua without OOP.

Although I should add, our Lua API isn't that bad either, and there are definitely ways we could improve both the API and the developing environment.
I wouldn't support v8 as much if we would be able to update to Lua JIT. But right now JS is the only way I see we can improve our API,and correct past mistakes. Unless we add API versioning, because that way we could break backwards compatibility. Right now we're stuck in an infinite loop of "we can't break b.w.c".

[prnxdev]

I think MTA should drop support for Lua in future since Lua isn't that growing language like JS/TS if we will port MTA API to JS ofc. (for example in 2.0 version). It would help us avoid splitting community into two (or more) groups.

Same thing should happen to dropping support for XML cause it's dying data format. YAML or JSON is much better and more readable.

Yet another thing - separate as much as possible MTA server elements into smaller packages. For example if someone has whole server based on some external API or database why he needs all SQLite thing? I know that account system is based on this but I think that can be omitted also.

[fresholia]

MTA should drop support for Lua

This never happens.