Who is Using Node.js And Why? Yammer, Bocoup, Proxlet and Yahoo | Hacker News Reader

Who is Using Node.js And Why? Yammer, Bocoup, Proxlet and Yahoo

bostinnovation.com

68 pointssliggity48 comments

"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.

Later in the same paragraph: Node.js is architected near perfectly for this situation. (And Proxlet demonstrates amazing throughput on minimal hardware to validate that).

That sounds like a good reason to me.

Can't wait to share these numbers! Blog post forthcoming in a few weeks.

Chris & I started Proxlet as a side project to scratch an itch and keep our skill-set fresh & do things in new ways. A great & rare opportunity to choose wild new tech stacks!

> exceedingly bad reason

It depends on the context. If it's a developer's side project, why not? If it's a businessperson's project that you are under contract to build, then yes, it's a bad reason.

Playing with new technology == motivation win.

The key to getting work done is to want to do it. Using technology that you want to play with makes the "wanting to do it" part easier. What follows is the project being done.

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

No it doesn't. If you see the promise and potential value of a new technology that solves a problem, you jumping aboard to play could mean the difference between a problem being solved or not.

A lot of very powerful influential projects were started by people who wanted their end users to "play" with their technology.

One good reason to choose new technology is to ride the buzz wave and build up a technology brand.

Additionally, you can exploit the python paradox to get amazing developers.

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.

Err, that is not me.

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?

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.

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

Include a link when you plug! https://github.com/JustinTulloss/zeromq.node

I was on the ipad, just getting tags was a struggle! Thanks for the link :).

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! :)

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

I found this library last night and was surprised how flipping easy it was to use, and how fast it was.

I wrote a tiny little script to test the max number of concurrent connections.

https://github.com/JustinTulloss/zeromq.node/blob/master/exa...

On my OS X machine it fails at 893 open connections. I compiled zeromq to have max_sockets = 5000 (zeromq2/src/config.hpp)

The error is:

s_849.send(msg); Too many open files rc == 0 (mailbox.cpp:374) Abort trap

What am I doing wrong? Should I just have one connection to zeromq and have all my async callbacks use it? I have a comment below that describes what I am trying to build. Thanks!

I made http://spotted.at using node.js / mongo. I used it because I wanted to see what all the hype was about and I wanted some real experience with it. But honestly I dont see what what node provides that eventmachine and twisted dont.

Have you considered using the actor model with something like akka for scala? http://akka.io/

It will give you event passing across machines in a really concise way.

Yep, that was exactly what I felt I was missing, processes/threads, ipc and I'm still not sure the memory usage/garbage collection handling would be great under stress.

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.

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.

You can get close with expressjs

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.

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).

Combining express with http://jashkenas.github.com/coffee-script/ makes it really terse.

Let's see, braces and parens but no semi-colons, almost. ;)

    data = models.getEntries()
    html = template.render('blog',data)

I may be wrong, but these two lines has to be blocking

That's the whole point, I don't care, hide that complexity from me. I can't render the page unless I have the data and I don't want to deal with callbacks, coroutines, monads, or what not, so I'll wait patiently for the data to come back.

Well, yeah, I'd like to see that too. Just like ruby or PHP, only with JavaScript syntax.

Sorry for pointing the obvious;

something like this:

  var session = require('session'),
      models = require('models'),
      template = require('template');

  function main(request,response){
    session.start(
      models.getEntries.bind(models,
        template.render.bind(template, 'blog',
          response.write.bind(response))));
  }

would be easy to put together with node.js; it's functionally equivalent to the above (though it assumes that data comes into the template.render call as the last argument(s)), and neatly avoids too much nesting.

Big discussion on that here http://news.ycombinator.com/item?id=2101210

Ryan was developing Node for certain use cases. He chose the name "Node" because it was supposed to be a small piece of a larger web app. A few nested callbacks, programs that have a few hundred lines of code and don't have complex control flows work well. Hype created a large community which is pushing beyond such narrow goals. But it will take time to come up with good DSLs or add continuations to V8. For now the best solution is to learn how to organize async code, for which I've only seen one trivial example.

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

Or the tobi project we released: https://github.com/LearnBoost/tobi

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?

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

A full list of companies: https://github.com/ry/node/wiki

I use it for my domain name generator: http://impossibility.org/

162k searches and counting :)

Oh cool, smugsex.com is available.

But seriously, good fast search.

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.

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.

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.

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.

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.)

i just built a system like this w/Erlang. we have 'post office boxes' that can receive messages, each is unique, one per connected client, and certain 'PO boxes' can subscribe to others', if they want, or to a random sampling of general message from a group of other boxes. Erlang is perfect for this. We've projected that we will max out at around 1MM connections on a 48GB, 8 core box. We're running 150K connections right now and it's using about 17% of memory and much less CPU. The key though is we already tested with multiple boxes and it works the same way. There's no refactoring when we run out of space on one box. Email me if you want some other ideas about how to set this up in Erlang.

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).

Reply on news.ycombinator.com