feat: wasm support

[2vg]

Swiftly currently support JavaScript and Lua to write plugins within Metamod/CS2.

Here, I propose adding new support for wasm to get better performance benefits.
JS/TS and lua are easy-to-write scripting languages, but I believe that their performance is generally lower than other languages ​​(I don't know how much they are optimized within Swiftly, so I apologize if I'm wrong).
It might be a different story if Swiftly added support for another language like a adding support for Rust or Go, for example, would require a lot of effort and changes, so it's not realistic.
Another option would be running JavaScript on the faster v8 engine, but this also would likely require significant changes and wouldn't be as lightweight as QuickJS.(I mean like a memory-size, etc.)
Therefore, I thought that wasm support would be more suitable as something that could gain performance with less effort.
Wasm should have better performance than js for general workloads, making it suitable for developing plugins that demand higher performance.
I'll talk about using Rust as wasm, which means that wasm will run without GC, and I expect it will be as fast as native.
Any other language that can be made into wasm should be able to be supported(so we can use Golang, etc.), so I'm sure adding wasm support will open up new possibilities for modding.

I understand that this is not an easy task, but I would appreciate your consideration, Thanks 🙏

[skuzzis]

I see, let's break everything down:

Here, I propose adding new support for wasm to get better performance benefits.

This is a great idea, we'll 100% consider it for future updates.

Now we're working on a new API for the extensions, which will also allow to make mostly everything what the scripting side can do.
Hopefully this will also allow the extensions to be more developer-friendly, and like that we can always add more languages in extensions, such as some that you mentioned (Rust, GoLang, etc.)

JS/TS and lua are easy-to-write scripting languages, but I believe that their performance is generally lower than other languages ​​(I don't know how much they are optimized within Swiftly, so I apologize if I'm wrong).

From the JavaScript part i've seen that the performance is pretty decent, it can always get some improvements later on, and on the Lua side, from a recent profiler, i've seen the speeds to be quite good. I'll attach a profiler file to this comment and it can be viewed using https://www.speedscope.app/ -> Browse -> Select the profiler json -> Sandwitch View and over there everything is listed accordingly for each item the minimum, average and maximum time used. For some plugins, it also depends how much data you're working with, if you make big for loops and so on. We're also updating our profiler now to minimise the amount of data stored inside the file.

profiler.all.c7b2d092-d4e1-484c-a0ef-382791fe73c8.json

mWZGNkc734dxWrNqX3iHSjUQwIXw8OoB.mp4

Also adding to this, we've focused more on development experience and on how fast and easy plugins can be developed.

It might be a different story if Swiftly added support for another language like a adding support for Rust or Go, for example, would require a lot of effort and changes, so it's not realistic.

Referencing to the first argument, we will add more languages support inside extensions.

Another option would be running JavaScript on the faster v8 engine, but this also would likely require significant changes and wouldn't be as lightweight as QuickJS.(I mean like a memory-size, etc.)

This was, and still is a variant for updating the JavaScript side. I was thinking to also add v8 and allow users to change which engine is best for their use case.

I understand that this is not an easy task, but I would appreciate your consideration, Thanks 🙏

We know it's not an easy task, it will of course take time and I'm sure that it will be great at the end of the implementation. Thanks for the suggestion and we're gonna make everything in our power to make this thing possible. ❤️

[skuzzis]

(Note: The profiler json can be also retrieved by you using the sw resmon enable, leave it on for however much you want to test out for, and then using sw resmon save to save the profiler of all the plugins into one file, or sw resmon save PLUGIN_NAME to save the profiler for that plugin)