[hasenj]

The problem with node is it decreases your productivity tremendously.

The most important thing about the choice of programming tools is productivity. Node.JS does not promise you any productivity gains. Node sells itself as a solution to "slowness" caused by "blocking IO". What's the solution? All I/O is evented! This means you have to write everything with callbacks.

You may see some very nice libraries/tools coming out around node.js, like jade, coffeescript, and stylus. These are all nice and good, and they do increase your productivity, but, only on the client side.

If you're looking for performance and non-blocking IO, use Go, it's much better at that.

[karterk]

You may see some very nice libraries/tools coming out around node.js, like jade, coffeescript, and stylus. These are all nice and good, and they do increase your productivity, but, only on the client side.

I disagree. Firstly, CoffeScript is not confined to the client-side. Besides, there are some modules like socket.io for which you will hardly find any substitues in other eco-systems.

You're also discounting the effects of context shifts between two separate languages - one on the client side, and the other on the server side.

Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node.

[Animus7]

> The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write.

I know exactly what you mean, because that's what I thought a year ago. I was going on and on about this to everyone. Mea culpa.

Then I actually tried node and learned the functional side of JavaScript (I don't mean the semantics, which are very simple; I mean powerful LISPish design patterns). Now I don't think about callbacks anymore, because I have a functional toolkit that mostly hides them.

You say asynchronous coding makes simple algorithms annoying to write. So let's have an example. Read two files -- in parallel -- trap I/O errors and warn about them, otherwise merge and sort the files by line, write the result to a third file, and warn about I/O errors there as well. Simple enough?

My solution is 8 lines, formatted. It was very pleasant to write.

  fork(
    ['lines.txt', 'lines2.txt'].map(function(name) {
      return fs.readFile.bind(fs, name);
    }),
    check(console.warn.bind(console), function(a) {
      fs.writeFile('linesOut.txt', a.sum().split('\n').sort().join('\n'), check(console.warn.bind(console)));
    })
  )

If you've seen enough JS to deduce what the lib definitions for fork() and check() might be, then this code will seem obvious -- almost trivial. Otherwise, you will probably claim shenanigans or 'spaghetti' because it doesn't look like insert favorite programming language/framework here.

So it saddens me to hear people whining about this aspect of node -- partly because it recalls my own naivety, and partly because I know from experience that they're missing out on something great.

[ericflo]

So your point is that it's hard until you spend a year working with callback-based JavaScript, and then it becomes easy and intuitive? A year of investment may as well be an eternity for most.

[karterk]

To be fair, the OP did not exactly say that it took 1 year to learn it. I personally took less than a few days. Every framework has a learning curve.

[downx3]

That's good to know though. As it's pretty easy to waste a year learning framework X.

[hasenj]

The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write.

I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires.

> Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node.

Not having to write everything asynchronously?

I haven't actually used go, but the way goroutines communicate (and synchronize) with channels suggests to me (from what I've read/seen) that this callback spaghetti problem is non-existent in Go.

[bobz]

> I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires.

This is a sign of a not-fully-adopted paradigm shift. Like, when someone first learns a new (spoken) language, they translate it to their native language in their head.

Fluent speakers don't translate, they simply understand. Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

That said, it does take some getting used to, which is a real cost that needs to be considered when choosing Node.

[irtopiste]

> Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

A minor remark from my experience with functional programming, continuation-passing style is actually something I prefer to avoid.

[wickedchicken]

> Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

I don't understand this comment. Javascript, while having first-class functions, does not have call/cc. This is the source of complaints that Javascript encourages callback-spaghetti. As people have mentioned elsewhere, continuation-passing style is meant for compilers, not humans.

[hasenj]

Thanks! I couldn't have phrased it any better.

This is why I said it's like writing assembly.

[guelo]

It cracks me up that you haven't tried Go but you're still recommending it, is there a web framework?

Edit: Found web.go. Screw it it's a long weekend, I'll give learning Go a go.

[chrisbroadfoot]

You don't really need a web framework with go. net/http is just fine for most use cases.

[hasenj]

I haven't had a pressing need for using it, and I'm considering it as something I want to learn on the side for now.

As for frameworks, it seems the http package comes builtin with a server and a url router. Also, Google's AppEngine supports Go.

[Jare]

web.go is still not compliant with the recently released Go1. I'd recommend anyone interested in Go but not in a hurry to wait a month or two until the Go1 dust settles.

[pepve]

> The problem with node is it decreases your productivity tremendously.

People say this over and over, complaining about nested callbacks and what not. I can tell you from experience that it is not true. I've been working on a Node application for a few weeks now. It is our first server side Javascript endeavour as a company, I had only tinkered with it in my own time before this. And the experience is pretty good. Writing in a more functional style makes me more productive and makes quite some problems more straightforward to describe (implement).

[VeejayRampay]

If "This is a revolution" hadn't been patented by Apple years ago, I'd be using it right now. Hell, Node invented / brought us:

- The Reactor Pattern, a never-been-before paradigm.

- V8 and its mind-blowing speed.

- Evented I/O, a game changer.

- It also allows you to program all that with the best language known to man, Javascript, ON - THE - EFFIN - SERVER (zomg).

Hats off to the Node community though, they're getting good at emulating Rails' PR tactics of buzzwords, fluff and overblown hype.

[Peaker]

Or Haskell, Erlang or various other languages that have better solutions for non-blocking I/O.

[trimbo]

Or C, C++, Java, Python or Ruby.

Every language has solutions for non-blocking I/O, even the boring ones.

[Peaker]

C doesn't have a good solution for non-blocking IO. Managing callbacks and their lexical scopes manually is quite painstaking.

User-level threads are non-standard, and ordinary threads are too heavy. All forms of threads lose much of C's benefit due to the relatively heavy stack allocation per thread.

[mcav]

Red herring. Node can increase productivity as well. It's all about your requirements and workflow.

[ryan_f]

I very much agree on the drop in productivity. I was just contracted to help with a Node project and just getting up to speed has been difficult. This is not all node's fault since the callbacks and such could have been handled differently.

The better examples will be in a few years when programmers have more experience with Node and the projects' code reflect that.

I won't be returning back to Node after the project though because it reminds me of earlier days writing XML with Spring.