[merb]

> be to re-implement the Electron API's that Code uses in HTML5 Javascript with local storage, such that VS Code could run entirely as a HTML5 web application.

This does not look fancy. Microsoft uses VSCode for their online Editor in Azure and VSS: - https://channel9.msdn.com/Series/Visual-Studio-Online-Monaco

Or to say it differently, at least the Editor part is working directly inside the browser: - https://github.com/Microsoft/monaco-editor

(P.S.: I'm not related to Microsoft, I just tumbled upon while trying to work with App Services on Azure)

[headmelted]

Totally agreed, the Monaco component is already in place and pre-dates VS Code.

It raises queries about what you do after the editor is running though (i.e. where does your terminal live? What about your interpreters/compilers?).

It quickly gets to the point of looking at SSH to another box like Cloud9 does it, at which point you may as well just run Code there and remote to it.

[skybrian]

Not really buying it. Sending each keystroke and paint update over the network isn't a great experience on slow networks; even just ssh has noticeable lag. (Mosh is designed to fix this, but it's not trusted in most places yet.)

Being able to run the UI locally and using ssh to load/save edits to files seems like a better way to deal with latency.

[nilliams]

Huh? For an editor in the browser you don't send every keystroke and paint update over the network. The UI is effectively local, you would only need to send regular network updates for 'autosave', and it wouldn't be to keystroke granularity.

[skybrian]

I meant the part about "may as well just run Code there and remote to it". Running in the browser reduces latency when it avoids a round trip.

[nilliams]

Ah I missed that, sorry.