0.1.0-stable

So, this was a cpython flask app designed to load brython.js 3.11.0 to imitate bits of translated java code. Now the code isn't complete by any means. But as a functional starting point, it gives one insight into how to template some of the bits. The rest is rpc logic or using the javascript/.brython.js logic to connect the dots with other javascript libraries.

Point being, it worked enough to enable one to continue templating the code. Because it is a stripped down version of what I envisioned, mainly a java runtime that was also backed by a python interface for the web directly. A tom cat server would have been overkill.

It's actual purpose is to be used with jython and xmlrpc calls. The point of it using rpc is for bi-directional communication with java classes running that brython might need to call into.

What this saves is the time of development. If you're only interfacing with parts of the code, and only handing back and forth data and handles.

This means passing only the data and the function the data (parameters of that function) back and forth. The rest is implementation and making sure the end points line up. Note that while using with jython and brython.js that the flask server in debug mode will have no idea that such is in use. So, any calls you make available to the front-end (html land) a function or a class, even bits of flask, due carefully check that you've passed the right name and check for errors. The back-end would be able to make functions accessible and use them. Even adding function handles to add the new route for the functionality you want it to exhibit. This to should be done cautiously. Now if you mapped an eel.js application to a flask app with a html <iframe> tag, you can still use eel.js within your flask app and have that also running but on a different port. This would additionally allow one to also have functions exposed that only the flask server can see due to configuring the eel.js app to run on a localhost ip instead of a 0.0.0.0 compatible one. Put together, one can even have java classes accessed in the browser.

This would allow for keeping the parts separate, lightweight, and able to run on most stacks that can run a dockerized flask+ app. But also allow for a way to not hamper another runtime with excessive loading and reloading. What this allows for is the ability to make the resources available without the client noticing that the backend functionality changed. For instance, if minecraft were built this way, it would be able to run in every browser with most of the resources rpc'd and the flask & brython app, one could connect the resources. Then run the needed parts for each version. One could also make use of WebGL with THREE.js & gravity.js, and the complexity of building goes down.