3 ms·

Node.js is an interesting bet for startups. It's hot, yes, and that means that there's a lot of people with a small amount of experience with it. As someone wh

Node.js is an interesting bet for startups. It's hot, yes, and that means that there's a lot of people with a small amount of experience with it. As someone who's worked heavily with Node (and various Node devs) for a while now, it's easy to do very, very wrong. It's not like using Ruby on Rails. The frameworks available for Node.js won't guard you from screwing yourself and your entire team. There are few conventions on how to structure your app. If I tell an experienced Rails dev about a problem I'm having with my Rails app, they can probably navigate to the right directory with their eyes closed. If I tell a Node.js dev I'm having a problem with my Node app, they'll ask for the repo and get back to me in a few minutes. Without at least one very experienced Node.js dev on a team, the project has an extremely high likelihood of ballooning in complexity by the 3-4 week mark, quickly exceeding the 7-plus-or-minus-2 rule and becoming unmanageable. I've seen it happen multiple times. I've made it happen. It's pretty much unavoidable (unless the devs you have on your team are already senior-level with multiple other technologies, and even that isn't guaranteed to save you). Node.js is powerful tech - it allows one to build featureful, highly scalable systems and do it damn fast; but it can also break your startup. Sorry for the tangent, I know this doesn't exactly answer your question. I can't be the only one who's realized this though, so Node.js is probably not a default choice the way Ruby was. If you're looking for "new hotness" points, it seems like Go would be the best bet.

pags 12y ago
It should be noted that none of these comparisons - Ruby\Node.js, nor Rails\Node.js, are really apples to apples.
- notduncansmith 12y ago
  This is very true. I made a point to say "the frameworks available for Node.js" above, but I didn't feel like carrying the rest of that language throughout the rest of the comment. Feel free to replace occurrences of "Node.js" with the above language for comparisons to Rails. Ruby/Node is a pretty fair comparison as far as evaluating "backend server tech". While yes, Ruby is a language and Node is a runtime (thus perhaps making JRuby/Node a more apt comparison), Node.js is far enough removed from client-side Javascript in terms of libraries, knowledge required, etc that I find it pretty easy to compare the two. With Ruby, you find a web framework, supplement with libraries, and code yourself up an app. With Node.js, you do the exact same thing. Good enough for me.
chandika 12y ago
Same applies for things like Meteor.js which are based on Node. Lot's of people dabble in it but to truly know how to not screw it up when building something bigger it takes patience, experimentation and serious effort. This is somewhat compensated by the speed of development you have with such platforms and is a tradeoff.
jeromegv 12y ago
Do you have any good reading to learn about avoiding those pitfalls with node?
- notduncansmith 12y ago
  I wish I did. I can say that watching a lot of Rich Hickey's talks and Gary Bernhardt's Destroy All Software screencasts have made me a better programmer in general, and that has carried over into my Node development practices. Here's a few nuggets that will help you: - Use promises instead of callbacks, specifically Q. Don't let anyone tell you the performance will hurt you - I guarantee that promise execution time is not your bottleneck. - Use event listeners for things like kicking off email notifications. - Use Mandrill for sending those emails. - Use promises. - MySQL is still good tech. - Use Sequelize to make using MySQL/Postgres not hurt. - Abstract into middleware when you can. - Bogart > Express. - Use promises. - Use dependency injection (Omni-DI is a good library for this). - Route handlers are for orchestration, not core business operations. - Avoid for loops. Prefer Array methods like forEach, map, reduce, and filter. - Use promises. I plan on doing more writing about this sort of thing when I have time.
eruditely 12y ago
Define very experienced. People use these terms somewhat loosely and I'd love for a semi-concrete definition relative to concrete measurements that I could check off.

pags 12y ago

It should be noted that none of these comparisons - Ruby\Node.js, nor Rails\Node.js, are really apples to apples.

notduncansmith 12y ago
This is very true. I made a point to say "the frameworks available for Node.js" above, but I didn't feel like carrying the rest of that language throughout the rest of the comment. Feel free to replace occurrences of "Node.js" with the above language for comparisons to Rails. Ruby/Node is a pretty fair comparison as far as evaluating "backend server tech". While yes, Ruby is a language and Node is a runtime (thus perhaps making JRuby/Node a more apt comparison), Node.js is far enough removed from client-side Javascript in terms of libraries, knowledge required, etc that I find it pretty easy to compare the two. With Ruby, you find a web framework, supplement with libraries, and code yourself up an app. With Node.js, you do the exact same thing. Good enough for me.

chandika 12y ago

Same applies for things like Meteor.js which are based on Node. Lot's of people dabble in it but to truly know how to not screw it up when building something bigger it takes patience, experimentation and serious effort. This is somewhat compensated by the speed of development you have with such platforms and is a tradeoff.

jeromegv 12y ago

Do you have any good reading to learn about avoiding those pitfalls with node?

notduncansmith 12y ago
I wish I did. I can say that watching a lot of Rich Hickey's talks and Gary Bernhardt's Destroy All Software screencasts have made me a better programmer in general, and that has carried over into my Node development practices. Here's a few nuggets that will help you: - Use promises instead of callbacks, specifically Q. Don't let anyone tell you the performance will hurt you - I guarantee that promise execution time is not your bottleneck. - Use event listeners for things like kicking off email notifications. - Use Mandrill for sending those emails. - Use promises. - MySQL is still good tech. - Use Sequelize to make using MySQL/Postgres not hurt. - Abstract into middleware when you can. - Bogart > Express. - Use promises. - Use dependency injection (Omni-DI is a good library for this). - Route handlers are for orchestration, not core business operations. - Avoid for loops. Prefer Array methods like forEach, map, reduce, and filter. - Use promises. I plan on doing more writing about this sort of thing when I have time.

eruditely 12y ago

Define very experienced. People use these terms somewhat loosely and I'd love for a semi-concrete definition relative to concrete measurements that I could check off.