I've been on the receiving end of this complexity explosion
Count me in. Been there with Twisted and (partly) EventMachine.
Imho node should really abstract this away before the eco-system turns into a giant spaghetti ball. Of course you can't bend javascript into a concurrency model as elegant as erlang's. But co-routines or a similar abstraction is urgently needed at least for the code that the users end up writing.
On a related note; I recently switched to coffeescript in an effort to bring my (still small) node codebase back into a half-way readable state.
The simple act of removing most curly brackets had an astonishing impact on readability. I still have to reason about callback chains, but at least I no more have to wade through half screens full of closing brackets while doings so.
That observation was a bitter-sweet reminder of what I'm (willfully) getting myself into with node - all the while keeping my fingers crossed that this wart on an otherwise beautiful environment will be improved asap.
A long time ago I convinced or at least started the ball rolling on getting coroutines added to node.js. Now when they finally were added, it was done in what I would call a very wrong fashion. Coroutines could have events pushed to them without being yielded to (there needs to be a guard). Of course the reentry issue is just as bad as the one being solved so I think it was written off as a horrible idea and never returned to.
Of course, it didn't have to be that way if they had proper event triggering semantics. I find very little hope of the community returning to this issue though. Not that it's the only way to solve things... but it would have been a nice balance IMO. (and I still hold that coroutines can be done cheaply... at least as cheaply as event sources if not more)
(Update: to clarify on proper coroutines on node, each needs to be able to iterate on an independent tick loop rather than allow preemption from EventEmitter#emit)
Comments
I've been on the receiving end of this complexity explosion
Count me in. Been there with Twisted and (partly) EventMachine.
Imho node should really abstract this away before the eco-system turns into a giant spaghetti ball. Of course you can't bend javascript into a concurrency model as elegant as erlang's. But co-routines or a similar abstraction is urgently needed at least for the code that the users end up writing.
On a related note; I recently switched to coffeescript in an effort to bring my (still small) node codebase back into a half-way readable state.
The simple act of removing most curly brackets had an astonishing impact on readability. I still have to reason about callback chains, but at least I no more have to wade through half screens full of closing brackets while doings so.
That observation was a bitter-sweet reminder of what I'm (willfully) getting myself into with node - all the while keeping my fingers crossed that this wart on an otherwise beautiful environment will be improved asap.
A long time ago I convinced or at least started the ball rolling on getting coroutines added to node.js. Now when they finally were added, it was done in what I would call a very wrong fashion. Coroutines could have events pushed to them without being yielded to (there needs to be a guard). Of course the reentry issue is just as bad as the one being solved so I think it was written off as a horrible idea and never returned to.
Of course, it didn't have to be that way if they had proper event triggering semantics. I find very little hope of the community returning to this issue though. Not that it's the only way to solve things... but it would have been a nice balance IMO. (and I still hold that coroutines can be done cheaply... at least as cheaply as event sources if not more)
(Update: to clarify on proper coroutines on node, each needs to be able to iterate on an independent tick loop rather than allow preemption from EventEmitter#emit)