1. The information gets from the VM to you through a custom WebSocket protocol called Goval (you can see the JS client at https://github.com/replit/crosis). It can do editing, console I/O, VNC, configuration of the image, etc.
2. The console is rendered with xterm.js, the desktop is a VNC client.
1. Yes, but, what is actually happening on the box?
2. I doubt this is xterm.js. The font and text to not appear to be aligned columns/rows like an xterm session. (Compare the outer emulator font sizing and the inner x64 font sizing.)
3. The croisis protocol says, "x protobuf for vague 1-sentence description", but this does not actually specify the behavior of the backend--and you can't read the source.
1. I'm assuming by "the box" you mean the VM. It gets started for you when you run the repl as a user who does not own it, and it will run a command specified in a configuration file (see https://docs.replit.com/programming-ide/configuring-run-butt...) and send you the output, as well as let you provide input. It will also detect the run program doing things such as starting to listen on ports (which will be forwarded to a public URL (only under certain circumstances (this is a bit confusing and a bit broken (I don't fully understand it)))) or opening X sessions, in which case it will start the VNC connection to your client. Other than that, it's fairly simple; just think of it as a VM running in the cloud, connected to you, and running a program specified by the creator.
2. I'm almost 100% sure that it's xterm.js, though to be clear I say that it is used to render the console that you briefly see whilst it is compiling. The desktop - which is how you are seeing the emulator window - is provided by a VNC client.
3. Replit is largely closed-source, unfortunately. The protocol is just the way in which the Replit IDE and client communicate with the VMs on the backend. I've summarised some of the behaviour of the backend in my other comment, most of which is known through messages or posts from their engineers. By that summary, it means that the protocol is Protobuf-based. If you want to see a sample of the stuff it sends to the server, you can open a repl you own, append `?debug=1` to the end of the URL, and click the alien logo on the left.
2. Ok, it's not xterm. What is the VNC server/client? I don't see on in the code. When you use replit, what will cause it to trigger a magic VNC client? What if I want to try a different VNC server to speed it up? When will the VNC close...there's a lot of magic that I as a developer can't really work with and doesn't seem to be documented.
AFAICT, this demo is equivalent to, "someone ran VICE in a VNC". I think that's the OP's point.
It isn't even clear what VNC (or what its performance profile is).
It's "magic", yes. Replit is not for you to mess around with the VNC or anything, that directly defeats its purpose. Replit is not a framework for building a Replit-like system. Replit is effectively just a way for you to save and interact with VMs in the cloud from your browser.
The whole point of this demo is "someone ran VICE on Replit". The VNC is completely besides the point.
1. it is xterm, xterm.js to be sepcific
2. uses no-vnc. if you own the repl theres a way to set the vnc server password and access from your own client, but i forget how. probably on the replit docs/blog
Again, let me stress this: xterm.js is providing the console only. Any visual things, including the x64 window, are provided by the VNC connection, which is completely independent of the xterm console.
2. The console is rendered with xterm.js, the desktop is a VNC client.
3. Not sure what you mean