5 ms·

I think Node.js is neat but could someone tell me how it's so awesome. When Rails came it was truly awesome because the language it used and the framework was

I think Node.js is neat but could someone tell me how it's so awesome. When Rails came it was truly awesome because the language it used and the framework was so much easier to work with then Java or .Net and some would say better designed then Perl or PHP. I don't see how Node.js makes developing so much easier than say Rails (unless of course you have a crazy high IO kind of app, which most don't)

FooBarWidget 15y ago
Node.js isn't easier than Rails, at least for the things that Rails is good at. Node.js is good for apps that require high I/O concurrency, things like chat servers, but much much worse than Rails for pretty much everything else. I see Node.js only being useful for special types of applications, it is not the next Rails or anything like that. Unfortunately I foresee that people will (ab?)use Node.js as some kind of Rails replacement.
- va_coder 15y ago
  Thanks for the insight
olegp 15y ago
To add to what FooBarWidget said, I do believe that there are inherent advantages to using JavaScript on the server for developing webapps. For one, due to the dominance of JavaScript within browsers, it is the one dynamic language we will be stuck with for at least the next 20 years! However, unless you're implementing servers, I believe it's better to go with synchronous I/O to simplify webapp development. That is exactly what we're doing at Akshell (http://www.akshell.com http://www.akshell.com).
- sausagefeet 15y ago
  Why do you believe synchronous I/O is better for building web apps? Certainly it is worse for utilizing resources. The problem seems to be that most of the internet is about 20 years behind when it comes to performing I/O well. Erlang, Haskell, Mozart/Oz all do it superior to something like Node, people just haven't realized it yet so a language that people want to use can be built.
  - olegp 15y ago
    Because most webapps do not need to be optimized for performance, but rather for ease of maintenance. Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives. At Akshell we're adding a Node based pubsub server with support for both server and browser based subscribers, allowing us to get the best of both worlds: a large number of concurrent connections combined with business logic & message processing using synchronous code.
    - sausagefeet 15y ago
      > Because most webapps do not need to be optimized for performance, but rather for ease of maintenance. I don't see how this conflicts with asynchronous I/O unless you're limiting yourself to Twisted/Node. > Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives. This is exactly how you write an Erlang application. Erlang supports asynchronous I/O. Your viewpoint is accurate if you limit yourself to many of the mainstream languages that are simply terrible at concurrency, but I think this is only temporal. As more work goes onto web apps synchronous I/O simply isn't going to cut it (as many people running popular websites already know).
      - olegp 15y ago
        Agreed on the first part, unfortunately most functional languages are difficult for most developers (read: non-academics or HN readers) to grasp. As somebody who taught me ML said: "if it's difficult to write, it should be difficult to read". Perhaps this will change, but it will be a while before we have a functional language that's as mainstream as JavaScript. Most big websites have asynchronous components to address their performance bottlenecks, but the bulk of the business logic uses synchronous I/O and unfashionable languages like PHP as per the 90/10 law: http://en.wikipedia.org/wiki/Program_optimization#Bottlenecks http://en.wikipedia.org/wiki/Program_optimization#Bottleneck...

FooBarWidget 15y ago

Node.js isn't easier than Rails, at least for the things that Rails is good at. Node.js is good for apps that require high I/O concurrency, things like chat servers, but much much worse than Rails for pretty much everything else. I see Node.js only being useful for special types of applications, it is not the next Rails or anything like that. Unfortunately I foresee that people will (ab?)use Node.js as some kind of Rails replacement.

va_coder 15y ago
Thanks for the insight

olegp 15y ago

To add to what FooBarWidget said, I do believe that there are inherent advantages to using JavaScript on the server for developing webapps. For one, due to the dominance of JavaScript within browsers, it is the one dynamic language we will be stuck with for at least the next 20 years! However, unless you're implementing servers, I believe it's better to go with synchronous I/O to simplify webapp development. That is exactly what we're doing at Akshell (http://www.akshell.com http://www.akshell.com).

sausagefeet 15y ago
Why do you believe synchronous I/O is better for building web apps? Certainly it is worse for utilizing resources. The problem seems to be that most of the internet is about 20 years behind when it comes to performing I/O well. Erlang, Haskell, Mozart/Oz all do it superior to something like Node, people just haven't realized it yet so a language that people want to use can be built.
- olegp 15y ago
  Because most webapps do not need to be optimized for performance, but rather for ease of maintenance. Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives. At Akshell we're adding a Node based pubsub server with support for both server and browser based subscribers, allowing us to get the best of both worlds: a large number of concurrent connections combined with business logic & message processing using synchronous code.
  - sausagefeet 15y ago
    > Because most webapps do not need to be optimized for performance, but rather for ease of maintenance. I don't see how this conflicts with asynchronous I/O unless you're limiting yourself to Twisted/Node. > Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives. This is exactly how you write an Erlang application. Erlang supports asynchronous I/O. Your viewpoint is accurate if you limit yourself to many of the mainstream languages that are simply terrible at concurrency, but I think this is only temporal. As more work goes onto web apps synchronous I/O simply isn't going to cut it (as many people running popular websites already know).
    - olegp 15y ago
      Agreed on the first part, unfortunately most functional languages are difficult for most developers (read: non-academics or HN readers) to grasp. As somebody who taught me ML said: "if it's difficult to write, it should be difficult to read". Perhaps this will change, but it will be a while before we have a functional language that's as mainstream as JavaScript. Most big websites have asynchronous components to address their performance bottlenecks, but the bulk of the business logic uses synchronous I/O and unfashionable languages like PHP as per the 90/10 law: http://en.wikipedia.org/wiki/Program_optimization#Bottlenecks http://en.wikipedia.org/wiki/Program_optimization#Bottleneck...