On Apr 16, 2012, at 10:24 AM, billywhizz wrote: > Axel, while nobody has explicitly stated that streamline.js is for everyone > it seems that every time someone asks a question about control flow and > nesting a streamline fanatic jumps on the thread and puts it forward as the > solution to everything. Maybe you guys just don't realise how bloody annoying > that is and how much confusion it must lead to for new users. the biggest > problem the "haters" have with the library is it works completely against the > rationale for node.js. i don't know how many times it has been stated by the > node.js team that node.js is all about async and callbacks and is > fundamentally tied to the way javascript does things. however much you might > like streamline.js it will always remain something of an experiment and a > hack. while it is an impressive feat of mental gymnastics i'm afraid i > couldn't call it a brilliant piece of engineering as it's going too much > against the grain of the platform it is built on and is massively over > complicated. > > my suggestion for the node.js community would be just to ignore any future > comments like this as these thread-wars only draw disproportionate attention > to what will always be a niche product. would be much better to let it die a > quiet lonely death in the corner. this is the last time i will be commenting > on it as i'm really really tired of hearing all this FUD.
@billywhizz: when someone complains "I love async, but I can't code like this" (and it happens quite often) streamLine is a valid proposition (whether you like it or not): > On Jul 12, 2011, at 12:57 AM, Bruno Jouhier wrote: >> >> The goal of streamline is precisely to "introduce as few new concepts >> as possible". My observation was that Javascript got somehow "broken" >> in node: the native flow control constructs of the language are not >> powerful enough to tame asynchronous code flows. So, as the language >> is too weak, people end up using flow control libraries, or doing low >> level wiring with callbacks. >> >> So, instead of inventing new abstractions, I just tried to "restore >> the power of the existing language keywords": I wanted if/else to >> behave like if/else, even if there was an async call in the if branch, >> or one in the else branch, or if the condition itself was asychronous. >> And not just if/else, but also while, for loops, and why not try/catch/ >> finally. I wasn't sure that I would be able to handle all the >> constructs when I started this but I found out is this was not so >> difficult and that it could be done with an algebraic, pattern-based, >> transformation (that I have later described in a blog post). >> >> Why introduce new abstractions if you can just fix what got broken? >> >> Bruno -- Jorge. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
