We have some Node.js code (not yet in production) for http://lanyrd.com/ for interacting with the Twitter streaming API.

My personal philosophy with Node.js is to use it for small, standalone network servers that complement the rest of my stack - basically anything that needs to handle large amounts of I/O. Everything I've written with Node.js so far has been just a few hundred lines of code.

So for templating, database interaction and so on I'll keep using Django. I'll use Node for stuff like comet/WebSocket pubsub services, handling file uploads, rate limiting API proxies, webhook dispatching, interacting with slow or streaming external web APIs, etc.

GitHub are using Node in this way at the moment: https://github.com/blog/678-meet-nodeload-the-new-download-s...

The thing I like about node.js is that you can now pretty much write your entire web app in JS, both front end and back end. This really helps with the context switches that happens in larger projects. With mongoDB, you can pretty much use JSON throughout the application stack.

I've used it on a few mid sized personal projects and have to say I generally regret the decision. The last project I worked on in node was great at first but as I slowly started adding more features the code became rather unmaintainable; IO heavy parts became a mess of deeply nested callbacks and compared to say python the choices of third party libraries are limited and often of poor quality. At the end of the day I personally rather use a tool that does not force me to compromise on code quality.

Many of my problems with node are simply a matter of taste and I'm not trying to discourage the use of Node.js; its pretty good for quick and dirty web services but, in my personal experience it has not been worth the trouble for large projects.

Quora thread for which startups in SV are using node: http://www.quora.com/Which-startups-in-San-Francisco-Bay-Are...

Quora thread for which companies are using node: http://www.quora.com/Node-js/What-companies-are-using-Node-j...

Yep, we're using it to run Readability server-side --> http://preona.net/2010/11/ever-wanted-arc90s-readability-as-...

Some things are a bit less mature than one might desire, but all in all it's a pretty brilliant piece of technology and I find myself using it more and more.

Gilt Group uses Node.js along with Hummingbird to do real-time traffic analysis/monitoring.

http://news.ycombinator.com/item?id=1335425

I'm using node (with expressjs) as part of my stack. It interacts with Mongodb and provides a public HTTP api.

I wouldn't use it as my main webserver, but it's really nice for this part of it.

We are at SelfServeApps and it's awesome. Not only is ES5 a decent language but our stack is incredibly simple (great when you don't have a sysadmin). We install node on a frontend server and run our app, that's it. It talks to our backend (Riak) over http.

edit: We have a thick client using Cappuccino and we talk to our Node web service using JSON. The only templating on the server is for a few HTML emails, password reset page, and the email verification landing page.

The guys at http://stackvm.com/ use node.js.

I was disappointed to learn javascript does not support tail recursion. Kind of makes it a 2nd class functional language.

https://github.com/ry/node/wiki < there is a good list of companies using node.js in production.

Is there a reason you dislike javascript?

I think there's likely a ton of people using it, since it's so fashionable right now.

Our entire stack is built on javascript / node.js (aside from Ubuntu and some CouchDB)

http://www.nodejitsu.com

http://github.com/nodejitsu

AppJet is being hosted at http://apps.jgate.de/.

We also launched Erbix a few days ago: http://www.erbix.com

http://apps.ycombinator.com/item?id=1938066

i'm not sure how these guys did it, but one could do a similar setup. one of the issues to overcome is availability of ports. since most apps will listen on port 80, you can use the HTTP Host header to virtual host instances. a reverse proxy can be set up at nnn.jsapp.us, look up the nnn and get an IP:port of which (internal) node instance to pass the request to. you could internally use UNIX domain sockets so there wouldn't be a need to worry about TCP sockets, but your frontend proxy needs to be smart about this.

thus nnn.jsapp.us can be mapped to a single IP address. things get more tricky if you allow people to host arbitrary TCP servers that aren't reverse-proxy friendly. the jsapp.us implementation seems to ignore a port argument to listen(), which seems reasonable.

the jsapp.us implementation seems to be able to keep multiple node instances running. obviously, if more and more people start hitting the server with their apps, this could lead to resource starvation. they probably have a clever way of not keeping the node instances sitting idle. if a particular nnn.jsapp.us host exists and the node instance isn't up, start it on the first "cold" request to that host. this allows the service to keep only those instances up and running that have had recent requests. or maybe they shut down a user's instances only when they log out or close the editor page?

that's my take on it. someone (maybe the jsapp.us guys?) should put together an all-in-one node.js hosting service that has a nice web-based editor based on Bespin or Cloud9 IDE and integrates node-inspector for an awesome remote debugging experience.

At HP Palm, we're using Bespin as the editor for our Ares code environment for building webOS apps. See http://ares.palm.com/Ares/

It works in Safari, but that's because the Safari command for bookmarks is Option+Command+B

works in chrome too

works in firefox