Comment by judofyr | Hacker News Reader

Comment by judofyr | Hacker News Reader

I like how the 10th tip is completely opposite of the 1st one.

2 is just a bad tip. Socket pooling is a useful feature. Opening up more connections than you (or the server) can handle will lead to poor performance.

3 and 5 isn't Node.js-specific and you're better off reading https://developers.google.com/speed/ to learn the fine details.

Instead of following 1, 8 and 9 you should learn how to profile your application so you can find the true bottlenecks of your app.

4 and 7 are just weird. Going session-free or switching to client-side architecture are both big tasks; I'd love to hear more about the real challenges, not just "this is fast, zomg!!"

I wish this post had more meat. How did they end up with these tips? How did they profile? How did they benchmark? Where can I read more about the other tips? Without any good links to learn more about the details (seriously, linking to gzip.org was the best you could do?) I'd say these tips can almost do more harm than good…

I'm not sure how the 1st and 10th tips are opposing. The first is to avoid blocking code, and the tenth is to keep the codebase skinny. What have I missed?

I'm not sure how #4 is weird. It can make sense in certain circumstances, as template rendering can be quite expensive. Making this change, though, without data from profiling is probably unnecessary.

Although you didn't touch on #6, they probably should have explained this in a little more detail.

It does sound like they made the decision to use binary modules as a result of profiling, and the fact binary modules exist might be useful info to a node n00b.

This article should probably have been presented more as food for thought, rather than Node's pseudo ten commandments for performance, but nevertheless, it's a useful article for the most part. Developers (well, seasoned ones at least) know to apply critical thinking to all advice anyway.

Practice what you preach. Passive-aggressively sniping at asynchronous code by implying it can never be small or light is not a valid argument. There is no "meat" to such a subjective position.

Callback-based code will always be more complex than synchronous code (and I believe that's an objective observation), but please let's not go there.

My remark was against their "Keep your code small and light". Making your code lighter doesn't always make it faster. If you can get your code to do less (like, skipping memory-based sessions), that will make it faster. If all you're doing is avoiding complexity, there's no guarantee it will be perform better.

The proper way is to benchmark and profile. You can refactor your code based on developer happiness, but only try increase its performance based on objective data.

EDIT: I should probably clarify this (although it seems silly to have to do this on HN): I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea.

Inside of an asynchronous framework where every call blocks all others (eg Node.js), callback-based code is almost always going to be the right choice. If you can't immediately produce the answer, don't wait. And if you can immediately produce the answer but it will take a while, break it up into multiple smaller computations so that you do not block.

If you are in a different environment, the arguments for/against become much different.

> I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea.

Node doesn't really give you much of a choice. If something is going to take awhile then you will be using callbacks, it's that simple.

Reply on news.ycombinator.com