A long time ago, way before two or three bubbles came and popped, the world discovered how much fun it can be to edit documents through the Web browser. The early products were simple, but soon companies like Zoho and Google produced a collection of Web applications that were real competitors to Microsoft Office. Today, even Microsoft sells tools that let you fire up your browser to edit documents, spreadsheets, presentations, and almost every other text-based document you can imagine, except one: software.

That programmers don't enjoy the same flexibility and cloud-based simplicity as their glad-handing, techno-clueless business development colleagues is deeply ironic -- programmers are usually decades ahead of the rest of the world, at least when it comes to tools. Why should programmers need to work so hard to develop on their own machine? Why, last week I waited a long time for gigabytes and gigabytes of Xcode tools to arrive from Apple. For some reason, I have to host gigabyte upon gigabyte of libraries on my machine just in case my hundreds of lines of code want to link to any of them. Then Apple dutifully updates Xcode every few weeks, and I get to download the entire thing all over again.

This odd gap is changing, but slower than anyone might expect. Many developers started using cloud-based repositories decades ago, for instance, and they embraced some of the cloud-based build management tools when those came along. Larger shops are already relying on Hudson/Jenkins to watch over their code and make sure the main tree stays pure and buildable. Some companies even offer these tools as services.

The meat-and-potatoes work of development, however, is a far cry from the meat-and-potatoes work of business development or marketing. The programmers are slowly catching up, and browser-based IDEs are appearing. To see how the market is evolving, I spent a few days experimenting with a whole slew of cloud IDEs. I wrote some code, pressed the Build button, and gawked at the "what hath God wrought" that appeared in another tab of the browser. It felt, at times, like I was testing the first telegraph.

The good news is that these browser-based IDEs often look great. Several of them have duplicated the classic IDE layout with a file tree on one side and the editing window on the other. It's like Eclipse but in your browser.

Some of the IDEs are experimenting with structures that are less traditional. The Web is filling up with micro-editors for twiddling with your code, many of them based on open source projects like CodeMirror. The greatest innovation seems to be occuring with the languages that run in your browser. It's a bit unfair to call building a JavaScript page development in the "cloud" just because all of the testing is done in your browser. After all, the browser is the native home for the code. But let's not get too philosophical about it. AJAX pages are a major platform now.

These IDEs are even turning up in places where you might not think of them as IDEs. WordPress, for instance, has an editor module that lets you play around with the PHP and HTML of your website. This is a dangerous tool that gave me all of the power to crash a blog, which I did once or thrice. But the power is seductive and quite useful. You might find yourself rearranging the HTML tags daily because the editor is only a click away.

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.

JSFiddle: Fiddle with JavaScript Few programming chores are purer than writing JavaScript, HTML, and CSS in three rectangles in your browser, then watching it run in a fourth. The code is simple and the browser is already heavily optimized to compile the code quickly and efficiently. Setting up a fast loop of writing and testing is easy. The tool will color and tidy up the code for you.

JSFiddle is the latest in a long line of emerging Web tools. Many big Web properties, for instance, offer "sandboxes" for playing with their API directly in a Web page. I've debugged Google Maps code several times in a window that Google built for experimenting with it. The browser's included debugger is all that's necessary.

Like Python Fiddle, a similar tool that runs Python in a JavaScript emulator in your browser, JSFiddle is meant more for tweaking than creating a monstrous piece of code. The tool builds "fiddles," which are smaller blocks of code that might work best as embedded frames. JSFiddle will host your "public fiddles" and even let you fork and extend them much like a revision control system. There aren't elaborate histories, but something to keep in mind if you want to roll back.

Some developers will see JSFiddle as a tool for experimentation and toys because there's little available for working on the server side of the app. The code can easily call APIs, but you won't build any APIs with it. That would be missing the point. The developers clearly want to encourage more snippets and code that can form the building blocks for Web pages.

Icenium: Mobile dev in the browser When I said above that developers of native code for mobile devices may be among the last to adopt Web-based tools, I left out a curious hybrid path now popular for apps that don't require squeezing every ounce of performance out of the hardware. Some developers are building their iPhone and Android apps in HTML, then wrapping them in a thin layer of native code. This is a fast way to create apps for different platforms, and it can work well if you're not building cycle-sucking apps such as games.

Telerik's Icenium Mist is a browser-based tool for building mobile apps around the Apache Cordova project, the latest version of a thin layer of device-specific code that was once known only as PhoneGap. Icenium Mist lets you create the apps in your browser and run them in a simulator for the different versions of the iPhone. It's a very quick way to spin up an iPhone app. Icenium Graphite, a companion tool that runs on Windows, handles the build, deployment to your device, and publishing the app to the App Store and Google Play.

The good news is that the tool has a solid code browser, a fine editor, and a sturdy connection with Git repositories for saving your revisions. Telerik has already folded in jQuery, jQuery Mobile, and Kendo for building the widgets, but you can replace them with your favorite code. Although the debugging isn't very robust -- the tool often produced inscrutable remarks like "Error: Script error. (URL: , LineNumber: 0)" -- I was able to work around it using the browsers' built-in debuggers. After all, the apps are just HTML and JavaScript, and the so-called simulator is another browser window.

Icenium is enough to build many basic apps for your mobile needs. It's not exactly native code, but that power is not necessary for most basic apps. It's a clever remix of the browser environment with the mobile.

Icenium is free through May and $19 per month afterward, with a discount for purchasing a full year in advance.

Cloud9 IDE: Node, Ruby, Java, and PHP The Cloud9 environment is full of features aimed at the fat part of the dynamic Web app development world: Ruby, PHP, and Node.js stacks. The Cloud9 IDE offers a classic file browser and editor for your projects that can be debugged on their server and deployed anywhere you like.

The environment comes with both a console log and a command line, so you're logged into the Unix directory where your code is running. For grins, I typed "emacs" and it worked. I'm not sure what anyone would do with the command line when a full editor is above it, but it's bound to come in useful for some odd occasions.

The company is generous with free demonstration projects, with the exception of one private workspace that requires your projects be public where others can watch them. The premium membership, which is just $12 per month, offers six private workspaces, plus better access to the shell and the VM. There's also no limit on collaborators, people who can edit your projects with you. The only other thing you might need for bigger development projects is local access to a database like MySQL.

Codenvy IDE: Java and Web stacks The Codenvy IDE is another incredibly rich code development environment with deep connections to a number of hosting platforms like Amazon's Elastic Beanstalk and AppFog. There are at least a half-dozen options, and they light up depending upon which type of application you want to create. The IDE offers three types of Java projects (library, WAR, and Spring) and the classic dynamic languages such as Ruby, Python, and PHP.

Java is clearly one of its strengths. Working in Codenvy IDE is not much different from using Eclipse. Most of the features are similar, and the code highlighting and editorial support are good. When I first started making subtle mistakes with my code (on purpose, of course, in the name of science), the browser didn't react. Then about five seconds later, the mistake was highlighted and flagged. After watching the network traffic, I came to the conclusion that the editor was often phoning home with big JSON packets full of code and waiting for instructions from the mothership before flagging my errors. The quality of the suggestions were great. Codenvy would even flag variables that were defined correctly but not used.

The connection with the various deployment platforms will attract users because Codenvy is a more effective front end for managing your code. There are custom tools for the seven major clouds that make configuration that much simpler. The Amazon dialog, for instance, will let you juggle your instances and data stored in Amazon S3 buckets.