Gregor Elke

look at the comments to the stackoverflow answer and think again if it's a good solution: http://stackoverflow.com/questions/244777/can-i-comment-a-json-file/18018493#18018493

functions statement vs. functions expression, you should at least mentioned this to terms, because they act differently in regard of hoisting read here http://kangax.github.io/nfe/

and arrays are more similar to Java Lists than to Arrays, but it's a minor detail, since js arrays are just objects, that have methods for special treatment of properties with numeric keys and the length property ;)

@paprikkastudio IE8 is a different beast. i'm all for snippeting too. <3 sublime for it

@paprikkastudio a TypeError? interesting... in node, and ff it works as expected, in chrome and safari there is a typeerror. i think it's when not a bug, then at least bad implementation. but hey! try that:

var f = console.log.bind(console)

;)

PS: of course this version is nearly the same as the opening tip :D

ever tried:
var d = console.log ?

The main, origin, goal of node was and is to fast develop specialized webservers, that are able to do amazingly many concurrent connections. it happened, that the concept to solve this problem is also a good one to solve many other problems. but never all. No serious node.js developer would promote node as solution for all problems.

JS is NOT async. you can write pretty much sync code in js. In Browser, there are 2 main API's that are async, the DOM Events and AJAX. DOM is built to be a UI Framework, thats why. Node.js is built to solve I/O-heavy problems on a server, thats why it is async too.

Writing multi-threaded sync-code that works well is hard. Firstly, sync code tend to use shared memory in combination with locking mechanism, that leads to unpredictable behavior. You can overcome it with proper frameworks. same is valid for async style. you don't like it? there are tools to help you flatten and prettify your code, if you can manage it yourself in the first place. Want to process 3k DB rows? Use Streams, not nextTick, not webworker or else. 3k DB-rows are I/O-heavy tasks. Why the heck are loading all 3k rows in to memory anyway? to avoid i/o and it's blocking nature?

if you really find yourself want to spinning many threads, may be your application is really CPU-eater, then go and use another platform, it's fine.

yeah, typical webapps are seldom suffering from typical concurrency problem. but yeah, typical webapps are seldom use much cpu, cause most of them are i/o-heavy, db access, file reading, access of other web services etc. oh yeah, they access even computing web-services written on better fitting platforms for computing things. instead of spinning more and more threads, and eating up memory resources, a single-threaded eventlooper handles all the i/o gracefully.

"I say let async do what it does well (parallel IO), and let threads do what they do well (schedule CPU)."

no one really doubt that. you COULD do app logic async, with practice it's not hard. you also COULD (and it is done widely) I/O with threads and sync code, with practice it's not hard.

there is no lie about node. Node is and was always a platform to do network-heavy stuff. and it does it pretty good. In node is nothing mashed together. It's users like you and me, who mash up things, that belong to separate layers. It's very specific to your application. if CPU become a bottleneck, change your system architecture, there are at least threading libs (with message passing btw.) for node. or move your app-logic to another platform.

People are willing to open up their minds to the idea that the future of concurrent web programming has many possibilities. That's why Node.js exists

@paprikkastudio even sweeter without underscore:

item.doSomeStuff() for item in items

@maciejsmolinski this looks amazing at the first sight, thanks for the pointer

even faster with http://balderdashy.github.io/sails/