On original topic: I truly believe that a good and clean software design paired with a small switch in the mindset, is more than enough to handle most of complexity in a node program. That's why a almost always advise to go pure js way, it forces you to actually learn how to do good software design and to think in evented/callbackdriven way. this is also valid in topics about code reusage, coffeescript etc. But i'm realist enough to not asume that everyone is enthusiastic to reach this standards. many of us, me sometimes including, just want to get the job done. or just have troubles to think different. nothing's wrong with that, there are tools to support this approach. this is where async, streamline, coffeescript etc. are valuable.
The problem with tools is always, that they add another level of complexity to grog. promises even worse, because they need another switch in the mindset, to follow a different paradigm. It's a good advice, to write you own control-flow lib. but not everyone has the time or ambitions to do it. and you don't have to. you just cant try to solve your current flow problem without libs and magic, just pure js, first. when it's done, then you could decide on the value of such libs for you. my advice on such questions will be allways: think about your code, your architecture first, think, how the decisions you made about it influence your problem. improve that first, it not only solves your flow problem, but probable improves other criteria for code quality, as testability, maintainability, coupling and reusability etc. If the design is good enough and the flow control is still a problem, then don't be shy on tooling. just know, that every tool you chose will have impact on your productivity in short and long range. I think a common and clean way to find and make decisions on a module, which refelects popularity is still a problem in node comunity, that is solved not good enough. npm search must provide more infos. download rates are good but only a beginning, dependency statistics and contributions frequency may be a good next step. then, it's easier for a node novice to decide on opinions posted here. at least regarding concrete modules. greet Am Samstag, 27. April 2013 22:15:20 UTC+2 schrieb Bruno Jouhier: > > Hi Isaac, > > Thanks for taking the time. It helps. Just replying to selected fragments > > Personally, I don't care how you write your JavaScript, whether you > >> use JSLint or Streamline or IcedCoffee or tea leaves or whisper the >> contents of your heart into the ear of a fairy who then sprinkles the >> JavaScript into the file with a liberal mix of extraneous comments, >> sourcemaps, semicolons, and pre-hoisted vars. Just don't make ME have >> to deal with that crap when I'm using your module. Publish >> JavaScript, not fairy whispers. >> > > I cannot resist but repost the secret recipe of streamline that I had > posted a long time ago on the streamline mailing list > > ... it really is black magic: > > The streamline compiler sends the code (asynchronously of course) to a > haitian vodou. > The vodou kills 3 animals at random, mixes their blood, drinks it, > spits 7 times on the code. > Then he dances in circles and invokes Papa Legba (guardian of the > callbacks) who whispers the result of the transformation to his left > ear. > And, as you would expect, the compiler gets the vodou's reply through > a callback. > > Hope this helps :-) > > >> Bruno, I appreciate that you're trying to be a good citizen etc. >> Towards that point, I think it would actually be much better if your >> "one liner" came along with a link to a longer post or something that >> very objectively explains what Streamline is, what it's good for, who >> it's (un)popular with, and what the drawbacks are. Ironically, >> perhaps, the shortness of the reply may be what causes some of the >> problems here. (Certainly, a long explanation of how great and >> perfect Streamline is for everything and how everyone uses it, would >> be inappropriate, but I see that you grok that already.) >> > > Well I had included the link to streamline's GitHub repo. > The README page gives a good overview of what it is. > > >> I can see that you both very much want to help new users be >> successful, and that is great. The fact that the debate is over HOW we >> should help newcomers most effectively is *awesome*. This question >> comes up often enough, and is enough of a source of disruptive >> disagreement, that maybe we three should just hash out a single wiki >> page or something that we can all be moderately happy with, and agree >> to send users there when they have this question. >> >> Does that sound like a reasonable idea? >> > > Why not? I think that the most important is to try to clarify the > different approaches: there are several library flavors (async, promises, > others), CPS transforms (streamline, IcedCoffeeScript, wind.js), coroutines > (fibers) and of course raw callbacks, and probably more to come (just saw > this today: http://koush.com/post/yield-await-v8). This is probably > difficult to grok for a newcomer. A technical explanation of the rationale > of each solution with factual pros and cons would be very helpful, much > more than psychodrama on the mailing list. > > Bruno > -- -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
