Live data from Hacker News

Experimenting with Node.js

jeffkreeftmeijer.com

31–40 of 88 posts

Re: Experimenting with Node.js

#31

I'm wondering if Javascript will start being heavily used server-side? Would it be wise to start learning JS and how to use Node.js or is it absolutely not suitable for production use?

Regardless of the popularity of Javascript on the server-side, if you're writing a web-based application, then your architecture will benefit from:

1. Shared code between client and server.

2. Specialization in one language.

V8 and Node are at least a very good combination for server-side Javascript.

Re: "is it absolutely not suitable for production use?"

Node in alpha state is already more production ready than many "production ready" tools.

Re: Experimenting with Node.js

#32
post #6

It would be interesting to hear from the author how the server is handling HackerNews traffic

Hi, author here. While building this thing, the Node server had the tendency to drop out. I'm monitoring it with God ( http://god.rubyforge.org/ ) now, so it restarts whenever anything goes wrong. I'm genuinely impressed by how it's holding out now. :)

Could you elaborate on this at all? What kind of traffic are you getting (max concurrent requests handled perhaps)? Any idea why Node dropped out?

Re: Experimenting with Node.js

#33
post #28

While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…

I definitely agree when it comes to the code scalability of something like Node.js (although, I haven't built gargantuan javascript applications before, but am going to assume that it's not necessarily a pleasant experience).

Diesel looks great. When looking into alternatives in Erlang/Haskell/Scala, or XMPP/BOSH, either it's not easy to find quick how-to examples, or I'm looking in the wrong places. Any fingers in the right direction would be welcome.

Re: Experimenting with Node.js

#34
post #28

While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…

Coroutines bring their own headaches and baggage. To say that callbacks are behind "state of the art" is a little misplaced,; its just a different way of doing things. With coroutines you have to worry about IO all over the place and have to make your functions coroutine safe and Ryan Dahl, the node.js creator, will argue with you all day long about coroutines vs callbacks.

I do agree, though, that developers should not ignore other ways of doing things, just don't discredit the callback way of doing things as it can be useful.

Re: Experimenting with Node.js

#35
post #28

While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…

Whether you like the model or not, the fact is that JavaScript with it's callback/event based model is what browsers understand. And the internet isn't going anywhere anytime soon.

Node is an attempt at using this successful model on the server too where is can solve massive scalability issues using the exact paradigm front-end devs already know.

Also while there are many technical ways to make code look blocking, but really be running other events under the hood, it's this exact implicit running of "other stuff" that makes writing threaded code so hard. You have to assume that things can change between every function call because you don't know if somewhere down the chain it's doing pseudo-blocking.

JavaScript's model is simple, you provide callbacks and you know exactly at what boundaries things can happen asynchronously.

In summary, node is one way of doing it. We think it's a better model and it's proven itself in the browser. If you think another model is better, than by all means go for it!

Let the leapfrogging begin ;)

Re: Experimenting with Node.js

#37
post #28

While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…

Programmer-mentality is somewhat different from other mentalities, but it's still bound to simplicity laws.

The technologies you are describing were already there, but it's not just a problem of technology, feature set or execution power. It's also a matter of simplicity.

Node.js is working because it gives so much power with a very simple approach. And by approach I mean also how much is simple to understand it and start producing something useful.

That's exactly the reason why we use more abstract languages, and that's the reason why Node.js is getting a lot of attention recently. If you don't know any language, do you think it's simpler to start with Erlang or Haskell, or with JavaScript? I don't have any proof, but my bet is surely on JavaScript. :)

And even the most obvious things are important. Because maybe a uber-developer can ignore the small details, but most of the programmers aren't uber, they just want to develop easily and happily. Every little detail matters. Just see how many steps you need to install Erlang on your machine, and how many steps you need to do the same with node. It seems stupid, I know. But when you sum every detail... it matters. :)

At the same time, this gives power to the uber-programmers out there to bring on more cutting-edge solutions when they need them, and feed the "simple" level with their discoveries and experience, making the language and frameworks evolve.

If you're right, one day we are going to have simple coroutines - in the complex, environmental and social sense expressed above. Maybe even in Node.js, because in the end JavaScript 1.7 afaik supports yield and V8 could implement it in the future. ;)

Re: Experimenting with Node.js

#38
post #28

While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…

Whether you like the model or not, the fact is that JavaScript with it's callback/event based model is what browsers understand. And the internet isn't going anywhere anytime soon. Node is an attempt at using this successful model on the server too where is can solve massive scalability issues using the exact paradigm front-end devs already know. Also while there are many technical ways to make code look blocking, bu…

I agree this is currently the best way of using similar models on both the client and server side. It'll be interesting to see if anything changes, on either side or both, when webworkers (browser threads) get more widespread support. At least it's likely that more direct comparisons of the programming models will be possible in the future.

Re: Experimenting with Node.js

#39
post #33
post #28

While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…

I definitely agree when it comes to the code scalability of something like Node.js (although, I haven't built gargantuan javascript applications before, but am going to assume that it's not necessarily a pleasant experience). Diesel looks great. When looking into alternatives in Erlang/Haskell/Scala, or XMPP/BOSH, either it's not easy to find quick how-to examples, or I'm looking in the wrong places. Any fingers in t…

The Glasgow Haskell Compiler (GHC) uses async I/O to implement all I/O actions (e.g. printing to stdout, opening a socket) and it's completely invisible to the programmer. Bryan O'Sullivan and I have rewritten the implementation used in GHC and GHC 6.14 will offer much better scalability (using epoll/kqueue) than previous version.

Just fork of a thread per connection (using forkIO) and just call normal I/O actions. The implementation will multiplex those forkIO threads onto a single OS thread that calls epoll/kqueue.

Post reply on HN