Author here. HN in a lot of cases has readership that I’d put in the segment of developers that should absolutely not be using Cloud9 daily.

I personally take using Cloud9 to the absolute extreme(https://www.trek10.com/blog/i-buy-a-new-work-machine-everyda...), having my Cloud9 env setup scripted and creating a new one every day/project. I don’t really recommend that approach for most folks. Anecdotally, it has paid off well when I left a Mac on a train and I was able to walk in an apple store grab a new one and lost minimal productivity for the day.

However, the flip side of all this is I regularly work with a lot of IT people that have underpowered machines, flaky / poor internet, crazy restrictions on their work machines that cause all sorts of problems with CLI / program installation, etc. I’ve found Cloud9 to be super liberating for those folks particularly with the parity of Cloud9 to AWS Lambda runtimes.

We do a lot of gpu server stuff and are victims of Apple vs Nvidia BD teams being broken. The remote solution we came to is VS Code's remote mode that tunnels over ssh (dir list, edits, git tracking, ...) yet maintains your normal native IDE responsiveness.

The 95% is still local, but makes remote more ok when ci + jupyter + quick vim isn't enough.

Thanks for the great content!

Appreciate you!

You probably aren't in a bubble, but the whole edit through the browser, cloud-native editors are really becoming interesting. The interesting part is more the integration of dev, testing and deployment into the editor in a way you just can't do without a lot of devops work with a traditional IDE.

I don't think you're in a bubble, but we've recently started evaluating Coder and have found the switch to a cloud-based IDE (especially when you add Progressive Web Apps to the mix for native keyboard shortcuts) has been extremely attractive. I'm finding myself more and more drawn to hosted IDEs where I don't need to worry about network performance or how the Docker VM on my Mac is eating up my battery life...

I use Cloud9 for 100% of my projects. I don’t have to worry about dependencies on my local machine or virtual environments or local resources or permissions or disk space. It stops charging for use when I stop using it so my average AWS bill is in the single digit dollars per month. I can use whatever machine I want because it’s just a dumb terminal.

I am a big fan, have been since before Amazon bought it. I’m shocked more vendors don’t have something similar.

Yes! Slowing down all software development seems like an overreaction to the risk of dev/prod environment differences. Good architecture design, modular components, and isolated unit tests should really minimize the number of times this will become a problem. I can't imagine giving up the productivity improvements of insert-fav-ide-here to address unforeseen or even hypothetical bugs.

I use it quite often, but as a tech-blogger, I'm an outlier.

I write about AWS products and it's quite nice to get an IDE preinstalled with AWS CLI tools with the push of a button.

For JS it's mostly an okay-ish IDE, not as good as VSCode, but okay.

For things like Rust or Reason it sucks quite much.

IME Cloud 9 is helpful for building applications where you need public endpoints (like if you're using OAuth) or in cases where you want a Linux environment but are on windows/OSX/chromeOS. But I would pass for everyday use.

I don’t use it as my primary editor/IDE, but it is convenient if I’m on my iPad. Setting up the environment and connecting it to your Git repo makes it very easy to debug in a pinch.

I wouldn’t be opposed to a cloud-based primary IDE (as long as it functioned offline), but I don’t think we’re there quite yet.

So it’s not my primary IDE, but it’s a solid backup.

I used it as my full-time IDE for a while when I only had a chromebook. I like what it offers but it just wasn't performant and responsive enough to live in it all day IMO.

Our startup used this setup in 2013 when I guess it was a much more hipster thing to do! We used Cloud9 connected via SSH to our sandbox AWS account, edited code in the cloud, restarted the Node server running dedicated to each developer's sandbox, and had a sandbox URL per dev (e.g., jake-dev.startup.co) to see the code update live.