[deleted]
Chrome DevTools outside of the browser
21–30 of 30 posts
Re: Chrome DevTools outside of the browser
#22> 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!
I'll want to see how they can expand this to debug other browsers especially mobile IE, oh god!
Have you tried weinre?
Re: Chrome DevTools outside of the browser
#23Earlier quoted context omitted.
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.
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.
The CPU can only do one thing at a time even with threads. It just hides that fact from you better.
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.
Re: Chrome DevTools outside of the browser
#24Any 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,…
Kenneth is the guy behind http://remotedebug.org/, so cross-browser is definitely in-scope.
Re: Chrome DevTools outside of the browser
#25Earlier quoted context omitted.
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.
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…
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.
Re: Chrome DevTools outside of the browser
#26Earlier quoted context omitted.
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…
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, f…
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.
Re: Chrome DevTools outside of the browser
#27Earlier quoted context omitted.
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.
In thread-per-connection server applications, the concurrency is exactly the number of threads spun up for the pool of connections. In node, it achieves that concurrency without a thread pool for the connections themselves, and thus you get less resource usage (memory mostly) for the same number of connections as the daemon scales up. Node's real draw, aside from pretty easy concurrency, is the package ecosystem.
Not to mention the overhead of switching threads... Moving context in and out of secondary memory (RAM, disk) is pretty big. And when you get to thousands of threads per core, the context switching becomes very costly.
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.
Re: Chrome DevTools outside of the browser
#28my 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... [2] http://www.google.com/design/spec/components/buttons.html#bu...
You are absolutely right. Do you have a suggestion for how to make it better? I'm not a designer :)
Re: Chrome DevTools outside of the browser
#29Does 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).
We could enable node-webkit to generate a windows build too. Are you interesting in helping out?
Re: Chrome DevTools outside of the browser
#30Cool hack, but couldn't you just enable remote debugging in chrome then use the devtools built into node webkit?
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.