Browser based IDE

I'm spending a lot of time using the web browser, either to read my emails, check my build status on Hudson or see the latest changes on BitBucket.

Most of the stuff I produce is destined to live on some server: emails, blog posts, wiki pages, issue tracker comments, source code changesets, build tags and even the builds themselves. This means that, most of the time, the local data is just a temporary cache until I do my task.

But modern day web applications should provide just this: a way to do you task using a local cache and then publish it to some remote server.

The IDE is a prime candidate for a serious web application: your projects are always in some version control system, developers really care about their IDE configuration and the server could really help with the workflow and build times.


Your projects are always in some version control system

The local cache is just a matter of convenience, what you really care about are your local source code changes which become your changeset.

Losing the local cache shouldn't be a problem other than the inconvenience of waiting for a re-download. Treating the local source code tree as something transient will encourage better practices like simpler workspace configurations.


Developers really care about their IDE configuration

Installing the IDE on a new machine means spending time re-adding your preferred tab-size, formatting options and so on. A web app will just store that in your user preferences.

The server is very good with caching and indexing


There's nothing more annoying than noticing how much time the IDE spends indexing or processing very popular libraries like Apache Commons.

Imagine how much CPU has been used world-wide indexing the same library over and over just so you could see some methods in a code completion popup!

All that wasted developer time might have been replaced by having the server index and cache a given library version and then just download (part of) that index when needed in the browser.

The server is very good with large builds


If the backend server if powerful, you could offload large builds to the server too. An artifact might take a lot of time to compile on your local machine, but it might run a whole lot faster on a powerful server or distributed on some build cluster.

If the time it takes to build on the server plus download the artifacts on your machine is much slower than just compiling locally, why not do it ?

Plus, you could even share the build artifacts with your team! Using some server-side approach, you could just ask the IDE post the build on the server and share the artifacts among the team (yes, I know about Maven repositories).

Web developers' dream

But I'm writing this from the perspective of somebody that does desktop applications (NetBeans Platform based, actually). What if you are writing a web app ?

Well, after you press "deploy" you just let the IDE upload your app to the test server and just open another browser tab.

Or, you press "deploy" which commits your changeset to the IDE backend server that saves it into your local history then uploads the new app to the test server. Pretty soon all the hard work happens behind the scenes and you are free to work on huge builds using really low powered netbooks.

And if you only upload / download changesets, you just might be able to work over dial-up!

Thin, Thick, Remote client ?


Of course, there are a few moments when developers are offline or when the bandwidth isn't abundant, so I don't view this browser based IDE as a remote client or a thin client that sends everything to the server.

I see it more of a thick client -- it's just as usable offline but much faster and convenient online when offloading work to the server too.

Some of the features listed above would only work if the server does your builds and has access to your source code. So they wouldn't work if you are just using the IDE to work on private projects, that remain on the local machine and never touch the IDE's backend servers.

To be continued...


This is just a first blurb about how I imagine a browser based IDE and I'm looking forward on seing it happen either as some Javascript thing or as some NetBeans fork running as a super-applet with local permissions.

Google might be serious about Chrome OS and their Cr48 laptop, but they don't mean business until I'm able to develop on one too.

This might also be the end of the IDE acronym because I'm not talking about an integrated development environment but a distributed development environment.