(If you substitute the native dev tools in this thought experiment with Brackets or Sublime Web Inspector, you start to see the power of decoupling tooling from the browser.)
(If you substitute the native dev tools in this thought experiment with Brackets or Sublime Web Inspector, you start to see the power of decoupling tooling from the browser.)
Our RDP (Remote Debugging Protocol) is not interoperable with the one in Chrome or any other browser. There are two reasons:
1) Both us and Chrome team would like to iterate on our protocols and tools as fast as we can. Maybe in future, when tools across browsers stabilize there will be a case for a standard but I personally believe that a wrapper protocol is a better answer.
2) RDPs depend on their platform's architecture. Ours is very SpiderMonkey centric while Chrome's is all about V8.
Google organized a nice Summit during the I/O this year and I attended on behalf of our team (video: https://www.youtube.com/watch?v=SOO9Kb1-JJU). I shared my thoughts on interoperability and other issues here: https://medium.com/web-developer-tools/1060a9f69e6a
Hope that helps.
The Google Web Toolkit team was looking at this; instead of their historical approach of using a JVM to run/debug user code (because that was actually a really great idea in IE6), using the native JS debuggers in FF/Chrome/etc.
...except that there is all sorts of wonkiness, like only 1 debugger is supported at a time, so you can't use, say, Eclipse (whether for GWT or pure JS debugging) + FF dev tools for inspecting CSS/etc. at the same time. And you can only connect to 1 tab...something, something. I was not directly involved, but it didn't sound pleasant.
Anyway, I totally agree that native dev tools should be decoupled/play friendly with other tools.
AFAICT, so far the FF/Chrome engineers are going down the path of basically building IDEs from scratch, in the browser itself.
Which was great for Firebug, and inspecting elements, but for a debugger, I really want to stay in my IDE.