upvote
Why do most developers not like it? Is it because the browser is a terrible platform for text editors since there is no proper key mapping, or access to proper debuggers, or there is too much latency, and no access to cli tools?

You make it sound like you are surprised, but everyone who has tried this knows it's crap and a band aid at best.

reply
I really tried to give vscode an honest shot.

I couldn't find anything about it that was even half as good as a real text editor.

It made writing code feel like a chore. I usually love writing code.

reply
What is a real text editor, by your estimation? NVim? Emacs? Genuinely curious.

I use VSCode/Codium since I maintain a GUI stack for general usage. But I have all the terminal tools installed for my work there as well. I hate customizing things too, which I find is necessary if you want to get the most out of terminal text editors. VSCode is pretty good out of the box, with terminal access and everything built in.

Jeez, I hope this doesn't turn into a text editor flame war...

reply
I hope folks know they can use Codespaces in their desktop editor. I never use the web editor.
reply
Why would I ever want to use a browser based solution instead of local VMs? If you're worried about VM escapes then you have bigger problems (and hopefully a full time security team supporting you).

Edit: I realize in hindsight this comes across as overly negative. I think those are great solutions to have available for when you are working with a suboptimal local setup for whatever reason. I just don't think they're the default choice let alone any sort of ideal to strive for.

reply
Web-based IDEs like VSCode on github just had a 1-click github token stealing vulnerability: https://blog.ammaraskar.com/github-token-stealing/

You could argue this is probably on GitHub for creating a token here that gives blanket access to all repos vs a scoped token for just the repo.

reply
Is the theory here that the browser cannot be co-opted to infect web-based repositories? Also: thinking of how yt-dlp can integrate with browser cookies now and the malware paths that opens up. (This is part of why Chrome wants HSM cookies, I expect: DRM and opsec!)
reply
In this scenario the malware will not be on the device but in an isolated dev environment on a remote machine. So it will have access to whatever was configured in that repo but hopefully the project is isolated enough to ensure containment and prevent cross-pollination.
reply
I don't think the cloud (someone else's computer) is the best solution. The sanitation problem can be mitigated by compartimentization but the cloud aspect also adds brittleness and new attack vectors.

Why not set up proper containers (or VMs) locally? And why not wait a little till local LLMs catch up?

Maybe just a personal itch, but having your dev environment elsewhere feels so gross to me..

reply
That is the problem. You outline perfectly how a developer sees the situation.

On the other hand ephemeral cloud environment with proper security controls makes a lot of sense if the goal is to isolate and control.

If everyone was following the protocol we wouldn't have had the problem to begin with.

reply
That’s a big, labor-expensive if.
reply
This is the leg of the cycle when we go back to mainframes & centralized computing? With all the datacenter build out; why wouldn't you want your services adjacent to the LLM processing centers?
reply
> I think web-based IDEs like GitHub Codespaces (but even VSCode with tunnels) is part of the solution

I am against proprietary SAAS online in browser dependencies.

reply