4 ms·

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

by olegp 16y 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 16y 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 16y 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 16y 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 16y 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...
      - sausagefeet 16y ago
        Brings me back to my original comment: > 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. Someday....someday...

by olegp 16y ago

sausagefeet 16y 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 16y 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 16y 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 16y 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...
    - sausagefeet 16y ago
      Brings me back to my original comment: > 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. Someday....someday...