The love and hate of Node.js

Node seems to evoke strong responses from people. As someone who has a couple of side projects running on Node in production, and also as someone who considers himself fairly language/platform agnostic - I will say this:

For a lot of people - Node allows them to do a lot of things that was previously non-trivial in Ruby or Python land. From comet based applications to using socket.io for real-time notifications. It's not that these things can't be done in other platforms. There have been plenty of Java COMET solutions. Heck, 3 years back I wrote my own multiplayer strategy game in Erlang/OTP. However today, if I were to write that game - I will do that in Node. Reactor pattern is nothing new - but if you work with Node you will realize that for certain classes of problems, neither event machine nor twisted come close to Node and its ecosystem today.

Yes, C++ servers could be faster and JS can be a terrible language to work with. But a lot of us don't care - we want to get work done and we use Node for stuff that it's good at. There are always going to be people using it for everything - but every community has its set of zealots. Someone said the other day that he/she uses Haskell for prototyping.

Why is it that folks who point out that Facebook, Twitter, and Square all had to move to a "fast" language never seem to be able to point to any company (in the current generation) that achieved massive success by starting in a fast language? Having to transition to another language once you achieve success is a pretty solvable problem in comparison to actually creating a product successful enough that platform matters.

For that matter, neither Square nor Twitter have exactly "migrated" (I don't know about Facebook). They optimized hotspots -- a long and storied tradition. Even C programmers drop down into assembly.

Use different pieces for what they're best at.

This article is spot on. We'd all like to have magical properties like speed and scale instantly conferred on our code merely by using the right tool. The fact of the matter is that both of those properties require consistent correct decisions at the application level to be achieved.

Scale, for that matter has been totally conflated with speed by many in the Node.js. A single-core reactor is not inherently scale-out. You can, of course, build a scale out app on node.js, but there's nothing about using node (or any other tool) that magically makes your app scaleable.

The reason I don't want to write much in node.js is simply I don't like callbacks. It's an inversion of control, and not a necessary one. One can easily invert control back to direct style by using futures/promises. There are even node.js extensions that do various conversions back to direct style, but since the language doesn't endorse any particular one you can't use them across a whole app (unless you write everything yourself).

I run a production node.js app and my experience hasn't been bad. My cofounder and I spent more time in the beginning (not much more time, mind you) learning how to deal with multiple outstanding async calls, a good application structure for express, etc. Now it's just as fast for us to go in and add a new API call that does this one query in node as it would be in another system.

The only technical problem I've seen that node is an easier solution is dealing with third party apis concurrently. It wouldn't be very straightforward to have a redis query, a mongo query, a facebook query, and a sendgrid query all open at the same time and managing the results when they all come in (and keeping program flow maintainable) in PHP, Python, Ruby, etc. Probably not a common problem or desired feature, though.

We're 100% Node on heroku with a custom buildpack, using a hosted Mongo service, some Node written cron jobs (which were pretty interesting to write), and redis and we serve 5 digits worth of hits every day at least, and I'm more than happy with performance. I never once look back and regret the decision to use node. I don't necessarily care about sharing code, having frontend developers do everything, etc like some node guys throw around naively, but I am looking forward to bringing somebody on that can grasp adding in a new API route, throw in a Mongoose find, and render a template with some variables. We have EJS templates serverside and clientside for that reason, and that could just as easily be done in PHP or Python.

However, I am enjoying working with node, the node community, and the interesting modules and stuff that are being released. I will say that there's a good bit more active "lets hack this up into a module and open source it over the weekend" kind of people in node than others at the moment.

I think part of the "problem" is that Node represents two different "radical" ideas together: first, using JavaScript on the server, and second, using evented/runloop programming. As such, the discussions become kind of confused. For example, not being someone too excited about Node myself, I still found this particular article kind of strange: I see no issue at all with using JavaScript on the server and in fact think that's the best part about Node. I am on the end of the spectrum where I don't even understand the point of discussing what language "deserves" to be on the server.

However, due to the hyper success of Node, we were left in this strange place where Node became the defacto JavaScript platform, and you can't really use JavaScript on the server/desktop without it (you can I guess, but don't expect anyone else to be able to use your code easily). As such, I think part of the reason you have people who want to use Node "for everything", is that a lot of them just actually want to use JavaScript "for everything", which is a less contentious issue in my opinion. In a world where you had "JavaScript on the server", and the optional "Node library" where you could do evented programming, vs. a different Rail/synchronous style library, you'd have something that looks a lot more like the other programming worlds.

I for example want to use JavaScript as my ideal scripting environment on the desktop, which is not that well suited for the asynchronous model of Node (just reading a bunch of files, operating on them, and then spitting out a new file can be kind of tedious with this model -- I'm not really waiting on anything or trying to hold a million open connections simultaneously). JavaScript itself I think competes just fine against Python and Ruby for these tasks, but again we can't really compare them in this abstract way, we have to compare JavaScript in the particular way it exists in Node, which brings along a lot of opinionated asynchronous APIs.

I was going to use Node.js for a site I was building, but then I stepped back and realised going with Node.js (and MongoDB) meant I had absolutely no idea what I was doing.

I stepped back and used Python with Flask and SQLite as I had done before. There was nothing wrong with what I was familiar with. (An added bonus was I could actually reuse code from an older project using a similar architecture)

I also consider language religion to be a red flag. The folks who wrote SICP said it better than I " Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn"

This is a tangential point in the article but he mentions interviewing people and asking questions about arrays vs linked lists. I was wondering whether a lot of you are working on stuff that involves deep understanding of data structures, sorting algorithms, etc? I seem to see it in a lot of interview questions. Is that just a good topic to separate those with formal education from self-taught people, or are a lot of you really spending a lot of time working on those types of problems?

(To add to that, I should say that I did study data structures in college and know the answers to these questions, but I just personally never have to deal with that level of the code in my work.)

The article misses the biggest advantage: writing browser & server code in the same language is a huge win. Libraries can be shared. It is easy to move functionality back and forth. You can have one implementation of input validation logic instead of two.

The author is not arguing whether there can be a server-side framework using a dynamic language like Javascript. Obviously there can, just like there is RoR, Django and others. His point is that the Node community came to such a point where they think Node is a silver bullet that can solve scalability issues just by itself.

My best guess is that Node gets such reaction due to the same reason Javascript does.

Anytime I stumble with a Node or Js or Rails guy the same question pops to mind. Why limit myself to one language or framework?

Node.js people: do you actually like Javascript?

I think a big part of this is just status quo bias. Also many programmers are suspicious of things that are convenient.

That article could easily be half as long

vibed.org

It doesn't strike me as ridiculous to make a server-side Javascript framework. I'm not interested in Node because from code examples I've seen, its programming model seems to make doing even simple things quite complex. I really like Javascript, though.

This makes me think of all the people who insist on using jQuery for exactly everything.