There's a big disconnect here; if you think there's some compelling use case for having shared state in a central location, then anything that gives your central service access to that shared state will meet that need. That does not mean this shared location is necessarily "the cloud", nor does it mean you "must" actually literally serve the IDE out of the cloud so it can live in the browser. That's just today's mantra, tomorrow's will be something else. You simply must have the state moved somewhere where it can be analyzed, or even simply shared P2P with no central node.
This is taking on an immense amount of pain for what sounds like gain that can be had for far cheaper in every conceivable way with a much simpler and less boil-the-ocean approach. Whatever benefit you think this is going to bring when it's done, why not prototype that now?
>Whatever benefit you think this is going to bring when it's done, why not prototype that now?
The biggest benefit is removing the need for a configured, physically accesible, machine in order to do your work.
Imagine visiting the parents for a weekend and being able to fix a small but urgent bug and do a commit using either something you have with you (like your webkit-based device) or what they have there (low-powered machine). Using a browser seems the most natural.
Don't the various methods of attaching to a remote desktop work well enough? I sometimes work in an IDE remotely on Windows using the native RDC or just VNC. Works great, smooth and fast, I would be happy to work that way for a couple of days if I was without my own machine. I don't see a big upside to sinking huge time and effort into a Web IDE when remote desktops fill most of the important use cases.
Also, how many developers are you thinking will be sharing the server using a Web IDE? For any compiled language I see compilation steps as big CPU hogs, severely limiting shared usage. Even with interpreted languages I suspect there would be CPU-sharing problems. Again, remote desktop seems a better solution.
As someone who is leaving my current job in large part because it forces me to work in a godawful web-based IDE, I think you need to think really, really hard about your motivations here. What problem does an IDE webapp solve which can't be solved any other way? Also, what problem does an IDE webapp solve which is so terrible, such an impediment to progress that it justifies throwing out the decades worth of development tools and experience we have on the command line or in traditional IDEs?
Honestly I've yet to come across such a problem. And any such benefits my company's internal web-based IDE might provide are entirely outweighed by the loss in productivity that comes from no longer having access to diff and patch and Unix pipes and vim and Git and all the other tools I've become entirely accustomed to on the Unix command line. Honestly, a MindTerm applet and a Unix shell account on a remote server would be a more functional "web-based IDE" than any I've seen, and certainly more functional than the one I'm leaving.
Obviously given enough time all of those tools could be replicated in a web-based environment, but why even bother? What's the killer app here?
> The IDE must be accessed via a standard browser and
> should be installable (ie. your own startup should be
> able put it on a dedicated server).
SSH is available on every reasonable development machine, I can SSH to some server and access Emacs, either via X forwarding or over the terminal, or I could use Tramp mode.
The other points could be done with a client-side application which talks to some server. Why put the whole experience in a browser?
Explaining the value of this is hard and I guess it boils down to the convenience of accessing everything via an URL. Of course everything you have in a browser may be done by applications talking to some server.
I'm basically hoping that an open-source cloud-based IDE will bring more to the table that just ssh x forwarding. What I've learned from a continuous integration server is that automation is important, but the test/build results are mostly separated from your IDE project -- integrating the two seems valuable.
Also, workspace configuration is a pain just as it is migrating to another machine. I'd rather just work as close to the (versioned) source code tree as possible.
It seems to me that having an offline IDE is odd when we are always connected, everything we produce goes back online (commit, emails) and we produce it usually by inspecting online resources (bugtracker, emails, google).
CodeMirror seems to be getting a lot of uptake, does pretty well handling the basics (highlighting, indenting, etc.), and has a pretty straightforward interface for adding support for new languages. Might be worth looking at.
I would say I'm offline often. I was interviewed by a company who's tech lead required everyone to program using VIM only on the server (production server). They didn't want any of the developers to have code on their machines for fear of them running off with it or something.
I won't even begin to enumerate the problems with that philosophy (developers editing code that was live and used the production DB - this was the biggest uh-oh) and other glaring issues of not trusting your programmers.
I promptly explained their silliness and walked out the door.
The most important feature of working-on-your-desktop, however, is to have mobility and isolation. I never let anyone edit code through SSH on the live server. If something is brokedd, even if it is something big, it can wait an hour to be fixed, peer tested, unit tested and pushed to the server. Plus WHY IN THE WORLD would you have your VCS history on the production machine!?!?! I don't get that about some of these cloud services that have you clone your source repository!
Laptop + Emacs + local db + Mercurial + rsync + Fabric is flexible and expressive in a way that anyone arguing for on-server only editing can't argue against.
I make a edit, hit refresh on the browser and verify it works as I expect it to then I simply type in "fabric deploy" and it asks me if I'm pushing to the staging server or to the production server. If I tell it I'm pushing to the production server it runs all of the unit tests for the project to make sure my edits didn't go f'up something else in the application I wasn't thinking about at the time. If the tests ALL pass it then rsyncs the files up with the server (using checksum not timestamp comparisons). If the tests fail, nothing happens.
[EDIT] Obviously I make batch edits - running unit tests for the whole project more than once a day would be ridiculous. But you get the idea.
It's the best process I've come up with so far and I've tried a lot of stuff. I've seen many horrors related to on-server editing.
What you've said about using staging and production servers and never pushing directly to the production server is valid.
Of course an online IDE doesn't mean editing code on the production server! You would still need to run a deploy towards the test/live server, run tests, etc.
It's not about throwing away the best practices or existing methodology, just about bringing the IDE more up to date with the online centric nature of coding.
I don't mean to be an ass I just think your time spent working on this tool could be invaluable working on some sort of shared-state mode for Emacs or VIM. I wouldn't go from Emacs to an online editor, no matter how good it is, because I don't have complete control over the software and where the code is being edited. That is important to me and many other developers...
The IDE will move from the desktop to the web, but that's a loooong way off. I recently installed Cloud9 ( http://cloud9ide.com/ and https://github.com/ajaxorg/cloud9 ) and it is by far the most advanced open source web IDE available. Supports multiple languages, syntax highlighting, error detection, etc.
However, as solid a start as it is ... it isn't anywhere close to being acceptable. No advanced editing features such a multiple line indenting, duplication, moving, etc. No code completion. No integrated manuals for languages. Limited shortcuts (since the most basic are mapped to the browser). I can go on, but you get the idea. We're still quite a few years off. All of it is possible, the tech is here, it would just take a massive undertaking ... and most of the resources are being poured into traditional IDEs.
>it would just take a massive undertaking ... and most of the resources are being poured into traditional IDEs
This is a big problem. As a mostly Java developer, the way I see it, none of the major three Java IDEs (Eclipse, NetBeans and IDEA) seem to move this way. Eclipse has announced Orion (http://mmilinkov.wordpress.com/2011/01/11/introducing-orion/ ) but that's very incipient and I don't think they are putting a lot of weight behind it.
Cloud9 seem to 'get' the idea and I do hope they shake things up a bit but although they release the code, I think they are basically a for-profit entity, so I would feel much more confortable if some open-source community/foundation would start building something like this.
I hope something like this takes off. I like eclipse but I never have the same installation between any two machines. Usually there is some kind of config bug that never gets sorted out and I just live with it. How different is this from what Heroku is doing in the RoR space?
Yikes. I agree but this looks like a workflow that would get in my way, not help me code. Open tab, wait 15 seconds while it launches. It just reminds me how much I despise java applets in web pages.
Ditto on the java-applet comments - I was shocked. Haha.
In all seriousness, though, people have mentioned this before but I don't think anyone's really tackled any underpinning reason why an IDE should be in "the cloud" (::cringe:: yea, I went there).
If I think about it in terms of features such a setup could provide - cohesiveness btwn. client & serverside testing, development statistics in real-time, and highly integrated documentation & comm. - then perhaps it's kind of sexy.
Seamless/buil-in pair-programming would seal the deal. It would be pretty awesome if it looked like Code Bubbles though...haha (http://www.youtube.com/watch?v=PsPX0nElJ0k)
This is taking on an immense amount of pain for what sounds like gain that can be had for far cheaper in every conceivable way with a much simpler and less boil-the-ocean approach. Whatever benefit you think this is going to bring when it's done, why not prototype that now?