Taking Chrome DevTools outside the browser
kenneth.io
kenneth.io
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.
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]
1. https://wiki.mozilla.org/Sepsis
2. https://palant.de/2015/07/17/javascript-deobfuscator-reloade...
3. https://addons.mozilla.org/en-US/firefox/addon/sepsis-inspec...
4. http://www.wirfs-brock.com/allen/posts/228
5. https://gitlab.com/crussell/sepsis-inspector
6. http://www.colbyrussell.com/2013/08/06/patches-wanted.html
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."
But to go ahead and answer your disingenuous question anyway, no. That is not the idea.
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.
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.
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).
[1] https://code.google.com/p/chromium/issues/detail?id=129539
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.
See https://kenneth.io/blog/2015/07/02/concurrent-editing-and-re...
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.
1. http://vorlonjs.com 2. https://github.com/MicrosoftDX/Vorlonjs/
It would be nice if these dev tools interfaces were better modularized to make them more flexible and adaptable different environments.
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.
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.