The only thing slowing it down was developer rejection of the austerity of vim and emacs. That’s changing now with VSCode’s in-browser and SSH Remote support. That’s the golden path now at my work. Although we still pay for JetBrains licenses, the JetBrains workflow is quietly and unofficially deprecated.
They have to do this to stay relevant. And I’m glad they’re doing it, because I want my JetBrains-level capabilities back. VSCode doesn’t come particularly close.
Especially in corporate context this will be the future for compliance reasons. No more developers who accidentally have code on their machine and lose it. Less access tokens on the client machines etc.
Will be an interesting trend of going back to the mainframe ... and will be interesting to see how that will collide with developers who want to have control and chose their tools and setup.
We are losing control and open ourselves to the mercy of whatever company.
Google is a great example. Many businesses rely on their services but if some robot bans you then you are majorly screwed.
IMO there's no stopping this trend. However, there's a solution and that is having more choices and competition.
Personally I love seeing this option because it lets me run my dev environment in a local VM. Sadly, I no longer trust community-developed editor plug-ins or dev tools to be free from malicious code. We talk about the problems with npm dependencies all the time on HN. How often do you audit the dependencies of your favorite VSCode plugins? I simply don’t want that code running on my system with full user access, and this architecture lets me avoid that. Of course there are still risks with it having access to dev code, but reducing potential exposure is a good thing.
The integration of VS Code with my C tools are so good that I don't see myself going back.
However this may now make it possible for a person who can't afford the hardware to make his own projects by renting the actual hardware a little at a time, as he has needs for it.
Gitlab codespaces works even if all you have is a locked down school issued Chromebook.
And it is not as if you don't have plenty of options if you want to run the entire thing on your own machine(s).
I like the term rent-seeking. I think conscious devs should be against this.
The server and client is by design separated, which potentially allows to run the server on some other host, and remotely connect to it.
But you can host your own server. And you can also just run it locally, and locally connect to it. You can even bundle it together.
I don't see how this is bad. Only if the server part would not be available to you, then yes, sure, this is bad. But otherwise, this is a very nice and flexible design.
As a student, I have a desktop at one of my parents' house that I can control over ssh, this kind of features make remote development much easier and is often needed when I run an intensive task for hours. The experience with VSCode over ssh is really great. Some have pointed out local VMs, which is another use for this.
So in general I am positive on IDEs that allow some type remote editing experience.
Same here. For me, it is the understanding that every bit of this 'convenience' is adding overhead and latency to what should ultimately just be a text editor with some degree of real-time feedback. I can barely tolerate RDP on a local LAN setup for writing code. Across the internet is a joke, especially if some corporate VPN is in the middle.
Remote tools are totally acceptable when a human isn't in the loop on every frame update. The laws of physics are never going to give us a win-win here. If you want remote tooling + cake (i.e., a low-latency UI experience that doesn't live local), you will need to start deploying this stuff closer to the users' physical locations.
You mentioned RDP which I wouldn't even start comparing to a setup like this. Obviously streaming individual frames, video and the likes over the network is a different beast than having an editor running on a remote machine and only stream commands and keystrokes. For example my ssh sessions don't usually involve a lot of lag and work just fine.
Perhaps this is like how some people swear on their life they cant see the difference between a 60hz and 120hz display. I know individuals who absolutely love all the touch screen controls and fly-by-wire features in their cars.
There is definitely some subjectivity to this. Especially, if the notion of building remote workspaces is cool to you. This would make the little annoyances much easier to ignore.
Some of us are sent right off the deep end by the most trivial of matters. I find myself in this camp. If I consciously detect the network round trip, I am going to immediately fall out of flow and start fucking with settings and checking network conditions. This is a huge liability for me when I already struggle to find focus to write code during the day.
But the tradeoff is increased risk: a single point of failure, a reduction in agency, etc.
There's no one-size-fits-all answer to this question; it depends on the individual case (not just the product, but the customer)
I'd hate to see the existing IDEs like pycharm die
But it feels like a slow errosion of our control and ownership of our tools. Where everything is becoming a rent-seeking opportunity and good tools are made available for a monthly rent.
Personally I like having my whole build system, IDE, CI/CD on a machine I work at. I get this might not be for everyone, but I think we need to be careful what we give up long-term for these conveniences.
Granted, I could just use VI and a terminal and nobody is forcing anyone to use anything ... but like many things, they are not like-choices.
I depend on my tools, and the fewer dependencies to paid-montly SaaS features the better.