10 ms·
Node.js Guide
- swannodette 16y agoUgh, don't agree at all with the dismissal of Object.freeze. This introduces immutable values to JS which is great for many kinds of data as well probably opening the door for more optimizations by V8.
- mraleph 16y agoCurrently doing Object.freeze closes the door for optimizations: object goes into so called slow mode. See http://jsperf.com/object-freeze http://jsperf.com/object-freeze results.
- swannodette 16y agohttp://jsperf.com/object-freeze/3 http://jsperf.com/object-freeze/3 http://jsperf.com/object-freeze/5 http://jsperf.com/object-freeze/5 http://jsperf.com/object-freeze/6 http://jsperf.com/object-freeze/6 A reminder on how immutable objects are meant to be used. When used properly even under attempts to mutate, they run circles around trying to use mutable objects in an immutable manner.
- mraleph 16y agoYeah, I did something stupid in my own test. Probably I was thinking about Object.seal(). Nevertheless your own test revision #3 shows that accesses to frozen properties are roughly 14 times slower. Revisions #5 and #6 do an allocation in the "hot" testcase so the real cost of property lookup just becomes hidden behind cost of memory management.
- davej 16y agoI was afraid to read the style guide for fear of seeing the preceding comma pattern (I think it's popular in Node because ryah uses it). Thankfully it recommends the trailing comma :) var variable, // trailing comma anotherVariable, thirdVariable; var variable , anotherVariable // preceding comma , thirdVariable;
- DTrejo 16y agoHere's an article about why preceding comma is very convenient: http://ajaxian.com/archives/is-there-something-to-the-crazy-comma-first-style?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ajaxian+%28Ajaxian+Blog%29 http://ajaxian.com/archives/is-there-something-to-the-crazy-... More specifically, in which is it easier for you to find the error? // error in standard style var a = "ape", b = "bat", c = "cat", d = "dog" e = "elf", f = "fly", g = "gnu", h = "hat", i = "ibu"; // error in comma-first style var a = "ape" , b = "bat" , c = "cat" , d = "dog" e = "elf" , f = "fly" , g = "gnu" , h = "hat" , i = "ibu" ;
- davej 16y agoYeah, I understand why, particularly when old IE browsers don't allow a comma trailing the final declaration. I just find it ugly as hell.
- jsankey 16y agoUnfortunately trailing commas still break IE7, which I wouldn't yet classify as old enough to ignore.
- davej 16y agoI'm not ignoring it but my code always runs through JSLint each time its saved and that picks up misplaced commas for me. Also we're not talking about client-side javascript here; fortunately Node.js uses the V8 Javascript engine, not the IE7 one. :)
- joelhaasnoot 16y agoIf that's so, why do we not see this in other mainstream languages? While I see the slight advantage of seeing errors, that is the first thing node sees. I use either nodemon or cluster, which both monitor your program on saving your code. When you think you're ready to go, save and see if it has no compile errors.
- krmmalik 16y agoFantastic. Just what i wanted. Thank you so much.
- mononcqc 16y agoHere's some criticism. Taken from 'convincing the boss': ''' Another great aspect of node.js is the ease at which you can develop soft real time systems. By that I mean stuff like twitter, chat software, sport bets or interfaces to instant messaging networks. ''' Those are not all 'soft real time' applications, especially not twitter. Soft real time here might mean that the usefulness of a result degrades if it misses its deadline. This might be the case of some chat software, but in the case of twitter, I receive very little degradation of service if I just go tomorrow. The key point here is that you have to be able to have a metric of a deadline and what to do when you fail it. "If we do not get an acknowledgement by 30 ms, we assume the current node is too busy for our needs and retry on a different one" could be an example of this. ''' So don't try to build hard realtime systems in node, that require consistent response times. Erlang is probably a better choice for these kinds of applications. ''' Erlang is made specifically for soft real time applications, not hard real time. You do not want to use Erlang to build things like life or death systems when you need to be precise to the microsecond. It is pretty good when you can miss a deadline, handle that, work your way around it, but it can not offer any guarantee about never missing a deadline. Not only does this section give bad advice about node.js, it also gives bad advice on other languages. It just feels as if the author meant to say "It is good for interfaces with live updates, which could be slow or lack constancy of response times", not much more. Later in the same section: ''' Combining this with node's radical model of non-blocking I/O, you have to try very hard to create a sluggish application. ''' My understanding was that you actually have to be careful not to write code that runs for too long, in order to avoid messing up your request times by ruining the cooperative scheduling scheme used in the language. === In general, the previous guides seem to be nicer, although I have to question the reason behind advice like 'do not extend the prototypes'. I figure it has to do with the difficulty of keeping things compatible, but if you're giving me advice, tell me why. Do not expect me to blindly follow your standards just because you said so. In the deployment part, it is shown how to use screen to start and detach the server. Is there any reason why nohup or disown won't do it? it is advised not to use the shown setup for a production system -- it would be nice to know where to look for that. I'd also generally be interested in knowing how you'd avoid spaghetti callback hell from the approach used in node.js, but that doesn't seem to be part of the guide. This is a work in progress, and I am not holding this against the author.
- joelhaasnoot 16y agoVery handy. Working on a project with node.js and need to take more of these suggestions to heart. Callbacks take some getting used to, especially returning data is tricky, but it does make things slicker. Node.js is awesome but oh so fragmented: I use Mongoose and Express, both of which have APIs that have changed, and stuff breaks, with lots of old examples floating around. There are also lots of plugins and libraries which seem to do the same thing (cluster, spark, spark2, etc, etc)
- deleted 16y ago[deleted]
- deleted 16y ago[deleted]
- efnx 16y ago(If you're reading Felix) The 'Right' section of Nesting Closures violates the 'Right' section of Named Closures. The outer closure is not named...
- jacoblyles 16y agoIn the "Beginner Guide" section - I would recommend using console.error() instead of console.log() for debugging output because console.error() is blocking while console.log() is not. Nothing is more annoying than your program crashing before it finishes printing debugging output when you are trying to debug a crash!
- felixge 16y agoGood idea, I'll do that.
- beck5 16y agoJust what I am looking for, installed node a few hours ago. Does anyone have any express.js resource recommendations?
- Apocryphon 16y agoI would like to echo my gratitude for this guide. I am also in need of a crash course in Node.js, this is really helpful!
- gumbo 16y agoSomething good to know about usecases where node.js is not a good fit: The truth is that while we are starting to see good frameworks for node.js, there is nothing as powerful as Rails, CakePHP or Django on the scene yet. If most of your app is simply rendering HTML based on some database, using node.js will not provide many tangible business benefits yet.
- reledi 16y agoThank you very much for this guide. I was going to learn Node.js later this month and this will make it much easier.
- FixedPoint 16y agoI am sorry, but event-based programming is the wrong way to tackle the problem of scaling up blocking I/O code. Event-based programming more or less forces one to write in CPS style, which soon becomes a nightmare to reason about. I speak from the experience of having written several thousand lines of such code. A better solution is to pick a language that has light-weight threads (Haskell, Erlang, ...), and let the language handle the events (and call-stacks!) under the hood. Cf the caffeine/percolator paper (even though they do end up using heavy-weight Java threads).
- fghthrth 16y agowelcome to: ====== ( http://www.fullmalls.com http://www.fullmalls.com )==== The website wholesale for many kinds of fashion shoes, like the nike,jordan,prada,, also including the jeans,shirts,bags,hat and the decorations. All the products are free shipping, and the the price is competitive, and also can accept the paypal payment.,after the payment, can ship within short time. free shipping competitive price any size available accept the paypal jordan shoes $32 nike shox $32 Christan Audigier bikini $23 Ed Hardy Bikini $23 Smful short_t-shirt_woman $15 ed hardy short_tank_woman $16 Sandal $32 christian louboutin $80 Sunglass $15 COACH_Necklace $27 handbag $33 AF tank woman $17 puma slipper woman $30 ====== ( http://www.fullmalls.com http://www.fullmalls.com )====
- lxd 16y agoamazing guide, thank you!
- glesperance 16y agoAm I the only one to wonder why there are no mention of coffee-script at all ? It seems to me like a very effective and easy way to make programming more efficient and improve code readability. Moreover,coffee-script handles all OOP concepts that could be needed to use node.