
Chrome DevTools outside of the browser - gidea
https://kenneth.io/blog/2014/12/28/taking-chrome-devtools-outside-the-browser/
======
Honzo
This is really neat.

FYI to run Chrome in remote debugging mode on a Mac

    
    
      > /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

------
esamek
From the authors philosophical standpoint, I think this is indeed very
interesting. I hate having to open up multiple instances of the dev tools
since they are tied to the tab instance.

------
chippy
How does this differ from the default Chrome DevTools remote debugging over
the wire? Doesn't that also run it's own http server in a way?

[https://developer.chrome.com/devtools/docs/debugger-
protocol...](https://developer.chrome.com/devtools/docs/debugger-
protocol#remote)

~~~
jaimeyap
This is almost certainly using the same protocol.

The DevTools team did the work a while back to pull everything they needed out
of process and establish the devtools protocol to enable remote debugging.

What the author has done is to take the Chrome DevTools (which is already
basically a standalone web app), and package it up with Node-webkit as a
standalone app.

I think this is cool, not from a technical perspective necessarily (since the
engineering work was mostly already done by the DevTools team for remote
debugging), but rather from a usability perspective. Slight tweak to the UX
and it changes the mental framing people have of what the chrome DevTools
actually is.

------
ercu
my 2cents for just for the ui [1]: using more than one floating action
(rounded) button more than once is against material design guidelines [2].

[1] [https://kenneth.io/assets/images/posts/devtools-app/app-
intr...](https://kenneth.io/assets/images/posts/devtools-app/app-
intro-963ce2ecf1e84a4a6e936fdeacfbdca1.png)

[2]
[http://www.google.com/design/spec/components/buttons.html#bu...](http://www.google.com/design/spec/components/buttons.html#buttons-
floating-action-button)

~~~
auchenberg
You are absolutely right. Do you have a suggestion for how to make it better?
I'm not a designer :)

------
xasos
This looks super interesting, and I'm definitely going to try it out when I'm
back at home.

GitHub repo if anyone is interested (with install instructions):
[https://github.com/auchenberg/chrome-devtools-
app](https://github.com/auchenberg/chrome-devtools-app)

------
mattdesl
Great post!

I'm also really curious about the future of Dev Tools and hope to see it
applied to other uses. I think there is a range of tools we could be building
on top of or around Chromium/DevTools/etc to provide real-time workflows for
animations, visual programming, shader authoring, WebAudio editing, and plenty
more.

I wrote about it a bit here: [http://mattdesl.svbtle.com/motion-
graphics](http://mattdesl.svbtle.com/motion-graphics)

You might also want to check out Thrust and atom-shell as alternatives to
node-webkit.

------
stephen
Any post/tool that mentions "cross-browser debugging protocols" has my
immediate +1.

Doing so from outside the browser (which gets me that much closer to staying
in my IDE) has my immediate +100.

I understand the fancy side of debugging tools is still being actively evolved
(interacting with/highlighting DOM elements), but surely we're to the point
where a basic JS debugger protocol (break point, skip, go in, go out, etc.,
...with source maps...) is doable.

~~~
msiebuhr
Kenneth is the guy behind [http://remotedebug.org/](http://remotedebug.org/),
so cross-browser is definitely in-scope.

------
mysteriouswasp
Cool hack, but couldn't you just enable remote debugging in chrome then use
the devtools built into node webkit?

~~~
auchenberg
You could, but my point here is to explore what it brings to the table when
DevTools is a separate application, just like your editor.

------
thomasfoster96
Does this run on Windows? Looking at the GitHub repo it seems to me it's very
much Mac-only (which is surprising seeing as it's made in node-webkit).

~~~
auchenberg
We could enable node-webkit to generate a windows build too. Are you
interesting in helping out?

------
kevnguy
> Chrome DevTools is close to a functional editor.

Yes, we need this badly! Can't wait to see what we can do with the devtools
and make something similar to Brackets!

~~~
androidreview
I'll want to see how they can expand this to debug other browsers especially
mobile IE, oh god!

~~~
thejosh
Have you tried weinre?

------
mijoharas
This seems like a really interesting idea, since I'm not by a computer right
now, has anyone played around with it yet? How does it seem?

------
amelius
How scalable is Node these days, considering that javascript has no real
multi-threading support, and most of the things you do for a user in Node are
thus blocking other users?

I know it is possible to run things in different processes, but it seems to me
that this is kind of a hassle (like a workaround).

~~~
boucher
Most of the things you do for a user are not blocking, that's the whole point
of node. Instead of blocking, almost everything is done with asynchronous
callbacks.

~~~
amelius
And while you are servicing a nonblocking request, you are effectively
blocking other users, because the CPU can do one thing at a time.

That is the main pitfall of asynchronous programming as opposed to
multithreaded programming.

~~~
jkrems
You are not blocking other users - the CPU is busy and couldn't do other stuff
even if it tried. With using one process per core (plus a spare core for
"other stuff") you get full CPU utilization. You are right that node is not
the right tool for doing large CPU-bound tasks as part of HTTP request
handling. If that was your point: yes, that's true and that won't change. But
if most of what you're doing is forking out to other services and some light
assembly (JS is a scripting language after all), then node is a very nice fit.

~~~
amelius
But what if your tasks need to talk to other systems, that may use mutexes to
control concurrent access. In that case, your HTTP request handling logic will
just block on those mutexes, and all is lost, since the event loop will be
stuck.

Now, you could of course rewrite those 3rd-party systems to use your event-
loop instead of plain mutexes, but the point is that threads are a more
natural fit for multiprocessing, from a software-engineering point of view,
because they allow one to compose systems more easily.

In other words, threads have been invented for a reason. Otherwise, we might
as well just go back to the Windows 3.11 era, with its cooperative
multitasking model.

~~~
tracker1
Your calls to third party systems should be through a callback interface..
they should not be blocking inline. The event loop will continue.

There are plenty of ways you can process out of band requests... you could use
a generic-pool with a size of one instance if you _really_ need to... However,
if you are really blocking access to a single client at a time, it's likely
node won't be your bottleneck.

