11–20 of 30 posts
[1] https://kenneth.io/assets/images/posts/devtools-app/app-intr...
[2] http://www.google.com/design/spec/components/buttons.html#bu...
> 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'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.
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).
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.
That is the main pitfall of asynchronous programming as opposed to multithreaded programming.
Earlier 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.
Node's real draw, aside from pretty easy concurrency, is the package ecosystem.
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.
Earlier 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.
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...
