9 ms·

Taking Chrome DevTools outside the browser

77 points by aeontech 11y ago

nevi-me 11y ago
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 11y ago
  HTML editing is pretty good but editing Javascript for anything but the simplest task is a dead end.
  - tracker1 11y ago
    Especially if you're doing any kind of transpiling (es6/7 features).
- deleted 11y ago
  [deleted]
Aoyagi 11y ago
I wish this was possible with Opera's Dragonfly.
curiousjorge 11y ago
or just click the gear and popup the devtool in its own window.
- joshstrange 11y ago
  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 11y ago
    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 11y ago
      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.
hirsin 11y ago
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 11y ago
  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-reloaded https://palant.de/2015/07/17/javascript-deobfuscator-reloade... 3. https://addons.mozilla.org/en-US/firefox/addon/sepsis-inspector/ https://addons.mozilla.org/en-US/firefox/addon/sepsis-inspec... 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
aidos 11y ago
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 11y ago
  "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
- auchenberg 11y ago
  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. See https://kenneth.io/blog/2015/07/02/concurrent-editing-and-real-time-visual-comparison-between-browsers-in-chrome-devtools-with-remotedebug-gateway/ https://kenneth.io/blog/2015/07/02/concurrent-editing-and-re...
jimmcslim 11y ago
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 11y ago
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 11y ago
  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 11y ago
    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.
- deleted 11y ago
  [deleted]
ciju 11y ago
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
octref 11y ago
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.

77 points by aeontech 11y ago

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 11y ago
HTML editing is pretty good but editing Javascript for anything but the simplest task is a dead end.
- tracker1 11y ago
  Especially if you're doing any kind of transpiling (es6/7 features).
deleted 11y ago
[deleted]

Aoyagi 11y ago

I wish this was possible with Opera's Dragonfly.

curiousjorge 11y ago

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

joshstrange 11y ago
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 11y ago
  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 11y ago
    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.

hirsin 11y ago

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 11y ago
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-reloaded https://palant.de/2015/07/17/javascript-deobfuscator-reloade... 3. https://addons.mozilla.org/en-US/firefox/addon/sepsis-inspector/ https://addons.mozilla.org/en-US/firefox/addon/sepsis-inspec... 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

aidos 11y ago

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 11y ago
"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
auchenberg 11y ago
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. See https://kenneth.io/blog/2015/07/02/concurrent-editing-and-real-time-visual-comparison-between-browsers-in-chrome-devtools-with-remotedebug-gateway/ https://kenneth.io/blog/2015/07/02/concurrent-editing-and-re...

jimmcslim 11y ago

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 11y ago

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 11y ago
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 11y ago
  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.
deleted 11y ago
[deleted]

ciju 11y ago

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

octref 11y ago

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.