Here's an idea: we need an IDE experience that bridges the web browser with the editing environment.

Doing it all in the browser is a bad idea. I won't go into why, except perhaps that textarea remains so horribly bad as to make the idea practically laughable. But I also think that editing and the browser can be seen as separate experiences beyond just key bindings.

Still, the web browser provides a compelling target in a lot of ways. It kind of occurred to me when I saw this example of HTMLTestRunner. Maybe I got distracted by FIT, which is a kind of non-programmer interface. There's lots of other in-between web apps, like the stuff in the TurboGears toolbox, Paste's interactive exception reporter, and elsewhere (as in some of the web-based interactive consoles).

Still, there's a context switch. Yes, it's nice to see stuff in a web browser -- with a simpler and often more complete UI experience than an IDE -- but I still like my editor. So how to bridge this?

I'm thinking Zope's ExternalEditor is one model (particularly the zopeedit side). It uses WebDAV (a subset, really -- the methods it uses are very limited) to open an editor. But this does lose some of the experience of an actual local file. But that's relatively easy to change. Either way, it involves sending some custom mime type (e.g., application/x-zope-edit) that sends information about the file (auth header and URL for zopeedit, maybe a host and filename would be another option). And maybe other little tweaks, like a line number. (E.g., click on a traceback frame to open the editor on that exact point.)

Hmmm... something to think about, and not just for web development. Maybe it's just because I'm more comfortable with web programming and Ajaxy stuff, compared to GUI development, but this seems much more approachable for developing an full development experience (not integrated) than trying to build or extend a traditional "full" IDE. Or maybe it is to say that this seems more appealing than console-based non-integrated development environments. For example, I think the interactive debugger is way easier to use than pdb even if it has less features. (But again, because this is a non-integrated environment, it is quite possible that you could swap in a traditional GUI debugger like Winpdb).

Another goal I see, is that with a non-integrated environment it is much easier to build framework- or application-specific tools that "fit" into the system, if only because there's such a low bar for "fitting".