Great article, but there are some issues with the comparison, specifically with the "Pros" listed for Rails:
1. Multi threaded -- This is not a "Pro" as node can take advantage of multiple cores using the built in cluster module: https://nodejs.org/api/cluster.html. Node is multi-threaded too.
2. No callbacks -- I wouldn't consider this a "Pro" as even though it makes programming more complicated, asynchronous code can simulate synchronous code, but not the other way around.
Further, thanks to additions like promises and async/await, asynchronous programming in JavaScript will soon be about as easy to wrap one's head around as synchronous programming without the use of callbacks.
3. Code Maintenance -- It's hard to call this a "Pro" -- it's like comparing apples to oranges. As mentioned in the article "NodeJS is a Runtime Environment for running JavaScript as a server." and "Rails is a Framework for Ruby Language." You'd find less of a difference in comparing Rails to something like Sails (http://sailsjs.org/), a Framework for JavaScript.
Rails can be multithreaded but most often than not it isn't. If you run on MRI you have the GIL so only one thread can run at the same time. Parallelism is achieved by running multiple Ruby processes. However, if you compile with JRuby and run on the JVM you have real multithreading. Not a very popular option in the setups I saw, probably because using JRuby in development is still quite painful and slow compared to MRI.
The premise of the post is incorrect. Rails should not be compared with Node.js but with some web framework running on Node.js. The correct comparison would be Ruby vs Node.js
Ruby is quick to learn, has flexible project structure and has flexible filenames (you can require "x" which defines class Y). Rails was also quick to learn in my experience, but I started with 1.0 with few concepts so maybe a newcomer could have different feelings.
Rails is opinionated, which is a very good thing if you share its opinions. Jump into somebody's else project and by the look of the URL you know exactly where every single file is, unless the dev wanted to be extra clever. You can start fixing things and adding features in a few minutes.
Less opinionated Node or Python or Ruby frameworks are hell to me because I must chase files across folders and understand what the original developer was thinking. It takes more time to me and it costs more to my customer. I don't see the advantages.
3 comments
[ 4.2 ms ] story [ 16.6 ms ] thread1. Multi threaded -- This is not a "Pro" as node can take advantage of multiple cores using the built in cluster module: https://nodejs.org/api/cluster.html. Node is multi-threaded too.
2. No callbacks -- I wouldn't consider this a "Pro" as even though it makes programming more complicated, asynchronous code can simulate synchronous code, but not the other way around. Further, thanks to additions like promises and async/await, asynchronous programming in JavaScript will soon be about as easy to wrap one's head around as synchronous programming without the use of callbacks.
3. Code Maintenance -- It's hard to call this a "Pro" -- it's like comparing apples to oranges. As mentioned in the article "NodeJS is a Runtime Environment for running JavaScript as a server." and "Rails is a Framework for Ruby Language." You'd find less of a difference in comparing Rails to something like Sails (http://sailsjs.org/), a Framework for JavaScript.
Ruby is quick to learn, has flexible project structure and has flexible filenames (you can require "x" which defines class Y). Rails was also quick to learn in my experience, but I started with 1.0 with few concepts so maybe a newcomer could have different feelings.
Rails is opinionated, which is a very good thing if you share its opinions. Jump into somebody's else project and by the look of the URL you know exactly where every single file is, unless the dev wanted to be extra clever. You can start fixing things and adding features in a few minutes.
Less opinionated Node or Python or Ruby frameworks are hell to me because I must chase files across folders and understand what the original developer was thinking. It takes more time to me and it costs more to my customer. I don't see the advantages.