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?)
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.