@Bruno Thanks. I appreciate the example. That sounds like a good demo touching the key features. Also, your delineation of lib vs app code I think is a good one, but for now I'll be happy just to have the former. Certainly of course the goal of this is for individuals motivated by their library of choice (or authorship) to implement these solutions themselves, so a well defined set of expectations would probably go far in soliciting contributions.
@Mikeal I agree completely with the spirit of your comment, but promises are by definition compatible with the node ecosystem via the many wrapping APIs, etc... which is of course a primary reasons for their perceived benefit, not having to deal with callbacks. My desire is to have a crowd-sourced canonical source for these sorts of comparisons similar to an idiomatic.js to better inform teams making decisions on whether tradeoffs rather then be swayed by the prevailing noise. FWIW, I personally don't know anyone that enjoys JavaScript as a language and has been programing in node.js for longer than 6 months that prefers promises. From what I can tell, most of the pro-promise zeitgeist originates from client-side implementations like jQuery's deferreds. Cheers, Adam Crabtree On Mon, Apr 1, 2013 at 2:44 AM, Bruno Jouhier <[email protected]> wrote: > We would probably need two examples then: > > * An "application" example to compare how the tools let you write a simple > yet non trivial application on top of existing libraries. > * A "library" example to test compatibility with the rest of the ecosystem. > > The streamline tutorial falls in the first category. It tests the ability > of the tool to deal with 3 types of common operations (web service calls, > fs calls, database calls) and it tackles common problems that every > application developer will face (exception handling, parallelization). > > For the second category, what about a basic SMTP client? Something that > would handle the low level dialog described in > http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#SMTP_transport_exampleand > would expose a simple API to send messages. Of course the API should be > aligned on node's standards and the example would also include a piece of > "standard" node code that exercises the API. > > > On Monday, April 1, 2013 2:26:51 AM UTC+2, Mikeal Rogers wrote: >> >> How do you express compatibility with the majority of the node.js >> ecosystem as a code sample? >> >> -- > -- > 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 > > --- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Better a little with righteousness than much gain with injustice. Proverbs 16:8 -- -- 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 --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
