

Who is Using Node.js And Why? Yammer, Bocoup, Proxlet and Yahoo - sliggity
http://bostinnovation.com/2011/01/15/who-is-using-node-js-and-why-yammer-bocoup-proxlet-and-yahoo/

======
ericflo
"We chose node.js for a few reasons. The first was, we simply wanted to play
with a new technology."

Well at least he's honest, but this seems like an exceedingly bad reason to
choose a technology stack.

~~~
finkle12
FYI, ericflo maintains a twitter account whose sole purpose is to covertly
mock node.js

<http://twitter.com/nodecore>

It's good to see these Django guys having to use questionable tactics to
challenge node.js.

~~~
huxley
my impression of Eric (I don't know him, I've only talked briefly at a couple
of conferences) is that if he disagreed with something or thought it had
problems, he'd tell you to your face.

I sat in on his speech "Why Django Sucks, and How We Can Fix It" at Djangocon
last year:

<http://djangocon.blip.tv/file/4112452/>

And he gave a lot of tough love to Django in front of most of the
establishment and people who are hardcore Djangonauts.

Speaking of questionable tactics, why create a HN account just for the express
purpose of attacking him?

------
liuliu
I am interested to see some solutions with Node.js. From my experience (I
built a lightweight protocol for multiplayer game with Node.js), it is super
easy to program with Node.js and it just works. But the down-side is, you
don't really get scalability. Node.js is great in one-process environment, and
you don't have any methods for inter-process communication (you can do it
based on you tiny protocol, but really, that is not what you want as "inter-
process communication" means). Node.js is fast for prototyping, but I am eager
to try out Erlang or Go before deployed the current version in production.

~~~
jmtulloss
<shameless plug> try zeromq.node for your interprocess communication needs!
</shameless plug>

~~~
ehsanul
This is actually just what I'm starting to use for inter-process communication
with node.js, for a realtime MMO game. I'm dividing the (2d) world into
squares, each handled by a node.js process which will each be responsible for
all the game logic and computations within that square, with some extra logic
for handling objects that span two or more adjacent squares.

All IPC goes through a single (per machine) routing server which handles
routing messages to the various node.js processes, which may or may not be on
the same physical server. Only communications are for objects around the edges
of the squares, for collision detection etc. and for transferring websocket
connections to another node.js process.

After a lot of thought, that seems to me to be the best way to work out a
scalable solution. Have yet to see if it'll work well, but I see no reason why
it shouldn't. Now if only I had enough users to test it..

Oh, and thanks for the great 0MQ library! :)

~~~
jmtulloss
That's awesome. Let me know if you have any problems!

------
x0ner
I am using Nodejs as an update monitor for a community game. When one person
does something, I need to update everyone else. I initially did this with ajax
polling back to the server for any updates. While this worked, it seemed slow.
Now all I have is a simple nodejs server that accepts web socket connections,
and passes information to all connections In total it was about 10 lines of
code and it is pretty much real-time.

------
Kilimanjaro
For a ssjs implementation to win my heart this is how I would like to code my
apps:

    
    
      require session,models,template
    
      function main(request,response){
        session.start()
        data = models.getEntries()
        html = template.render('blog',data)
        response.write(html)
      }
    

Can not be simpler, hide all complexities from the coder so he can concentrate
on building apps, not fighting with code.

~~~
aaronblohowiak
You can get close with expressjs

~~~
Kilimanjaro
I like it, it can be humanized a bit more like:

    
    
      var app = express.Application(); // let me create apps, not servers 
      app.get('/', app.do('index',req,res));
      app.run();  // set port in config.js
    

I'll keep an eye on express.

~~~
foenix
I can give express a thumbs up. I came from a python-flask environment, and
express provided a way for me to quickly get the gist of javascript object-
models and message passing.

(I'm not a CS guy, I just wanted to finish a digital art project involving
buses and geolocation).

------
sorenbs
Every web developer should check out node.js because of this test framework if
nothing else <http://zombie.labnotes.org/>

~~~
rafaelc
Or the tobi project we released: <https://github.com/LearnBoost/tobi>

------
budwin
I've used Node.js to power a little "social doodling" pet project I made:
<http://letsdrawit.com> and I find it a useful way to think about concurrency
because there are certain types of race conditions you don't have to consider
(for example any critical regions in memory)

It's extremely useful for the "evented" part, but I get the sensation of using
node for hosting webpages might be overkill and not the appropriate tool.
Instead, I've got the node.js core proxied behind an nginx server hosting
static files and ruby rack (for when dynamic content is necessary).

Does anyone see an advantage of using Node to host templated webpages?

------
calebelston
We use Node at Yobongo, and love it. Fantastic for our realtime communication
infrastructure.

------
rafaelc
A full list of companies: <https://github.com/ry/node/wiki>

------
chaosmachine
I use it for my domain name generator: <http://impossibility.org/>

162k searches and counting :)

~~~
mise
Oh cool, smugsex.com is available.

But seriously, good fast search.

------
SoftwareMaven
I'm sorely tempted to use node.js for a project I'm starting now, but my needs
require 100% http/s support and its latest release just rebuilt its http/s
support.

Since a large portion of our solution is sitting on the browser in extensions,
it would be nice to reduce our language footprint by one. If it were a year
later, I have no doubt I would.

~~~
jamwt
I wouldn't try to shoehorn SSL/TLS in as a requirement of whatever
language/framework you do network stuff in--it's unlikely to be a great
implementation, anyway. Just put nginx or stunnel in front of your service and
go about your business. Both are fantastic proxies for high-load services. We
use stunnel -> haproxy -> diesel/python at Bump... and we have a _lot_ of
users.

------
gourneau
I would like to write a TCP server with node.js can accept 1000s of client
connection. Each client would need to publish about 1 timestamp a second to a
queue that is unique for the client. That same client would also need to be
able to subscribe to one other clients queue, and have that data pushed to it
when it get published. The data would not need to persist at all, if there is
not a subscriber who wants it discard it.

Any tips on how I should go about doing this? I would like some type of
solution that could scale if I put a load balancer in front of it. I have been
thinking about using some type of PubSub queue, maybe zeromq, maybe a XMPP
server.

~~~
jerf
If you want to load balance this and you need something custom, you're going
to be a lot better off starting with Erlang. In Erlang, a PID reference
(process ID) can transparently be a reference to a process on another machine
in the cluster, so sending a message to the target queue is some variant on
Message ! Pid regardless of which machine the queue is actually living on.
MNesia can be used to keep track of what PID is what and that transparently
replicates around without you having to write the logic. In Node.js it's going
to be less transparent and unless there's a library that does all this for
you, you're still going to be putting the solution together when you could
have been done in Erlang, even if you're an expert in JS and know nothing
about Erlang.

One of the queuing libraries might just work out of the box, though. But at
least at the moment I would actually consider Node.js counterindicated for
this task, unless you can be rigidly sure that messages never have to cross
process boundaries.

~~~
skeltoac
Agreed. This sounds like an ideal learning project for Erlang.

Open a few tabs of erlang.org/doc/, grab a book (Joe Armstrong's Pragmatic
book is a good one) and get started.

You'll be surprised how easily you made your first Erlang production system.
(If this makes you feel guilty and you need to self-flagellate afterwards you
can try packaging your app into a release.)

------
jimmyjazz14
We have used Node.js at my company to build a few small web apps. The decision
to try node.js was most likely based on the fact that everyone in the office
knows javascript already. The experience has been a little love/hate (at least
for me).

Personally, I like the idea of asynchronous IO for writing server applications
but I would probably go with a slightly more robust language (for me it would
be Haskell).

