You want to send all your code over the internet for processing every time you edit a line? This is (to a much lesser extent) how Salesforce's IDE works, and it's awful in my estimation. The only reason to do it is if (again, like Salesforce) you have a proprietary platform with an automated verification process that you don't want to reval to users.
Zaphar obviously didn't mean a web service. Look at the READMEs for the projects he mentioned to get a sense of the architecture: something that understands the language, be it a library, a daemon, what have you; and a binding of the editor to that thing, like a plugin.
Pitching a new IDE is asking a programmer to throw away years of experience in their editor of choice (mine, for better or worse, is Emacs) for some shiny feature.
Wasn't obvious to me :) In that case, I would generally agree, and I'm not sure why that isn't the standard model (since I can't think of many IDE frontend features that don't reduce to some pretty generalizable concepts, while I can think of lots of IDE backend features that are very unique to the language in question).
(I see above that people are arguing that this doesn't solve the issue of visual integration, but I don't see why separation of concerns in this way would make it harder to write a language-specific IDE--can anyone point to any examples?)
