Review: 4 killer cloud IDEs

Browser-based JSFiddle, Icenium, Cloud9, and Codenvy stretch from client-side JavaScript and HTML5 to server-side Java and Web stacks

1 2 3 4 Page 2
Page 2 of 4

Cloud power, cloud latency

The not-so-good news about the browser-based IDEs is that the fun often ended with the press of the Build button. The systems still largely do the job, but the lag can turn into a real drag. Your experience will vary depending upon the speed of your Internet and the code you write. Mine fluctuated immensely with the day and the rain. (One of my Internet links is wireless.)

The performance was often acceptable, but it was never as fast as running a local IDE on a machine with enough power and RAM. While much of the lag was probably caused by the network latency, I wouldn't be surprised if some was due to the CPU sharing common in clouds. Nothing beats having your own eight-core machine sitting at your desk.

Well, that's not exactly true. For most tasks, building the code wasn't very complicated and the network latency was very, very noticeable. Big projects, though, might gain significantly from the cloud. CloudBees, for instance, has a raft of machines just waiting to jump on the builds. If your build is made up of N independent tasks that can run simultaneously and your value of N is large enough, there's a good chance the N tasks will run simultaneously on N machines in the cloud. Even the fat eight-core machine on your desk can't do that.

For now, I think the attractiveness of cloud-based IDEs will depend heavily on the type of code and the size of the build. People building Web apps that run in the browser will be the most likely adopters, in part because the cloud is often storing the files. The latency doesn't get in the way very much.

The next may be geographically diverse build teams that are working together on the same files. Atlassian, the dev tool company known for issue management software like Jira and Git hosting services like Stash, is at work bolting a pairs-programming editor onto Firebase. This is bound to lead to more collaborative editing done over distances greater than two feet. The IDEs here also unlock geographically diverse pairs programming. Heck, you might even call it triple or quadruple programming.

The older teams working on code in Ruby or Java will take a bit longer. The network latency may be the biggest hassle for them. When I tried to work through a build-debug-fix cycle, I spent too much time wishing for that old behemoth Eclipse and key clicks didn't take a roundtrip on the Internet.

Tools like Xcode, which build native apps that need to connect to hardware like an iPad, will be the last to go. This observation, though, doesn't hold for programmers building their mobile apps out of JavaScript and HTML. The browser is their native environment, and it's a great place to work.

The myriad complaints aren't inescapable road blocks that indicate long-term limits for the tools. The browser code will get smarter, and the foundation for local files, local data, and larger libraries is already baked into HTML5-compatible browsers. The creators of these tools will be moving more and more intelligence to the client, which will eliminate many of the headaches associated with waiting for the events to make a roundtrip on the Internet. This will happen rapidly. In a few years, not many desktop IDEs may be left.

1 2 3 4 Page 2
Page 2 of 4
How to choose a low-code development platform