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.
I completely agree. There's still a long way until we have a common API that caters for all use-cases across tools and runtimes, but uniting around the same protocol is the first tiny step towards this vision of better decoupled tooling.
Luckily the Chrome Remote Debugging protocols is quite flexible, so we could start iterating on the API's too using some sort of vendor prefixing, if needed.
I started a project[1] a while back when it became clear that the underlying architecture for the new devtools in Firefox was going to be as problematic as Firebug's had been. Longtime Mozilla contributor Wladimir Palant just published a post a few days ago touching on some of the problems with devtools that he ran into when trying to work with it.[2]
The idea with sepsis-inspector is that it should be able to replace Hewitt's old DOM Inspector codebase and be stupid simple to extend with third-party viewers. (For anyone unfamiliar, DOMi has the ability to inspect not just webpages, but e.g. the Firefox UI [and Thunderbird, and SeaMonkey] and extensions as well.)
The interface between the Inspector itself and the viewers is nice and modular for the most part. It's basically Unix pipes in GUI form, with a few services for sugaring. Altogether, this makes its design a good foundation for a generalized inspector framework. (And I do mean generalized. Let's debug PNGs, PDFs, and Haxe, too, but I'm not even talking just the Web here. Want to use it to debug Gnome Shell or your Mono app? Sure. I mean, why shouldn't we be able to?)
Since DOM Inspector, Firebug, and the new Firefox devtools exist, I've focused most of my time on getting the architecture right and then teaching the Inspector how to do some things that those tools can't already do, rather than necessarily shooting for parity from the start. This means that if you download the sepsis-inspector add-on[3] right now, you'll find that it's missing some things that existing tools can do, but at this point, it's just a matter of layering those features on. There's still work to be done underneath, though.
The sepsis-inspector's dependency on XUL needs to go away, for example.
Allen Wirfs-Brock did some research on JS mirrors[4] a few years ago, although nothing seems to have come of it, AFAICS. Everyone decided to roll their own debugging/reflection APIs, I guess. But it's blindingly obvious to me that something based on mirrors is what needs to be powering our inspectors, and that your chosen inspector should be able to do a lot more tricks than what the current crop of web inspectors can do (including, as I said before, doing more than just debugging CSS, JS, and the DOM).
If anyone is interested in collaborating here, you'll find that, for the most part, the sepsis-inspector code is extremely well commented for a Mozilla add-on. Patches wanted.[5][6]
It's a project codename, not a serious attempt at coming up with a name fit for mass consumption. It's not supposed to help with anything but one thing: to be able to unambiguously refer to the project even in the pre-release phase.
Using "sepsis" follows the policy that project codenames shall be patterned after unappealing medical phenomena (e.g., staph, polyp, varicose, etc). There are two reasons for this:
These kinds of ugly names are unusable from a marketing standpoint, so there’s a vanishingly small chance of collision with anything else.
They’re also a constant reminder of the fact that the codename is just a codename; it totally eliminates the risk of anyone ever looking at it during the actual research and naming phase and lazily suggesting, "Hey, let’s just go with that."
So if someone knows someone who's affected by one of your life threatening conditions, they can just stay out of the project. It's all about the macho core contributors. Who overthink things (is collision really such a problem? is "marketing" really that likely to run with some random name, and why is that a problem?) and continue to make obscure projects without diverse participants. Is that also part of the logic?
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.
"I really wish the Chrome remote debugger allowed multiple websocket connections."
You, me, and a ton of other people. It's the number 1 starred Dev-Tools issue[1], and has been for years now. I'm guessing it's a political issue since there has been no indication whatsoever towards providing a solution.
It really is a big deal; there's a ton of potential applications if we could plug multiple things into a single page.
I think spy.js only scratches the surface of what's possible in this space; and spy.js is pretty awesome (if only it wasn't dreadfully slow and tied to an IDE).
Agreed. This is much needed for enabling other tools to be built in the RemoteDebug-ecosystem.
I've recently started exploring what I could mean to have concurrent connections to browsers, and what kind of tools we could build. Realtime visual comparison is really exciting.
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].
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.
No I'm not talking about debugging android apps. I'm talking about debugging websites using a android device. Again I'm not taking about remote debugging.
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?
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.
You're missing the point. This is about pulling out devtools so that it can be used with more than just chrome and provide a single way to debug everything from FF/Chrome/Safari to NodeJS apps and iPhone native apps.
That may be, but as you read the article, you do get re-inforced the idea that WebKit (and by proxy Chrome DevTools) are infinitely more embeddable and mallable: All examples listed of non-standard usage are WebKit and Chrome. Not a single Firefox or Mozilla component in sight.
Is there a (still) technical reason for this, or is it just that WebKit & Chrome won the developer mindshare to the point where there's point in investing elsewhere if you want to get picked up?
If so, that would have me worried. You may argue it's "only" on the developer-side, but that's always where things start out before they spread out.
We are already very close to a Chrome monoculture taking hold, and I find websites and services on a daily basis which doesn't work in Firefox (or Firefox mobile) which I have to open in Chrome in order to have loading correctly.
I think we're already at the point Microsoft was with IE, if not well beyond.
As someone who cares about the open web, open data and a proper standards-based internet, I think pretty much everything is heading in the wrong direction these days.
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