I am sorry, I had to write more detailed explanation of my above statements.
*Postel low (Robustness principle)* You can have a look at wikipedia article about it http://en.wikipedia.org/wiki/Robustness_principle. It contains explanation about why the robustness principle is harmful and contains a link to the corresponding RFC. About browsers. I am not much aware history of browsers wars, but I am aware about HTML parsers and what a shit they are and heard about how much efforts it took to make all that quirk stuff be a standard. Although browsers had a greater excuse for that than a pure machine protocols. Finally, I personally suffered from "robustness" even within my *private* tool chain :) *process.nextTick* * * Downsides of process.nextTick are 1) It is none-standard, not available in other environments and even can't be shimed (with promise of the same performance). 2) It has performance costs. Significant or not depends on your use case. 3) It disables some use cases. Example for 2 - 3 Let's say you have a some streaming app which receives something, transforms it and sends results further. TCP -> PARSER -> TRANSFORM -> SEND No surprise that PARSER often receives a chunk which contains many protocol objects. So, deferring them with nextTick is a performance overhead. And indeed, for example cursor.nextObject() of node-mongodb-native<https://github.com/mongodb/node-mongodb-native/blob/master/lib/mongodb/cursor.js#L678> calls it's callback synchronously exactly for the same reason. On other hand SEND also may decide to pack several protocol objects in one network packet. One possible and sometimes best way to do that is to consume what is available right now in the same tick, pack that and send. This is not possible when objects are deferred. About 1) and that it's none-standard I can add that when nextTick semantics were changed in 0.10.x and temporal max tick depth limitation were added many module authors were confused. They haven't discovered process.maxTickDepth setting and patched their code to use new setImmediate() function instead. Loosing performance of new process.nextTick and adding a junk to their code. Hope, now my claims look more sane and making sens. четверг, 22 августа 2013 г., 22:32:28 UTC+4 пользователь Scott González написал: > > On Thu, Aug 22, 2013 at 2:22 PM, Eldar <[email protected] <javascript:>>wrote: > >> > Be conservative in what you send, be liberal in what you accept. >> >> This is absolutely wrong! You should be conservative in what you accept >> and conservative >> in what you send otherwise you get huge troubles, shits and endless "it >> works here doesn't there" story. >> Browsers are good example. >> > > This is so misguided it's not even funny. There's a huge difference > between being liberal and having defined results for every input and the > bullshit that went on during the major browser wars. > > >people writing node modules should follow the node patterns and never mix >> sync and async behavior >> >> There is a certain edge between the case when you should follow common >> practices event if you don't like them >> and the case when you shouldn't, because they are so bad that cause a >> greater damage >> than confusing people from time to time. >> > > You realize that if you want to be conservative as an API developer, you > need to use nextTick(), right? There's absolutely zero change of danger or > confusing when forcing async callbacks. All of the danger and confusion > comes from sometimes-sync callbacks. > > >> For the case of nextTick I ignored it, because it's such a PITA. >> > > Sorry that writing one more line of code is so troublesome for you. > -- -- 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.
