10 ms·

Node.js - Convincing the boss guide

139 points by neovive 15y ago

neovive 15y ago
Somone is proposing Node.js for a project and I was wondering if the advantages/disadvantages in this article are still current. This is for a web application with lots of CRUD, but will also require a custom JSON API.
- jerf 15y ago
  There are tons of existing fast, mature existing options that do great CRUD, JSON APIs (they might call it "REST"), and even have some integration between the two. There's no compelling reason to go with something like Node if that's your use case. That's not so much because Node is intrinsically bad at such things as that the things that it was relatively good at were not that, so the focus hasn't been on that use case. Displacing the existing incumbents in that space would be an incredibly tall order.
tzaman 15y ago
Don't use Node if you have a lot of CRUD, because you'll still have to do a lot of stuff manually. Node's ecosystem is relatively young which means you'll have to do a lot of manual labor (as opposed to something like rails and mature, production-ready gems) and stitching of components. It cat get messy rather quickly, so my advice is "the right tool for the job". These guys nailed my point pretty good: http://www.perfectline.ee/blog/optimizing-ruby-on-rails-application-with-nodejs http://www.perfectline.ee/blog/optimizing-ruby-on-rails-appl...
- neovive 15y ago
  Thanks for the link. I definitely agree. I've never used Node, but didn't want to dismiss any recommendations without fully researching the technology. Perhaps building the API in Node and leaving the CRUD to our existing server-side stack is an option.
  - XLcommerce 15y ago
    This is the route I've gone. The core CRUD part of the app is PHP, and the real-time chat and document collaboration aspect of my app is node. Works beautifully. I've had so much fun working with node for the last few days.
- tferris 15y ago
  I have to disagree. I understand that you can get quickly the feeling that you have to do a lot of stuff manually with node because node packages (gems in node) are more kind of atomic and not full-blown like rails. You can quickly setup a rails-like-environment with node packages. There are different web frameworks which are a refreshing take compared to rails and provide same or better functionality. ORMs like ActiveRecord for SQL DB are available as well. Deployment is easy and the overall ecosystem reflected by npm (node packet manager) is very advanced and brings some innovation into this space (compared to rvm/rbenv).
  - tzaman 15y ago
    Prove it: What is node equivalent of: "rails g resource User email:string password:string"? AFAIK there is none. At least not one that would take care of migrations, validation, security, logic and views. And if I want to use postgres? Sure, there's a npm package. But it's for queries, I still need to define models and validation manually. ....
    - spyder 15y ago
      http://railwayjs.com/ http://railwayjs.com/ http://towerjs.org/ http://towerjs.org/
      - tzaman 15y ago
        Now show me a couple of sites/applications that have at least 100k users and rely solely (ok, mostly) on node.js
        dlagillespie 15y ago
        LinkedIn's iOS apps
        tbeseda 15y ago
        I don't understand what value that would offer, much less what it would prove. This was a thread about accomplishing `rails g resource` with Node. What am I missing?
- xyzzyb 15y ago
  I completely agree, and wrote an article on this while I was frustrated with a node.js project at work that was trying to throw node, backbone, require, mustache, mocha, and dynamoDB. http://rakeroutes.com/blog/the-problem-with-completely-client-side-applications/ http://rakeroutes.com/blog/the-problem-with-completely-clien...
deleted 15y ago
[deleted]
c10n_2 15y ago
The usecase of building JSON api servers are often used. Can someone give some examples of node JSON api implementations?
- Alexandervn 15y ago
  Do you mean companies using it? Look for SimpleGeo. Do you mean librairies? Look for Express or Restify.
- jedschmidt 15y ago
  I recently built SAJAK (Simple Authenticated JSON API Kit) to suit my own needs: https://github.com/jed/sajak https://github.com/jed/sajak
  - Sivart13 15y ago
    Good name.
hsmyers 15y ago
JavaScript seems to be having the same problem that other languages have developed over usage time. It becomes increasingly difficult to know what package does what and more importantly information of the pros and cons of the package. Does anyone know of a link to something similar to what I'm talking about? Say something meaningful about the top N (where N might be 10 or so) packages---what they do, the good and the bad?
- mnutt 15y ago
  Check out the Node Toolbox: http://toolbox.no.de/ http://toolbox.no.de/ It doesn't seem as fleshed out as the Ruby Toolbox (https://www.ruby-toolbox.com https://www.ruby-toolbox.com) and could use a bit more editorial for your purposes, but it's a good place to start.
  - bmelton 15y ago
    Thanks a ton for posting that. I'm new to Node, and it's a great help. Of course, it'll never go anywhere until whomever is maintaining it either allows for crowdsourcing of the data or tries harder, because the first couple of packages I looked at had very poor descriptions. Coffeescript, for example, is defined as "Unfancy JavaScript". CS is one that I happen to know about, and by that definition, I'd have never ever switched to it.
- yesbabyyes 15y ago
  Peteris Krumins had a nice series of Node.js modules you should know about: http://www.catonmat.net/category/nodejs-modules http://www.catonmat.net/category/nodejs-modules Some of my favorites: - async -- flow control - stitch -- packaging client side scripts - express -- web framework - redis -- great Redis client - stylus -- css preprocessor - request -- HTTP client I find myself following certain people, like how I'm a fan of different rappers. Usually, stuff by visionmedia, felixge, mikeal, isaacs, substack is top notch.
pjmlp 15y ago
So far I don't see any benefit in node.js over mature enterprise frameworks.
- famousactress 15y ago
  That's funny, cause I'd prefer literally anything that isn't called an enterprise framework.
  - wolraf 15y ago
    Bash cgi?
- sandfox 15y ago
  The whole point of node.js and it's ecosystem is to avoid anything that looks like an 'enterprise framework', rather it's a collection of lots of little modules that each do one thing and one thing well and that can build on top of each other (turtles all the way down).
  - Cloven 15y ago
    That sounds like a lot of fun to maintain and keep version control on, especially when they're written by different people with different motivations.
hamidpalo 15y ago
Why is non-blocking IO radical? Tons of libraries and frameworks offered it much before node, including twisted, Java's NIO, and the entire System.Net namespace in .NET. Other than that, surprisingly sensible advice.
- jbooth 15y ago
  It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world. I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks. But don't listen to anyone who tells you they use node+mongo to handle their WEB SCALE PERFORMANCE. If they really had that problem, they'd be better off using the java ecosystem or, if they really wanted to go hardcore, using a lot of C. But Java's unfashionable and C's ridiculous to write a web app.
  - mcantelon 15y ago
    >doesn't really have any performance benefits in the multicore world AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.
    - jbooth 15y ago
      From what I could tell, that spawns actual child processes and communicates with them over pipes. Fine from an architectural standpoint, but a penalty compared to shared memory from a performance standpoint. And it still has the problem of a single heavy CPU request on a given worker blocking all the requests behind it on that worker. Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying if you really need to crank out performance, use java.util.concurrent, or maybe Go. They both offer event-driven i/o if you really want it, and have better threading models.
- SkyMarshal 15y ago
DanI-S 15y ago
Here's something oft-understated: As a web developer, you sit on the intersection of engineering, design and art. You're lucky enough to live at a time where there are numerous production-ready tools with which to do your job. If you choose a tool that you're excited to explore, with an active and fast-moving ecosystem, your excitement and enthusiasm will make you happier and more likely to do a better job. Someone down the thread said this: > So far I don't see any benefit in node.js over mature enterprise frameworks. If I was only allowed to work in ASP.NET, I'd be looking to change careers pretty fast. Don't underestimate the value of enthusiasm - especially if you're a boss.
- RyanMcGreal 15y ago
  > Don't underestimate the value of enthusiasm - especially if you're a boss. Indeed, and your advice is wisely directed at bosses. However, it's a bit harder (though not impossible) for a developer to use this argument successfully: "Let me use Node because I'll be more excited about the project."
  - DanI-S 15y ago
    That does sound true, although in some cases, "It will help with recruitment" might help.
    - taligent 15y ago
      I guarantee you it is 100x harder to get Node.JS developers than Java/ASP ones. Especially if you don't live in the US.
- neovive 15y ago
  Excellent points!! Always keep an eye open towards the advantages and disadvantages of anything new. Don't immediately dismiss something because it is new, just as you wouldn't immediately start using something new. Research and learn.
  - tzaman 15y ago
j2labs 15y ago
I love that this started with bad use cases.
arturadib 15y ago
> Bad Use Cases: CPU heavy apps I wouldn't say that Node (i.e. V8) is a bad use case for CPU-heavy apps. In math/statistics for example, V8 stacks up well against other scripting alternatives. See e.g. the benchmarks here: http://julialang.org/ http://julialang.org/ Of course it's still not as fast as C++, but not terribly off either. Expect dramatic improvements here thanks to the push for making web apps faster.
- jbooth 15y ago
  In that example, V8 javascript was 400x slower than the alternatives for matrix multiplication. That's because it's not binding to the BLAS libraries like the 'real' statistical languages. Of course, node supports calling out to C APIs, but that's not an argument for javascript, dynamic languages will naturally be terrible at math compared to C. More to the point: Node does nonblocking i/o but cpu work is in fact blocking. This means that a CPU-heavy request queues up all requests behind it, waiting to get access to the CPU. You're better off using a threaded architecture for CPU-heavy work.
  - arturadib 15y ago
    That's silly. No one in their sane mind would serve web requests AND do heavy processing in the same thread - no matter what language. In Node, you would have a process responding to web requests, and launch a separate process -- via a convenient child_process with built-in pipe communication -- for doing the heavy CPU work. The only case where that wouldn't make sense is if you need BOTH a ton of concurrency AND heavy CPU work. In that case, threads would make sense as they would be cheaper memory-wise. But my point remains: CPU-heavy applications don't necessarily rule out Node as a feasible alternative. PS: V8 was 40x slower, not 400, in that one benchmark result you picked.
    - jbooth 15y ago
      Well, in Java I serve rpc requests and doing heavy processing from the same thread all the time, and it works great. What would we have to do in node to get the same level of performance? We'd need a front end instance delegating requests to 8 back-end instances for each core? Writing all these bytes over internal pipes and blowing L1/L2 cache all the time as the data moves across cores? At a certain point, isn't it just way easier and more effective to have one thread spinning an accept loop and a threadpool handling the requests, all within one process bound to a port? As I said upthread, I'm using node for a side project right now and I'm liking server-side js for a variety of reasons, but squeezing every cycle out of the CPU is not one of them.
jroseattle 15y ago
We're running a nodejs+nosql+js-heavy-client project right now. While evaluating any stack component is an important task, it is certainly more so important in this environment. This guide is OK, but it's insufficient. If you're going to do a technical evaluation of the node/nosql/js-client stack for risk assessment, you're going to need to get much more granular than what this guide offers. This is a fine guide for a project lead, but this is somewhat useless for the system designer. For example, in reference to "nosql+node+buzzword+bull$#!t", the advice is to use nosql when you "really" know it, otherwise stick with mysql/postgres. While the devil-you-know-vs-devil-you-dont is a fine project mitigation strategy, it's not a very good technical strategy. Maybe the guide's author assumes one would do so, but the nosql/rdbms comparison exercise is not trivial and requires you to do your homework. Understanding and contrasting the finer points of comparing nosql operations vs. relational data stores is much more useful than a blanket comment. Like I said, it's a fine guide, but it's much more useful for those who aren't necessarily responsible for determining the stack's applicability to a given project.
ChrisArchitect 15y ago
this is great. in general, need more of these sorts of 'convincing x' guides ...purely for need for the right 'language'/points to convey benefits without getting lost in tech/trendspeak.
cageface 15y ago
Go seems to me to provide the benefits of Node's non-blocking IO with a much easier programming model and a much less warty language. But I haven't actually built anything real in either language yet. Anyone with experience in both care to contrast them? Their problem domains seem to overlap quite a bit.
- dsl 15y ago
  We did some bake-offs with node and Go (and other languages of course). Go won pretty much across the board, except in the time to write category. The other big downside to Node is hiring. You have two types of "JavaScript" developers. People good with JQuery, and people who have written JavaScript books. There is extremely little middle ground from which to hire good to awesome developers. Go is the C replacement. Node.js is going to be a Ruby replacement one day.
  - cageface 15y ago
    Interesting. My own limited experience with Go suggests that it requires more time to write but less time to test and debug and tune so it might b a wash overall. Where did you find you were spending most of your time?
    - dsl 15y ago
      What I meant was that Node is super fast for cranking out proof-of-concept stuff, and that was its big win. When it got down to trying to close the performance gap between Node and Go (an order of magnitude requests/sec) we sunk a lot more time into Node unfortunately.
      - cageface 15y ago
        That jibes with my intuitions after looking briefly at both of them. Node seems like it would be quick for quickly banging out prototypes but I can imagine that all the other metrics might tilt pretty quickly towards Go. I've recently rediscovered the joys of static typing so that alone inclines me much more toward go.
hack_edu 15y ago
Lately my problem has been convincing my boss NOT to use Node on every little project. Don't get me wrong, Node is versatile and fun, but not the most appropriate choice for systems work and your usual DevOps tools. To him, any little one of script written by the team (except his own) must be re-done in Node. Then, the code being "his", he'll upload it to his own personal github account. Meanwhile, we have to reimplement the new Node written tool.
dylanz 15y ago
"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 actually suited for soft realtime systems as well. I've never seen it recommended for hard realtime systems.
Sivart13 15y ago
The table of contents at the top of this article makes it look 10 times more intimidating than it really is.
daemonza 15y ago
I seriously think Node.js is one of those things that get's overhyped. Yes it's fun to code...until the nested callbacks get's too much. For me personally I will stick production code with ruby/sinatra and eventmachine and play with node for personal projects.

139 points by neovive 15y ago

Somone is proposing Node.js for a project and I was wondering if the advantages/disadvantages in this article are still current. This is for a web application with lots of CRUD, but will also require a custom JSON API.

jerf 15y ago
There are tons of existing fast, mature existing options that do great CRUD, JSON APIs (they might call it "REST"), and even have some integration between the two. There's no compelling reason to go with something like Node if that's your use case. That's not so much because Node is intrinsically bad at such things as that the things that it was relatively good at were not that, so the focus hasn't been on that use case. Displacing the existing incumbents in that space would be an incredibly tall order.

tzaman 15y ago

Don't use Node if you have a lot of CRUD, because you'll still have to do a lot of stuff manually. Node's ecosystem is relatively young which means you'll have to do a lot of manual labor (as opposed to something like rails and mature, production-ready gems) and stitching of components. It cat get messy rather quickly, so my advice is "the right tool for the job". These guys nailed my point pretty good: http://www.perfectline.ee/blog/optimizing-ruby-on-rails-application-with-nodejs http://www.perfectline.ee/blog/optimizing-ruby-on-rails-appl...

neovive 15y ago
Thanks for the link. I definitely agree. I've never used Node, but didn't want to dismiss any recommendations without fully researching the technology. Perhaps building the API in Node and leaving the CRUD to our existing server-side stack is an option.
- XLcommerce 15y ago
  This is the route I've gone. The core CRUD part of the app is PHP, and the real-time chat and document collaboration aspect of my app is node. Works beautifully. I've had so much fun working with node for the last few days.
tferris 15y ago
I have to disagree. I understand that you can get quickly the feeling that you have to do a lot of stuff manually with node because node packages (gems in node) are more kind of atomic and not full-blown like rails. You can quickly setup a rails-like-environment with node packages. There are different web frameworks which are a refreshing take compared to rails and provide same or better functionality. ORMs like ActiveRecord for SQL DB are available as well. Deployment is easy and the overall ecosystem reflected by npm (node packet manager) is very advanced and brings some innovation into this space (compared to rvm/rbenv).
- tzaman 15y ago
  Prove it: What is node equivalent of: "rails g resource User email:string password:string"? AFAIK there is none. At least not one that would take care of migrations, validation, security, logic and views. And if I want to use postgres? Sure, there's a npm package. But it's for queries, I still need to define models and validation manually. ....
  - spyder 15y ago
    http://railwayjs.com/ http://railwayjs.com/ http://towerjs.org/ http://towerjs.org/
    - tzaman 15y ago
      Now show me a couple of sites/applications that have at least 100k users and rely solely (ok, mostly) on node.js
      - dlagillespie 15y ago
        LinkedIn's iOS apps
      - tbeseda 15y ago
        I don't understand what value that would offer, much less what it would prove. This was a thread about accomplishing `rails g resource` with Node. What am I missing?
xyzzyb 15y ago
I completely agree, and wrote an article on this while I was frustrated with a node.js project at work that was trying to throw node, backbone, require, mustache, mocha, and dynamoDB. http://rakeroutes.com/blog/the-problem-with-completely-client-side-applications/ http://rakeroutes.com/blog/the-problem-with-completely-clien...

deleted 15y ago

[deleted]

c10n_2 15y ago

The usecase of building JSON api servers are often used. Can someone give some examples of node JSON api implementations?

Alexandervn 15y ago
Do you mean companies using it? Look for SimpleGeo. Do you mean librairies? Look for Express or Restify.
jedschmidt 15y ago
I recently built SAJAK (Simple Authenticated JSON API Kit) to suit my own needs: https://github.com/jed/sajak https://github.com/jed/sajak
- Sivart13 15y ago
  Good name.

hsmyers 15y ago

JavaScript seems to be having the same problem that other languages have developed over usage time. It becomes increasingly difficult to know what package does what and more importantly information of the pros and cons of the package. Does anyone know of a link to something similar to what I'm talking about? Say something meaningful about the top N (where N might be 10 or so) packages---what they do, the good and the bad?

mnutt 15y ago
Check out the Node Toolbox: http://toolbox.no.de/ http://toolbox.no.de/ It doesn't seem as fleshed out as the Ruby Toolbox (https://www.ruby-toolbox.com https://www.ruby-toolbox.com) and could use a bit more editorial for your purposes, but it's a good place to start.
- bmelton 15y ago
  Thanks a ton for posting that. I'm new to Node, and it's a great help. Of course, it'll never go anywhere until whomever is maintaining it either allows for crowdsourcing of the data or tries harder, because the first couple of packages I looked at had very poor descriptions. Coffeescript, for example, is defined as "Unfancy JavaScript". CS is one that I happen to know about, and by that definition, I'd have never ever switched to it.
yesbabyyes 15y ago
Peteris Krumins had a nice series of Node.js modules you should know about: http://www.catonmat.net/category/nodejs-modules http://www.catonmat.net/category/nodejs-modules Some of my favorites: - async -- flow control - stitch -- packaging client side scripts - express -- web framework - redis -- great Redis client - stylus -- css preprocessor - request -- HTTP client I find myself following certain people, like how I'm a fan of different rappers. Usually, stuff by visionmedia, felixge, mikeal, isaacs, substack is top notch.

pjmlp 15y ago

So far I don't see any benefit in node.js over mature enterprise frameworks.

famousactress 15y ago
That's funny, cause I'd prefer literally anything that isn't called an enterprise framework.
- wolraf 15y ago
  Bash cgi?
sandfox 15y ago
The whole point of node.js and it's ecosystem is to avoid anything that looks like an 'enterprise framework', rather it's a collection of lots of little modules that each do one thing and one thing well and that can build on top of each other (turtles all the way down).
- Cloven 15y ago
  That sounds like a lot of fun to maintain and keep version control on, especially when they're written by different people with different motivations.

hamidpalo 15y ago

Why is non-blocking IO radical? Tons of libraries and frameworks offered it much before node, including twisted, Java's NIO, and the entire System.Net namespace in .NET. Other than that, surprisingly sensible advice.

jbooth 15y ago
It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world. I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks. But don't listen to anyone who tells you they use node+mongo to handle their WEB SCALE PERFORMANCE. If they really had that problem, they'd be better off using the java ecosystem or, if they really wanted to go hardcore, using a lot of C. But Java's unfashionable and C's ridiculous to write a web app.
- mcantelon 15y ago
  >doesn't really have any performance benefits in the multicore world AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.
  - jbooth 15y ago
    From what I could tell, that spawns actual child processes and communicates with them over pipes. Fine from an architectural standpoint, but a penalty compared to shared memory from a performance standpoint. And it still has the problem of a single heavy CPU request on a given worker blocking all the requests behind it on that worker. Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying if you really need to crank out performance, use java.util.concurrent, or maybe Go. They both offer event-driven i/o if you really want it, and have better threading models.
SkyMarshal 15y ago

DanI-S 15y ago

Here's something oft-understated: As a web developer, you sit on the intersection of engineering, design and art. You're lucky enough to live at a time where there are numerous production-ready tools with which to do your job. If you choose a tool that you're excited to explore, with an active and fast-moving ecosystem, your excitement and enthusiasm will make you happier and more likely to do a better job. Someone down the thread said this: > So far I don't see any benefit in node.js over mature enterprise frameworks. If I was only allowed to work in ASP.NET, I'd be looking to change careers pretty fast. Don't underestimate the value of enthusiasm - especially if you're a boss.

RyanMcGreal 15y ago
> Don't underestimate the value of enthusiasm - especially if you're a boss. Indeed, and your advice is wisely directed at bosses. However, it's a bit harder (though not impossible) for a developer to use this argument successfully: "Let me use Node because I'll be more excited about the project."
- DanI-S 15y ago
  That does sound true, although in some cases, "It will help with recruitment" might help.
  - taligent 15y ago
    I guarantee you it is 100x harder to get Node.JS developers than Java/ASP ones. Especially if you don't live in the US.
neovive 15y ago
Excellent points!! Always keep an eye open towards the advantages and disadvantages of anything new. Don't immediately dismiss something because it is new, just as you wouldn't immediately start using something new. Research and learn.
- tzaman 15y ago

j2labs 15y ago

I love that this started with bad use cases.

arturadib 15y ago

> Bad Use Cases: CPU heavy apps I wouldn't say that Node (i.e. V8) is a bad use case for CPU-heavy apps. In math/statistics for example, V8 stacks up well against other scripting alternatives. See e.g. the benchmarks here: http://julialang.org/ http://julialang.org/ Of course it's still not as fast as C++, but not terribly off either. Expect dramatic improvements here thanks to the push for making web apps faster.

jbooth 15y ago
In that example, V8 javascript was 400x slower than the alternatives for matrix multiplication. That's because it's not binding to the BLAS libraries like the 'real' statistical languages. Of course, node supports calling out to C APIs, but that's not an argument for javascript, dynamic languages will naturally be terrible at math compared to C. More to the point: Node does nonblocking i/o but cpu work is in fact blocking. This means that a CPU-heavy request queues up all requests behind it, waiting to get access to the CPU. You're better off using a threaded architecture for CPU-heavy work.
- arturadib 15y ago
  That's silly. No one in their sane mind would serve web requests AND do heavy processing in the same thread - no matter what language. In Node, you would have a process responding to web requests, and launch a separate process -- via a convenient child_process with built-in pipe communication -- for doing the heavy CPU work. The only case where that wouldn't make sense is if you need BOTH a ton of concurrency AND heavy CPU work. In that case, threads would make sense as they would be cheaper memory-wise. But my point remains: CPU-heavy applications don't necessarily rule out Node as a feasible alternative. PS: V8 was 40x slower, not 400, in that one benchmark result you picked.
  - jbooth 15y ago
    Well, in Java I serve rpc requests and doing heavy processing from the same thread all the time, and it works great. What would we have to do in node to get the same level of performance? We'd need a front end instance delegating requests to 8 back-end instances for each core? Writing all these bytes over internal pipes and blowing L1/L2 cache all the time as the data moves across cores? At a certain point, isn't it just way easier and more effective to have one thread spinning an accept loop and a threadpool handling the requests, all within one process bound to a port? As I said upthread, I'm using node for a side project right now and I'm liking server-side js for a variety of reasons, but squeezing every cycle out of the CPU is not one of them.

jroseattle 15y ago

We're running a nodejs+nosql+js-heavy-client project right now. While evaluating any stack component is an important task, it is certainly more so important in this environment. This guide is OK, but it's insufficient. If you're going to do a technical evaluation of the node/nosql/js-client stack for risk assessment, you're going to need to get much more granular than what this guide offers. This is a fine guide for a project lead, but this is somewhat useless for the system designer. For example, in reference to "nosql+node+buzzword+bull$#!t", the advice is to use nosql when you "really" know it, otherwise stick with mysql/postgres. While the devil-you-know-vs-devil-you-dont is a fine project mitigation strategy, it's not a very good technical strategy. Maybe the guide's author assumes one would do so, but the nosql/rdbms comparison exercise is not trivial and requires you to do your homework. Understanding and contrasting the finer points of comparing nosql operations vs. relational data stores is much more useful than a blanket comment. Like I said, it's a fine guide, but it's much more useful for those who aren't necessarily responsible for determining the stack's applicability to a given project.

ChrisArchitect 15y ago

this is great. in general, need more of these sorts of 'convincing x' guides ...purely for need for the right 'language'/points to convey benefits without getting lost in tech/trendspeak.

cageface 15y ago

Go seems to me to provide the benefits of Node's non-blocking IO with a much easier programming model and a much less warty language. But I haven't actually built anything real in either language yet. Anyone with experience in both care to contrast them? Their problem domains seem to overlap quite a bit.

dsl 15y ago
We did some bake-offs with node and Go (and other languages of course). Go won pretty much across the board, except in the time to write category. The other big downside to Node is hiring. You have two types of "JavaScript" developers. People good with JQuery, and people who have written JavaScript books. There is extremely little middle ground from which to hire good to awesome developers. Go is the C replacement. Node.js is going to be a Ruby replacement one day.
- cageface 15y ago
  Interesting. My own limited experience with Go suggests that it requires more time to write but less time to test and debug and tune so it might b a wash overall. Where did you find you were spending most of your time?
  - dsl 15y ago
    What I meant was that Node is super fast for cranking out proof-of-concept stuff, and that was its big win. When it got down to trying to close the performance gap between Node and Go (an order of magnitude requests/sec) we sunk a lot more time into Node unfortunately.
    - cageface 15y ago
      That jibes with my intuitions after looking briefly at both of them. Node seems like it would be quick for quickly banging out prototypes but I can imagine that all the other metrics might tilt pretty quickly towards Go. I've recently rediscovered the joys of static typing so that alone inclines me much more toward go.

hack_edu 15y ago

Lately my problem has been convincing my boss NOT to use Node on every little project. Don't get me wrong, Node is versatile and fun, but not the most appropriate choice for systems work and your usual DevOps tools. To him, any little one of script written by the team (except his own) must be re-done in Node. Then, the code being "his", he'll upload it to his own personal github account. Meanwhile, we have to reimplement the new Node written tool.

dylanz 15y ago

"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 actually suited for soft realtime systems as well. I've never seen it recommended for hard realtime systems.

Sivart13 15y ago

The table of contents at the top of this article makes it look 10 times more intimidating than it really is.

daemonza 15y ago

I seriously think Node.js is one of those things that get's overhyped. Yes it's fun to code...until the nested callbacks get's too much. For me personally I will stick production code with ruby/sinatra and eventmachine and play with node for personal projects.