FYI to run Chrome in remote debugging mode on a Mac
> /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
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.
GitHub repo if anyone is interested (with install instructions): https://github.com/auchenberg/chrome-devtools-app
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
You might also want to check out Thrust and atom-shell as alternatives to node-webkit.
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.
Yes, we need this badly! Can't wait to see what we can do with the devtools and make something similar to Brackets!
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).
That is the main pitfall of asynchronous programming as opposed to multithreaded programming.
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.
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.
In an app that grabs a page from a database and returns it, the node.js app will receive a request from a user, make a request to the database, receive a request from another user, make a request to the database, then wait for either database request to return, then return it to the user, then when the other returns, return that to the user.
Your program doesn't deal with one whole request at a time, it chops it up into lots of little "wait for this event" parts and node.js has an event loop that listens for events, which can happen in an arbitrary order. So you can be waiting for hundreds of events to happen for hundreds of requests, and as node.js doesn't make you wait for the first one to process the second, nobody's holding up anyone else.
Threading does nearly exactly this automatically... except that you need memory per thread in order to maintain the illusion that each thread has complete control over the CPU (its own stack, etc), and it can also split up CPU-bound workloads automatically. node.js needs much less memory per event it's waiting for.
Node's real draw, aside from pretty easy concurrency, is the package ecosystem.
Some modern systems use thread pools, and manage state switching internally to avoid this overhead at the CPU layer... just the same it is costly.
I worked on a simulator a few years ago that was being written in many threads (each virtual character in play would have its' own worker thread)... this lead to a much lower number of users/system than should have been needed... switching to an event-loop and message bus reduced the overhead significantly.