I quite like the idea of separating browsers and their dev tools. Beyond the immediate benefits of familiarity for the developer, a standard discovery/communication protocol helps reinforce both standards compliance and good documentation processes.

As it stands, there is no standard for dev tool communication. V1.1 of Chrome Debug protocol, which we used to teach IE to speak to Chrome dev tools [1], is a good start though. However, with the deeper (ie profiling) features of browser dev tools, you tend to find a lot of "blit a chunk of memory to the dev tools", which would almost never end up being standards compliant. So there's still some internal work to be done before Kenneth's dream of truly interoperable dev tools can become reality.

1. https://github.com/Microsoft/IEDiagnosticsAdapter

I really wish the Chrome remote debugger allowed multiple websocket connections.

A while back I made chromesync [0] to automatically push changes to your local files directly in to Chrome. It means you can work in your own editor (whichever it is) as normal and have your js updated on the fly. For me, it's a great way to develop SPAs.

Unfortunately, all too often you need to inspect something in the Chrome dev tools - which causes issues because you can only have one debugger connected.

Someone created a proxy to handle multiple connections [1] but it requires running the Dev Tools in a separate tab via the proxy too. You can make it all work but it's a lot of moving pieces.

[0] https://github.com/aidos/chromesync

[1] https://www.npmjs.com/package/ws-multi-proxy

I know this is not closely related to the post, but this really got me worried:

and I was quite surprised how little “desktop” focus there is in the spec. It’s like the design team simply have forgotten that we have this thing called a “desktop” computers, where we use these oldschool interactions called mouse and keyboard.

I have similar experience, recently just starting to learn Mac development. The getting started guide for creating Mac desktop app is 3 years old and using XCode 4, whereas the iOS guide is updated and polished.

And I had a mixed experience with my Chromebook. It is great for web-browsing, but most of the apps available are designed primarily for mobile devices and feel weird to use. The "desktop" version of them usually just involves opening a tab in Chrome or in an resized individual window. I don't know if the developers are too lazy to design for desktop, or they are clueless to how they should do it.

It's also work taking a look at Vorlon.js [1]; a Microsoft-backed 'open source, extensible, platform-agnostic tool for remotely debugging and testing your JavaScript. Powered by node.js and socket.io.' MIT licensed, and code available on GitHub [2].

1. http://vorlonjs.com 2. https://github.com/MicrosoftDX/Vorlonjs/

I have on occasion wanted to use browser dev tools on Android itself (not remote debugging) and additionally have wanted to run them in a command line interface (for running in ssh from a build/testing server)

It would be nice if these dev tools interfaces were better modularized to make them more flexible and adaptable different environments.

I agree on DevTools being quite close to an editor. I recently started editing my CSS files directly inside DevTools, I wish I would have started doing that months ago, it's saved me from many page refreshes. I wonder what else I can do with it?

Closing the loop, with tunnelling and a mirror of the client dom.

https://www.youtube.com/watch?v=w6AvExQtvQ0

Had wrote a tunnelling server in Go, to achieve this. Even had a client site go binary which would download the chrome binary, and open a new user profile, setup inspector and generate a tunnelling url. The parts of DOM mirroring were mostly copied from different blog posts etc, on the web.

https://github.com/ciju/devmirror

https://github.com/ciju/gotunnel

I wish this was possible with Opera's Dragonfly.

or just click the gear and popup the devtool in its own window.