The older teams working on code in Ruby or Java will take a bit longer. The network latency may be the biggest hassle for them. When I tried to work through a build-debug-fix cycle, I spent too much time wishing for that old behemoth Eclipse and key clicks didn't take a roundtrip on the Internet.
The myriad complaints aren't inescapable road blocks that indicate long-term limits for the tools. The browser code will get smarter, and the foundation for local files, local data, and larger libraries is already baked into HTML5-compatible browsers. The creators of these tools will be moving more and more intelligence to the client, which will eliminate many of the headaches associated with waiting for the events to make a roundtrip on the Internet. This will happen rapidly. In a few years, not many desktop IDEs may be left.
JSFiddle is the latest in a long line of emerging Web tools. Many big Web properties, for instance, offer "sandboxes" for playing with their API directly in a Web page. I've debugged Google Maps code several times in a window that Google built for experimenting with it. The browser's included debugger is all that's necessary.
Some developers will see JSFiddle as a tool for experimentation and toys because there's little available for working on the server side of the app. The code can easily call APIs, but you won't build any APIs with it. That would be missing the point. The developers clearly want to encourage more snippets and code that can form the building blocks for Web pages.
Sign up for Computerworld eNewsletters.