8 ms·

Wow. This is going to be a major game changer for remote development work, and it's a perfect counterpoint to the "Electron is stupid just write it in C" that w

Wow. This is going to be a major game changer for remote development work, and it's a perfect counterpoint to the "Electron is stupid just write it in C" that we hear a lot. Because of the flexibility provided by separating the Node-based logic and processing layer from the web-based presentation layer, VS Code lent itself well to this kind of innovation. Of course, browser-based IDEs aren't new. But they've always been a beast of their own; this will work seamlessly with the tight VS Code integrations numerous languages and frameworks have.

celrod 8y ago
I'm a huge fan of RStudio server. I splurged on an expensive desktop, while I'm using an old laptop with an i3 processor and 4GB RAM my brother gave me. RStudio server let me work from the same R sessions, wherever I was, while giving me (high end) desktop performance for running simulations like MCMC, wherever I was -- from R. I did similarly with Jupyter for Julia, but I always preferred Atom/VS Code. So my work flow, away from home, was using things like remote-ftp and ssh. But I can't seamlessly continue a session I had at home from my laptop. Needless to say, I am excited about this.
- movedx 8y ago
  Looks good, but it's for R only, I guess?
  - rpier001 8y ago
    Effectively. These days you can use a Python kennel in notebooks and get syntax highlighting, but not much else. Python and SQL are supported but second class use cases.
    - cwyers 8y ago
      The new version (in preview) has better Python support: https://blog.rstudio.com/2018/10/09/rstudio-1-2-preview-reticulated-python/ https://blog.rstudio.com/2018/10/09/rstudio-1-2-preview-reti...
      - celrod 8y ago
        Yes, I was quite happy with reticulate, when I tried it. I like the workflow of working on code in a script, with hotkeys to run code blocks in the REPL and jump to the next block. If I am actively working on code, I'm unlikely to want to run the entire file, but that is the default in Python for VS Code, for example. So in terms of quickly getting comfortable and focusing on the work, reticulate with RStudio worked well for me. I also like it more than Jupyter, unless you're making reports where mixing code with markdown and LaTeX is great -- although RStudio supports this too. But I've also used a lot more R than Python, and am already comfortable with RStudio. For someone who hasn't used RStudio before, there's probably better options to jump into Python for data analysis. I brought up RStudio Server in the first place because I find it to be convenient, and even use it at home in place of RStudio Desktop, so that I can resume the same session I left at home remotely on my laptop. Code-Server looks like the equivalent of RStudio Server. While I still haven't tried code-server (still planning on it -- just haven't yet because I'm not used to downloading and running binaries I find online), it has those same benefits, and much broader language support. I am happy to see it.
pimlottc 8y ago
Can you elaborate on the remote development use cases you have in mind? I struggle to see what makes this better than developing locally and pushing/pulling code via git or some other VCS.
- harshitaneja 8y ago
  My work involves a lot of smaller scripts that need to run on very large datasets. Git was impractical for the frequency of my pushes so I resorted to the old scp or ssh and paste to my workstation. With this I can streamline my whole process.
- halbritt 8y ago
  There are many cases where there is a desire not to have a company’s code base floating around on people’s laptops. For these folks remote development is a good option. It mitigates the risk of losing intellectual property. My understanding is that much, if not all development at Google works like this. I don’t know their specific policy but a friend works on a similar project internally.
  - kyrra 8y ago
    Google devs access the repo locally most of the time through a FUSE file mount. So the code is never written to local disk, but still accessible locally as far as you can tell. (The other ways of writing code aren't publicly mentioned yet in any talks or papers that I know of, so I'll leave that one alone) From the 2016 ACM paper. > Most developers access Piper through a system called Clients in the Cloud, or CitC, which consists of a cloud-based storage backend and a Linux-only FUSE file system. Developers see their workspaces as directories in the file system, including their changes overlaid on top of the full Piper repository https://m-cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://m-cacm.acm.org/magazines/2016/7/204032-why-google-st...
- kmundnic 8y ago
  Scientific computing, specially when you'd like to do visualizations of data that is big/can't leave the server. It's also possible in Jupyter notebooks using port forwarding, but I don't see it for development involving data, as much as for data exploration or presentations.
flukus 8y ago
> Because of the flexibility provided by separating the Node-based logic and processing layer from the web-based presentation layer, VS Code lent itself well to this kind of innovation. Game Changer? Innovation? This sort of thing has been possible with x-windows for decades.
- deleted 8y ago
  [deleted]
- morpheuskafka 8y ago
  X forwarding is totally unusable over crowded, throttled, public WiFi or even good internet speeds with hardly any latency at all. The web is designed for those environments.
foxes 8y ago
Imagine needing the complexity of docker, browsers, vs code when a much simpler (and compared to this which is running in http? - secure) tool already exists :), ie ssh -X
- haolez 8y ago
  Or simply mount a dir with sshfs or similar :)
- bitwize 8y ago
  No. The X protocol is objectively shit. It's so shit, modern toolkits don't even fully use it anymore. Instead they do all rendering locally and pipe the composited pixmaps over to the X server via DRI. Over a network, guess what? No DRI. Meaning uncompressed pixmaps get sent over that network link every time a redraw happens. Wayland, Pipewire, and H.265 will be a much better general solution to remote desktop access. In the meantime, VSCode via browser is a MUCH better approach than trying to forward it over X over any but the fastest network links.
  - kristianp 8y ago
    To clarify your statement about Wayland, it doesn't support remote desktop access in itself [1]. A remote desktop server would sit on top of Wayland. [1] https://wayland.freedesktop.org/faq.html#heading_toc_j_8 https://wayland.freedesktop.org/faq.html#heading_toc_j_8
- asutekku 8y ago
  I’d rather use the tooling of VSCode than ssh into some shoddy configuration of vim
  - flukus 8y ago
    > I’d rather use the tooling of VSCode What they're suggesting allow you to do just that.
- jpambrun 8y ago
  I tried that in the past and it's unusable over typical internet latency.
sjellis 8y ago
"browser-based IDEs aren't new. But they've always been a beast of their own; this will work seamlessly with the tight VS Code integrations numerous languages and frameworks have." Yes, I evaluated AWS Cloud9 and walked away, because it was obvious that it could never compete with the ecosystems of the major editors. New tools and frameworks will keep coming, and proprietary cloud developer environments won't keep pace. This project or Theia[1] look much more viable, if they can maintain enough compatibility with VS Code. 1: https://www.theia-ide.org/ https://www.theia-ide.org/
- anton_kosyakov 8y ago
  Theia relies only on stable and documented APIs for compatibility which are not move fast and don't get removed, not on patching and exposing of VS Code internals.

celrod 8y ago

I'm a huge fan of RStudio server. I splurged on an expensive desktop, while I'm using an old laptop with an i3 processor and 4GB RAM my brother gave me. RStudio server let me work from the same R sessions, wherever I was, while giving me (high end) desktop performance for running simulations like MCMC, wherever I was -- from R. I did similarly with Jupyter for Julia, but I always preferred Atom/VS Code. So my work flow, away from home, was using things like remote-ftp and ssh. But I can't seamlessly continue a session I had at home from my laptop. Needless to say, I am excited about this.

movedx 8y ago
Looks good, but it's for R only, I guess?
- rpier001 8y ago
  Effectively. These days you can use a Python kennel in notebooks and get syntax highlighting, but not much else. Python and SQL are supported but second class use cases.
  - cwyers 8y ago
    The new version (in preview) has better Python support: https://blog.rstudio.com/2018/10/09/rstudio-1-2-preview-reticulated-python/ https://blog.rstudio.com/2018/10/09/rstudio-1-2-preview-reti...
    - celrod 8y ago
      Yes, I was quite happy with reticulate, when I tried it. I like the workflow of working on code in a script, with hotkeys to run code blocks in the REPL and jump to the next block. If I am actively working on code, I'm unlikely to want to run the entire file, but that is the default in Python for VS Code, for example. So in terms of quickly getting comfortable and focusing on the work, reticulate with RStudio worked well for me. I also like it more than Jupyter, unless you're making reports where mixing code with markdown and LaTeX is great -- although RStudio supports this too. But I've also used a lot more R than Python, and am already comfortable with RStudio. For someone who hasn't used RStudio before, there's probably better options to jump into Python for data analysis. I brought up RStudio Server in the first place because I find it to be convenient, and even use it at home in place of RStudio Desktop, so that I can resume the same session I left at home remotely on my laptop. Code-Server looks like the equivalent of RStudio Server. While I still haven't tried code-server (still planning on it -- just haven't yet because I'm not used to downloading and running binaries I find online), it has those same benefits, and much broader language support. I am happy to see it.

pimlottc 8y ago

Can you elaborate on the remote development use cases you have in mind? I struggle to see what makes this better than developing locally and pushing/pulling code via git or some other VCS.

harshitaneja 8y ago
My work involves a lot of smaller scripts that need to run on very large datasets. Git was impractical for the frequency of my pushes so I resorted to the old scp or ssh and paste to my workstation. With this I can streamline my whole process.
halbritt 8y ago
There are many cases where there is a desire not to have a company’s code base floating around on people’s laptops. For these folks remote development is a good option. It mitigates the risk of losing intellectual property. My understanding is that much, if not all development at Google works like this. I don’t know their specific policy but a friend works on a similar project internally.
- kyrra 8y ago
  Google devs access the repo locally most of the time through a FUSE file mount. So the code is never written to local disk, but still accessible locally as far as you can tell. (The other ways of writing code aren't publicly mentioned yet in any talks or papers that I know of, so I'll leave that one alone) From the 2016 ACM paper. > Most developers access Piper through a system called Clients in the Cloud, or CitC, which consists of a cloud-based storage backend and a Linux-only FUSE file system. Developers see their workspaces as directories in the file system, including their changes overlaid on top of the full Piper repository https://m-cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://m-cacm.acm.org/magazines/2016/7/204032-why-google-st...
kmundnic 8y ago
Scientific computing, specially when you'd like to do visualizations of data that is big/can't leave the server. It's also possible in Jupyter notebooks using port forwarding, but I don't see it for development involving data, as much as for data exploration or presentations.

flukus 8y ago

> Because of the flexibility provided by separating the Node-based logic and processing layer from the web-based presentation layer, VS Code lent itself well to this kind of innovation. Game Changer? Innovation? This sort of thing has been possible with x-windows for decades.

deleted 8y ago
[deleted]
morpheuskafka 8y ago
X forwarding is totally unusable over crowded, throttled, public WiFi or even good internet speeds with hardly any latency at all. The web is designed for those environments.

foxes 8y ago

Imagine needing the complexity of docker, browsers, vs code when a much simpler (and compared to this which is running in http? - secure) tool already exists :), ie ssh -X

haolez 8y ago
Or simply mount a dir with sshfs or similar :)
bitwize 8y ago
No. The X protocol is objectively shit. It's so shit, modern toolkits don't even fully use it anymore. Instead they do all rendering locally and pipe the composited pixmaps over to the X server via DRI. Over a network, guess what? No DRI. Meaning uncompressed pixmaps get sent over that network link every time a redraw happens. Wayland, Pipewire, and H.265 will be a much better general solution to remote desktop access. In the meantime, VSCode via browser is a MUCH better approach than trying to forward it over X over any but the fastest network links.
- kristianp 8y ago
  To clarify your statement about Wayland, it doesn't support remote desktop access in itself [1]. A remote desktop server would sit on top of Wayland. [1] https://wayland.freedesktop.org/faq.html#heading_toc_j_8 https://wayland.freedesktop.org/faq.html#heading_toc_j_8
asutekku 8y ago
I’d rather use the tooling of VSCode than ssh into some shoddy configuration of vim
- flukus 8y ago
  > I’d rather use the tooling of VSCode What they're suggesting allow you to do just that.
jpambrun 8y ago
I tried that in the past and it's unusable over typical internet latency.

sjellis 8y ago

"browser-based IDEs aren't new. But they've always been a beast of their own; this will work seamlessly with the tight VS Code integrations numerous languages and frameworks have." Yes, I evaluated AWS Cloud9 and walked away, because it was obvious that it could never compete with the ecosystems of the major editors. New tools and frameworks will keep coming, and proprietary cloud developer environments won't keep pace. This project or Theia[1] look much more viable, if they can maintain enough compatibility with VS Code. 1: https://www.theia-ide.org/ https://www.theia-ide.org/

anton_kosyakov 8y ago
Theia relies only on stable and documented APIs for compatibility which are not move fast and don't get removed, not on patching and exposing of VS Code internals.