Hacker News Reader

Comment by coldtea | Hacker News Reader

>However, I'm not sure who this is for. Downloading and installing an application is not a particularly big ask for the type of people who use VSCode

It's like how nerdy types could easily slap together their own Dropbox, with rsync and duct tape (as per the famous comment), but most didn't - plus the world is not just full of types who'd do it. And then MS can start adding all kinds of collaboration tools built in, from pair coding to bug tracking, time tracking and so on.

I can imagine an enterprise giving devs just this + something like local/Cloud VPS/CI/CD environment to work in. Immediately reproducible, no hassle, secure, and so on.

>The browser version will always be a compromised experience, given the inherent limitation

Well, offline VSCode is a glorified browser as well.

View on HN

"I can imagine an enterprise giving devs just this + something like local/Cloud VPS/CI/CD environment to work in."

That sounds horrible.

It's really freeing when coupled with something like Gitpod or CodeSpaces. You join a new project and you have ZERO setup to do on your own. You can open up a new branch and start working in seconds. I don't have to worry about whether my computer has enough memory to keep up with Docker, if it's fast enough for this new project, if I have to install version managers to separate runtimes for each project (rbenv, pyenv, nvm, etc).

To perform experiments it's even better. I have multiple directories with sample/initial projects from many languages where I was just feeling out a new framework or library or concept. Then months pass and I can't run them again because the specific dependency is no longer installed on my laptop. Now I can create these new study projects and know that it'll run in seconds when I get back to it.

Plus not all of us can work from highly performant workplace-provided workstations. I have just my laptop to work with. Imagine running Docker and Chrome and Spotify and maybe macOS decided that was the right time to hog my disk and do file indexing while I'm running tests...it's a hassle I'm glad to be rid of. I'd rather a company get me a Gitpod/Codespace and I can separate things cleanly.

That is how many of us used to work on UNIX and similar timesharing OSes.

The cloud + browser is back to the future.

Brings back sweet memories of Multics[0], which predated Unix by quite a bit:

[0] https://en.wikipedia.org/wiki/Multics

My first experience with such setup was the DG/UX at the university campus, where we had a mix of classical green/ambar phosphor terminals, and a couple of X-Windows thin clients from IBM to connect to it.

Regarding Multics, it was a failure only for Bell Labs themselves, as the project kept going and had still a couple of years for itself.

https://multicians.org/myths.html

That makes a lot of sense. Thanks for the insight.

>Well, offline VSCode is a glorified browser as well.

Not really, it may use electron for the front end, but a huge amount of what makes vscode useful and fast is the native binaries that power all of its functionality.

What are those native binaries? I know that VSCode ships with ripgrep, but that's the limit of my knowledge. Those binaries probably could be compiled to WASM to make VSCode fully run in a browser too.

The Language Servers that power all of the intellisense and syntax highlighting and stuff are all native code. As are the compilers and everything that make VSCode more than just a text editor.

I think the typescript compiler and language service are implemented in typescript and compiled to JavaScript.

And none of them require Electron, because they run out of process.

well, the browser is not going to provide them.

The server backend will, and this is also a way to run VSCode on system browser without Electron bloat.

Good points, you still have to rely on an OS for all that stuff.

Language servers for any non JavaScript language? Python, rust, Go, C++, and many more.

Additionally the ability to say.. start a web server and run it? The ability to run the actual generated binaries from any of those other languages?

>Additionally the ability to say.. start a web server and run it? The ability to run the actual generated binaries from any of those other languages?

You could trivially had those with VSCode in the browser. They just run on a remote build/CI/CD environment.

> It's like how nerdy types could easily slap together their own Dropbox

Let's be honest, setting up and maintaining your dropbox clone, versus installing one executable once, are not the same kind of "easy".

> And then MS can start adding all kinds of collaboration tools built in, from pair coding to bug tracking, time tracking and so on.

But they can do that just as easily today with the vscode app. The fact that this runs in your browser does not help (or hinder) at all: As you said, offline VSCode is just a glorified browser.

> I can imagine an enterprise giving devs just this

presumably they would have to give you a laptop to access it, and any laptop that can run it in the browser can run it offline, this is 99% the same codebase.

Overall I also don't understand where this fits between offline VSCode and Codespaces. Codespaces makes sense because you don't even have to clone your code, and the compute/build happens elsewhere. Plus collaborative features can be added with no hassle because authentication is already baked in.

But this seems like it brings 0 value over offline, except skipping a 30 seconds install, once.

>But they can do that just as easily today with the vscode app. The fact that this runs in your browser does not help (or hinder) at all: As you said, offline VSCode is just a glorified browser.

On the contrary, it does help a lot. Offline VSCode might be just a glorified broswer, but web VSCode will hook automatically with the vendors development/build/code repo backends. And you could have the appropriate environment (eg. a linux version x, with y libs, and z servers running) per project, available everywhere you go with no setup of your own.

>presumably they would have to give you a laptop to access it, and any laptop that can run it in the browser can run it offline, this is 99% the same codebase.

Yes, and then you can install this or that, diverge from the common environment, and so on. And you have to setup all of those, even if it's just some docker instance running locally or some cloud stuff you access.

With the bundled web-vscode+cloud-backend, you wont have to.

>Codespaces makes sense because you don't even have to clone your code, and the compute/build happens elsewhere. Plus collaborative features can be added with no hassle because authentication is already baked in.

Codespaces is the whole idea behind this too. In other words, this is just a component of codespaces / a codespaces type deal.

> web VSCode will hook automatically with the vendors development/build/code repo backends. And you could have the appropriate environment (eg. a linux version x, with y libs, and z servers running) per project, available everywhere you go with no setup of your own.

But again, that is codespaces. They have rolled this out months ago, and it does exactly what you are talking about, with vscode in the web and all. And I agree that it makes sense.

Vscode.dev looks like it could have been an early prototype of codespaces, with 10% of the features. So I still don't understand why this is coming out after codespaces is already in production.

> Well, offline VSCode is a glorified browser as well.

It's the opposite, you download an OS that runs VSCode. That OS is a web browser. It's just that it's an OS that runs on other OSes.

>That OS is a web browser.

The key point os "glorified browser" being "you still run non-natively in a sandbox, whether it is JS or web assembly, and you still call the DOM for drawing".

Ubuntu is my hypervisor.

I use a mixture of Gitpod, GitHub Codespaces and Proxmox. https://ghuntley.com/anywhere

Why bother with all of that when you could just ssh (nee telnet), remote X or VNC sessions to a server?

Apparently current generation never worked in classical UNIX development environments.

Not to mention corporate rules.

Reply on news.ycombinator.com