cwisniew
commented
1 week ago i read that WASM was faster than JS however i couldn't find a reputable source but given that WASM is basically using a virtual machine to run fake assembly code like java or c# which i know for a fact are faster than JS it will eventually be faster if it isn't already. GraalVM has support for web assembly which means that there isn't a need to develop our own implementation of WASM. i currently am busy but if no one implements this in 6 -18 months i may look at implementing it myself.
Unfortunately the webassembly from graalvm does not run on the standard JVM (unlike the JavaScript from graalvm) which is kind of a hurdle
Feature Request
programming in javascript isn't pleasant or productive, and there are many languages which i would prefer to program in, i do believe that anyone that isn't a webdeveloper and that tried to code a macro library either feels this way about javascript or macros.
The Solution you'd like
i know it isn't feasible to simply add support for new language x because one person asked, but web assembly is a web standard and many languages compile to it, so by supporting web assembly we indirectly support many programming languages.
Alternatives that you've considered.
programming in javascript or implementing support for the language i want directly in maptool.
Additional Context
i read that WASM was faster than JS however i couldn't find a reputable source but given that WASM is basically using a virtual machine to run fake assembly code like java or c# which i know for a fact are faster than JS it will eventually be faster if it isn't already. GraalVM has support for web assembly which means that there isn't a need to develop our own implementation of WASM. i currently am busy but if no one implements this in 6 -18 months i may look at implementing it myself.