5 ms·

I wonder if any startups are using this tchnology. What kinds of advantages could a js stack like this have over something like ruby on rails?

smanek 17y ago
writing the same language server and client is obviously easier (fewer context shifts, smaller code base, etc). It's also asynchronous (non-blocking) so you can run thousands of connections out of a single thread (instead of RoR's silly 1-connection per process model).
- donw 17y ago
  You can multithread RoR on JRuby, but you still won't get anywhere near the performance of event-driven I/O. But, you need to think differently about how you build your app, right from the get-go.
  - dualogy 17y ago
    Does anyone know of a good write-up outlining how your thinking and building needs to change?
simonw 17y ago
I wrote about this a few months ago: http://simonwillison.net/2009/Nov/23/node/ http://simonwillison.net/2009/Nov/23/node/ - it's exciting because it's asynchronous (like Ruby's EventMachine and Python's Twisted) but makes it almost impossible to screw up your event loop. JavaScript is an excellent fit for asynchronous programming. http://transloadit.com/ http://transloadit.com/ is one startup that's using Node.js - it's particularly good for handling large file uploads since it can handle tens of thousands of them in parallel on a single server.
frankus 17y ago
Two big ones that I can think of: First, Mozilla, Apple, Google and Microsoft (and don't forget Opera) are in a high-stakes tournament to produce the fastest implementation. And three out of the four/five (CMIIR) are open source. Second, the server uses the same language as the client. This isn't a big deal yet, but I'm sure within a month or two we'll start to see some web frameworks that take advantage of this. The obvious application is validation, where constraints from the Model and Controller layers could automatically bubble up into the View layer and out to the client. But it could be more subtle. You could have a data-access layer written in JavaScript that when run on the server pulls from the database, and when run on the client pulls it over a REST interface. You could do jQuery-style DOM manipulation on the server for the initial page state, serialize it to HTML to pass to the client, and then do further manipulations on the client using the same code base. So there's a lot of code sharing across where you currently have a pretty sharp dividing line.

smanek 17y ago

writing the same language server and client is obviously easier (fewer context shifts, smaller code base, etc). It's also asynchronous (non-blocking) so you can run thousands of connections out of a single thread (instead of RoR's silly 1-connection per process model).

donw 17y ago
You can multithread RoR on JRuby, but you still won't get anywhere near the performance of event-driven I/O. But, you need to think differently about how you build your app, right from the get-go.
- dualogy 17y ago
  Does anyone know of a good write-up outlining how your thinking and building needs to change?

simonw 17y ago

I wrote about this a few months ago: http://simonwillison.net/2009/Nov/23/node/ http://simonwillison.net/2009/Nov/23/node/ - it's exciting because it's asynchronous (like Ruby's EventMachine and Python's Twisted) but makes it almost impossible to screw up your event loop. JavaScript is an excellent fit for asynchronous programming. http://transloadit.com/ http://transloadit.com/ is one startup that's using Node.js - it's particularly good for handling large file uploads since it can handle tens of thousands of them in parallel on a single server.

frankus 17y ago

Two big ones that I can think of: First, Mozilla, Apple, Google and Microsoft (and don't forget Opera) are in a high-stakes tournament to produce the fastest implementation. And three out of the four/five (CMIIR) are open source. Second, the server uses the same language as the client. This isn't a big deal yet, but I'm sure within a month or two we'll start to see some web frameworks that take advantage of this. The obvious application is validation, where constraints from the Model and Controller layers could automatically bubble up into the View layer and out to the client. But it could be more subtle. You could have a data-access layer written in JavaScript that when run on the server pulls from the database, and when run on the client pulls it over a REST interface. You could do jQuery-style DOM manipulation on the server for the initial page state, serialize it to HTML to pass to the client, and then do further manipulations on the client using the same code base. So there's a lot of code sharing across where you currently have a pretty sharp dividing line.