Hacker News Reader

Comment by hirsin | Hacker News Reader

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

View on HN

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]

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

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?

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

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?

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.

Reply on news.ycombinator.com