Serious question: What is the benefit of Node.js over other server-side platforms? Is it just because client-side developers are already familiar with JavaScript?
Well, yeah, that's one benefit. In many cases it makes sense to allow client-side developers to work on their own backend and have the "real" backend somewhere else (which could also be Node or could be something totally different).
But there are other benefits, those are depending on what you compare it against.
Primary advantage (to me at least) over other frameworks and server-side platforms is that it's asyncronous by design versus something tacked on or optional that you decide to use later (which could be problematic if you have a lot of highly coupled code that blocks [or worse, you aren't aware that it does]). If you're considering doing something that requires a lot of asyncronous processing, it's a good choice to avoid potential headaches that can arise if you're not careful when using some alternatives.
TypeScript also works well with Node.js if you want something more strongly typed (and with classes) on the server side and still have the advantages that Node brings.
The primary value that I've experienced is that I can run the same code -- as in the same version of a library -- as part of a CLI app and as part of an interactive JS web app.
So, ignore the async arguments, because everybody else (mostly) can do that too.
The things I like about it are NPM, which is the package manager and is quite handy--maybe a bit better than bundler for what it does.
Writing extensions in C/C++ is not hard to do.
Extending node with your own Javascript code and bundling that as a library for others is not hard at all (see NPM).
It actually runs on Windows with a minimum of wailing and gnashing of teeth.
You can do remote debugging of a server with some sanity.
It plays with messaging libraries (zmq, sockjs, etc.) very well.
Grunt is awesome for running tests and not being makefiles.
There is a pretty cool LDAP client/server library available for it.
~
That said, there are some things that bug me.
Javascript has some nasty edges, and anything you don't like about Javascript won't go away with node.
Async callback spaghetti hell will happen unless you use something like promises via Q, and it will suck.
It's a young platform, and nobody quite seems to have Rails or CodeIgniter or whatever for Node yet--too many contenders currently.
There is no standard ORM yet, and has the same issues as above: many choices, no winners.
Node devs can be derpy sometimes (usually around threading, fibers, rediscovering basic principles of operating systems engineering, etc.) It's a loveable derpiness though.
Express (a pretty standard Sinatra-like web server for node) can die in a fire: its docs are bad and the devs should feel bad (and it's soon to be abandoned, it looks like, as there is yet another new shiny incarnation of it on the way.).
~
It is quite good at prototyping at hackathons, though.
I have a very different view point than most about why I think Node.js is popular. Take it for what it's worth.
I've always sort of laughed at the idea of Front-End developers flocking to Node.js just for the fact that it is the same language. I actually really like Node.js but hardly ever use it for web apps. I think where it shines is as a platform for systems programming and I think when you look at Node.js systems programming was clearly at the forefront of the design.
I can't count how many Front-End-to-Node.js developers I've worked with that have been using Node for a year or more and have no clue about processes, sockets, streams and pipes. Perhaps that is a testament to libraries like Express that hide all of that, but in my opinion the beauty of Node.js is all of that "other stuff" Front-End people ignore. To each their own I guess.
Also, the myth of sharing Server and Client code is almost never done and even when it is, it isn't done well.
Agree, i don't know why Front-End devs think that just because is the same language everything will apply as the same context. The only reason why node is installed in my machine is that i use some npm packages for my workflow.
Depends what you mean by other server side platforms. What does it compete with?
Node.js isn't a web framework so it doesn't compete with Django, Rails, ASP.Net, PHP etc. I generally consider it a tool for building web services, which it's great at.
For example: I've got Node.js servers which host JSON APIs calling Postgres stored procs on a Django app because it's faster than going through Django when you've worked out the interfaces.
Package system is a breeze. That alone is wonderful.
That, and probably the breakneck pace at which it forces you to embrace asynchronous operations. As async, parallelism, and concurrency become more important, I think it's valuable to start thinking in these terms as fast as possible.
I had a really, really hard time using Twisted every single time I tried, over the last 5 years. It's a very opinionated framework that requires you to structure your code and business logic in a very specific way.
I'd love to see alternatives to Twisted that are built as a library rather than a framework.
I've come to be a big fan of async.auto which allows me to break a large task down into smaller functional steps, define their required dependencies on each other, and then just let async take care of the magic of executing the operations in the correct order, and parallelizing operations when possible.
Do any of you promise and/or generator users know of a good equivalent to async.auto?
I feel like promises and generators have potential but much of my code is based on async.auto and I feel like it would be complicated and painful to try to rewrite that with promises and generators.
Yet you still need to write callbacks.Neither async nor promises nor generators solve that issue.Afaik only fibers make the code lighter. ES6, arrow functions will make things less painfull though.
24 comments
[ 5.2 ms ] story [ 90.2 ms ] threadShare code for server and client (HTML5) side.
But there are other benefits, those are depending on what you compare it against.
TypeScript also works well with Node.js if you want something more strongly typed (and with classes) on the server side and still have the advantages that Node brings.
The things I like about it are NPM, which is the package manager and is quite handy--maybe a bit better than bundler for what it does.
Writing extensions in C/C++ is not hard to do.
Extending node with your own Javascript code and bundling that as a library for others is not hard at all (see NPM).
It actually runs on Windows with a minimum of wailing and gnashing of teeth.
You can do remote debugging of a server with some sanity.
It plays with messaging libraries (zmq, sockjs, etc.) very well.
Grunt is awesome for running tests and not being makefiles.
There is a pretty cool LDAP client/server library available for it.
~
That said, there are some things that bug me.
Javascript has some nasty edges, and anything you don't like about Javascript won't go away with node.
Async callback spaghetti hell will happen unless you use something like promises via Q, and it will suck.
It's a young platform, and nobody quite seems to have Rails or CodeIgniter or whatever for Node yet--too many contenders currently.
There is no standard ORM yet, and has the same issues as above: many choices, no winners.
Node devs can be derpy sometimes (usually around threading, fibers, rediscovering basic principles of operating systems engineering, etc.) It's a loveable derpiness though.
Express (a pretty standard Sinatra-like web server for node) can die in a fire: its docs are bad and the devs should feel bad (and it's soon to be abandoned, it looks like, as there is yet another new shiny incarnation of it on the way.).
~
It is quite good at prototyping at hackathons, though.
True, but other async platforms lack a developed ecosystem of add-ons written to be asynchronous.
I've always sort of laughed at the idea of Front-End developers flocking to Node.js just for the fact that it is the same language. I actually really like Node.js but hardly ever use it for web apps. I think where it shines is as a platform for systems programming and I think when you look at Node.js systems programming was clearly at the forefront of the design.
I can't count how many Front-End-to-Node.js developers I've worked with that have been using Node for a year or more and have no clue about processes, sockets, streams and pipes. Perhaps that is a testament to libraries like Express that hide all of that, but in my opinion the beauty of Node.js is all of that "other stuff" Front-End people ignore. To each their own I guess.
Also, the myth of sharing Server and Client code is almost never done and even when it is, it isn't done well.
Node.js isn't a web framework so it doesn't compete with Django, Rails, ASP.Net, PHP etc. I generally consider it a tool for building web services, which it's great at.
For example: I've got Node.js servers which host JSON APIs calling Postgres stored procs on a Django app because it's faster than going through Django when you've worked out the interfaces.
That, and probably the breakneck pace at which it forces you to embrace asynchronous operations. As async, parallelism, and concurrency become more important, I think it's valuable to start thinking in these terms as fast as possible.
I'd love to see alternatives to Twisted that are built as a library rather than a framework.
http://blog.carbonfive.com/2013/12/01/hanging-up-on-callback...
By the way, for those that are interested, here's a link you can use to learn/understand how generators can help with async control flow: http://blogs.atlassian.com/2013/11/harmony-generators-and-pr...
Do any of you promise and/or generator users know of a good equivalent to async.auto?
I feel like promises and generators have potential but much of my code is based on async.auto and I feel like it would be complicated and painful to try to rewrite that with promises and generators.
Yikes. That is not so wonderful looking. But yeah, it's better than callback hell.