This looks very cool! All the demo slots are taken at the moment. I'm curious: is the frontend just a dumb display server, or do you run there subset of GUI code responsible for latency sensitive feedback loops (typing, scrolling, dragging, maybe expanding menus etc)? E.g. is it vulnerable to network latency the same way as remote desktop solutions are?
Thanks! Sorry about the slots, I just raised the limit and idle desktops now free up after 10 minutes, so it should be easier to get in.
It's not a display server. Each app's frontend is a normal web page that runs in your browser, in its own sandboxed frame, so typing, scrolling, menus and dragging are all local, just like any web app. The desktop itself (windows, taskbar, the map) also runs in the browser.
What goes over the network is only what the app decides to send: messages and events between its frontend and its backend on the server, over one WebSocket. So latency shows up where any web app would feel it, when it waits for data from its server, not on every frame or keystroke.
The one exception is something like the Terminal, where every keystroke goes to a shell on the host, so it feels like SSH on a slow link.
Reminds me quite a bit of puter.js
Looks interesting though
https://developer.puter.com/
This looks very cool! All the demo slots are taken at the moment. I'm curious: is the frontend just a dumb display server, or do you run there subset of GUI code responsible for latency sensitive feedback loops (typing, scrolling, dragging, maybe expanding menus etc)? E.g. is it vulnerable to network latency the same way as remote desktop solutions are?
Thanks! Sorry about the slots, I just raised the limit and idle desktops now free up after 10 minutes, so it should be easier to get in.
It's not a display server. Each app's frontend is a normal web page that runs in your browser, in its own sandboxed frame, so typing, scrolling, menus and dragging are all local, just like any web app. The desktop itself (windows, taskbar, the map) also runs in the browser.
What goes over the network is only what the app decides to send: messages and events between its frontend and its backend on the server, over one WebSocket. So latency shows up where any web app would feel it, when it waits for data from its server, not on every frame or keystroke.
The one exception is something like the Terminal, where every keystroke goes to a shell on the host, so it feels like SSH on a slow link.
How tightly is the system tied to React? Can it be run with no React at all?
[flagged]
Yo Dawg, I heard you like web apps..
So I put a browser in an OS in your browser in your OS!