
Taking Chrome DevTools outside the browser - aeontech
https://kenneth.io/blog/2014/12/28/taking-chrome-devtools-outside-the-browser/?repost=1
======
hirsin
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](https://github.com/Microsoft/IEDiagnosticsAdapter)

~~~
carussell
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]

1\. [https://wiki.mozilla.org/Sepsis](https://wiki.mozilla.org/Sepsis)

2\. [https://palant.de/2015/07/17/javascript-deobfuscator-
reloade...](https://palant.de/2015/07/17/javascript-deobfuscator-reloaded)

3\. [https://addons.mozilla.org/en-US/firefox/addon/sepsis-
inspec...](https://addons.mozilla.org/en-US/firefox/addon/sepsis-inspector/)

4\. [http://www.wirfs-brock.com/allen/posts/228](http://www.wirfs-
brock.com/allen/posts/228)

5\. [https://gitlab.com/crussell/sepsis-
inspector](https://gitlab.com/crussell/sepsis-inspector)

6\. [http://www.colbyrussell.com/2013/08/06/patches-
wanted.html](http://www.colbyrussell.com/2013/08/06/patches-wanted.html)

~~~
duncanawoods
Sepsis? That's a pretty off-putting name that I can't imagine will help you.
Any reason you named it after such a grim life-threatening condition?

~~~
carussell
Yes.

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."

~~~
davidy123
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?

~~~
carussell
This is the most presumptuous and mean-spirited comment I've ever received not
just on HN, but in my entire history of being online. No exaggeration.

But to go ahead and answer your disingenuous question anyway, no. That is not
the idea.

------
aidos
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](https://github.com/aidos/chromesync)

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

~~~
Nemcue
"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).

[1]
[https://code.google.com/p/chromium/issues/detail?id=129539](https://code.google.com/p/chromium/issues/detail?id=129539)

------
octref
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.

------
jimmcslim
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](http://vorlonjs.com) 2\.
[https://github.com/MicrosoftDX/Vorlonjs/](https://github.com/MicrosoftDX/Vorlonjs/)

------
bobajeff
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.

~~~
auchenberg
You can. Facebook has started the Stetho project, which essentially is a
protocol adaptor for Android.
[https://github.com/facebook/stetho](https://github.com/facebook/stetho)

~~~
bobajeff
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.

------
nevi-me
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?

~~~
matthewbauer
HTML editing is pretty good but editing Javascript for anything but the
simplest task is a dead end.

~~~
tracker1
Especially if you're doing any kind of transpiling (es6/7 features).

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

[https://www.youtube.com/watch?v=w6AvExQtvQ0](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/devmirror)

[https://github.com/ciju/gotunnel](https://github.com/ciju/gotunnel)

------
Aoyagi
I wish this was possible with Opera's Dragonfly.

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

~~~
joshstrange
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.

~~~
glandium
Note you can already do most of that with Firefox's Devtools:
[https://developer.mozilla.org/en/docs/Tools/Remote_Debugging](https://developer.mozilla.org/en/docs/Tools/Remote_Debugging)

~~~
josteink
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.

