Hacker News Reader

Comment by sirsinsalot | Hacker News Reader

I get a horrible feeling in my stomach when I see these "remote" IDE options. I am very sure that they have their benefits, coding from a thin-client machine and having an "always on" session in the cloud ...

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.

View on HN

JetBrains makes money selling to corporate engineering orgs. In that context the incentives towards remote development environments are very strong. You can get a developer immediately productive (again) by restoring a golden image. Instead of paying engineers to optimize the build or write IDE plugins to index manageable subsets of the codebase, you can just throw power at it. Remote dev environments at my company have 96 cores. The monorepo builds in about a tenth of the time. Unfortunately I think it’s inevitable.

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.

Just to add reasons:

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.

The very first step of our engineering onboarding process is to turn on FileVault...

As another data point, I buy a license to all Jetbrains IDEs as a private individual. The non-remoteness and the fact my license is for a perpetual installed version matters to my livelihood. It's also a known cost where many things get more PAYG

I love the idea of a remote IDE, especially when i'm compiling heavy apps in xCode/Android Studio but i have to agree.

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.

It’s an option, just as it is for VSCode.

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.

No wonder developers complain about sluggishness and running out of memory when they're literally using a headless web browser to write code. Sublime Text works brilliantly. I can have tens of projects, hundreds of files open and the memory usage is peanuts. I don't get the hype about "modern" IDEs let alone remote IDEs.

I'm sure you already know this, but I used to use sublime text and moved to an IDE because of the debugging features. Sublime text and a terminal is great for simple problems, but you'll cost yourself a lot of time doing print statements when you could just use an IDE.

This is perhaps more related to the language than you think. Many languages have good debugger support from a terminal.

Sublime Text is handy for doing text manipulation and jumping around files. I use it in addition to Xcode for that sort of thing. I know some vim but not enough to use it this way. I hope Fleet is closer to ST in speed than I’ve heard VSCode is sometimes.

I always used ST even after trying VS Code and Atom some years ago, but some weeks ago installed VS Code to try GitHub Copilot and I haven't already gone back.

The integration of VS Code with my C tools are so good that I don't see myself going back.

I can totally understand the feeling, but I read this as just as much an opportunity for the other way around.

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).

Agreed, if you subscribe to there being such a thing for “software craftsmanship” then you might also expect to have some reverence for the tools being used.

I like the term rent-seeking. I think conscious devs should be against this.

But this is here just about the software architecture design. This is kind of similar to the X Server and Client architecture. Or to games like Quake 3.

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.

That WOULD be great, IF they open sourced the server side. Otherwise, it's just one bad day away from some manager pulling the old switcheroo, and making the server a paid "pro" thing.

Or, more in vein of recent business trends, some company acquiring the technology, and THEN making it pay-to-play.

JetBrains IDEs are commercial, proprietary software. In my opinion well worth the price.

They won't open source it but I imagine they will allow you to run a version of it inside your corporate firewall, at a premium price, just like their 'Code With Me' server.

Don't forget that we are not just talking about the IDE, but increasingly being integrated with cloud-first tools like Space ...

While I don't doubt the goal is cloud, it's not the only use.

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.

I know you are mainly commenting on "cloud remote" things, but I do want to mention that I find VSCode's "remote ssh" mode very useful, and I use it frequently when I'm sitting at my windows desktop and I want to edit code on the headless linux machine in my basement.

So in general I am positive on IDEs that allow some type remote editing experience.

> I get a horrible feeling in my stomach when I see these "remote" IDE options.

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.

But here I have to ask what your experience with such remote setups is? I used the remote features of Visual Studio Code a while back because I needed a beefy machine that was integrated into a specific remote service landscape. I have to say I couldn't really notice that it was running remotely. But that probably depends on your company and how weird their network setup is.

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.

> I have to say I couldn't really notice that it was running remotely.

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.

I think it's the classic efficiency tradeoff. Centralizing these tools is more efficient for the vendor, for the IT department, for users. It streamlines a bunch of things.

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)

The track record with these centralisation trends is that standalone tools get less and less features and attention then die out, leaving little choice.

I'd hate to see the existing IDEs like pycharm die

Interesting. Would/could this be a motivating function for open source alternatives?

Remote IDEs aren't necessarily about subscription based SaaS. For me any editor that can't be run by ssh into a workstation within the build-farm is a non-starter.

If you want to access a higher capacity VM or a large data collection that doesn't fit locally then it's justified.

I would much rather pay monthly than pay my LTV all up-front. I can't afford thousands of dollars for an IDE

On the subject of Apple making macOS a closed ecosystem, ala iOS, I have commented that they can't. They have to keep macOS a general purpose OS in order to write iOS apps. Someone else responded that they could move all iOS development to tools running in the clown, and this prospect makes me very nervous. I, too, like everything running locally, and have no desire for ANY of these remote tool ideas. It "solves" problems -- which I perceive -- relatively few of us have, but which companies would LOVE to corner the market on, and lock people into yet another walled garden.

Reply on news.ycombinator.com