Interesting. It seems to me that client side prediction and lag compensation (aka the basics for games in similar situations) would have been a viable alternative.

▲

mnazzaro 7 hours ago | parent | next [-]

While I can see that working well for echoing keystrokes in a terminal, I'm not sure how it would work when you actually enter commands into the terminal. Same for opening files in the IDE.

▲

mlhpdx 7 hours ago | parent [-]

I didn’t get that the IDE is running on both sides, if that’s true. Wow.

	▲	mnazzaro 7 hours ago \| parent \| next [-]
		Yup! There's a language server and file server running in the sandbox that the editor on the frontend interacts with.
	▲	formerly_proven 7 hours ago \| parent \| prev [-]
		This is why most IDEs nowadays ask you something about "trusting files" when opening a project. They tend to lick and run on everything in there (at least for dynamic-ish languages, and maybe not "run" intentionally but do stuff which is arbitrary code execution more or less by definition) to analyze the code.

▲

jgtrosh 7 hours ago | parent | prev [-]

These rely on undoing within a game's constrained environment. There isn't a way to magically undo any possible procedure with side effects.

	▲	mlhpdx 7 hours ago \| parent [-]
		How so? Perhaps I don’t understand the context. Undoing text display is trivial, undoing code changes is already there, what’s missing? We’re not talking eons, less than a second.