Ditch Vert.x and remoting API entirely, and go embedded JS/TS route only?

[vorburger]

@edewit it occured to me while thinking about the "architectural design" of our project here that after #51 and #50 and perhaps before or along with #52, IFF we are only running scripts server-side and not client-side in-browser anymore anyways, then... I'm not sure what our entire Vert.x-based remoting API is actually good for - we may be able to make a pretty fundamental change and simplification and completely ditch all that again!

We COULD just run the JS scripts "locally in-process" in the JVM. I haven't looked at the details, but as I suspect you know even better than me there are several options to do this... we would have to pick any of the many JS engines that have a JVM "binding", whether like ScriptCraft did based on Nashorn (tutorial) or more modern alternatives, such as such as GraalVM or Chrome's V8 with J2V8 (dead?) (but not Rhino, that's ancient).

Something I think is important in this kind of approach is to "sandbox" what a script has access to, which may (?) not be possible with ScriptCraft's approach, but may be with modern alternatives - this would need more investigation and prototyping.

PS: An even more "fun" and crazy idea I had could be to allowing writing scripts for Minecraft using https://www.assemblyscript.org and then run that with https://github.com/wasmerio/wasmer-java. For this to work with Visual Programming that however would require that we control the code generation, which may be harder with Scratch but could be possible with Blockly, see #264.

[vorburger]

@edewit says Nashorn is going away, and GraalVM is likely the way to go here.

[vorburger]

#321 illustrates that we actually already have (some, basic) javax.script.ScriptEngine support.

What's missing is a convenient "local API". I'll try to explore that a bit further.

[vorburger]

such as such as GraalVM

@edewit started this on #434.