
The love and hate of Node.js - zinxq
http://mailinator.blogspot.com/2012/05/love-and-hate-of-nodejs.html
======
karterk
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.

~~~
wmf
_For a lot of people - Node allows them to do a lot of things that was
previously non-trivial in Ruby or Python land. ...for certain classes of
problems, neither event machine nor twisted come close to Node and its
ecosystem today._

This is the kind of stuff that causes the backlash. The JVM doesn't exist?
Erlang doesn't exist? Why did the Node people insist on building a new
ecosystem from scratch? Wouldn't it have been easier to build on something
that was already mostly working (and already supported multicore)?

~~~
chc
Erlang may as well not exist for the vast majority of developers. I like
Erlang, but a lot of people don't get it, and even more are completely unaware
that it exists. Meanwhile, JavaScript is already one of the biggest languages
on the Web. This is actually one of Node.js's intended strengths.

The JVM is really mature, but its primary language is one many people hate, so
people would complain about choice of platform even if they had gone that way.
You may as well ask why Ruby on Rails wasn't Java on Rails. The answer is that
37signals didn't like Java.

And V8 and JavaScript already existed when Node was created, so they were
building in an existing ecosystem. Again, JavaScript was already one of the
dominant languages on the Web. That's a big argument in its favor.

To my understanding, JavaScript had one more advantage that put it over the
top: what _didn't_ exist in its ecosystem — namely, a culture of synchronous
development. This meant Node wasn't fighting against the idiomatic way to do
things. JavaScript was already highly async, and since this was the whole idea
behind Node, it made JavaScript a less-bad fit than most other languages.
Other languages were considered, but the fact that libraries for those
languages were largely synchronous was viewed as a downside.

~~~
anuraj
Since when did people do not like Java? And still it is the most widely used
computer language? And how many people like Ruby, Python by the way? Hype is
indeed stranger than reality.

You should choose languages and platforms that fit the task at hand. Every
language is as good as the programmer who wields it as long as it suits the
purpose. Hating a language is hardly the way to get things done. After
learning and working on dozens of languages I am very language agnostic - a
new language takes at most a week to get to moderate proficiency now. Make
systems that work rather than bitching about your new pantyhose.

~~~
chc
Java is the most widely used computer language because it's the lingua franca
of the enterprise. That doesn't reflect the programming community's love — it
reflects the approval of big business executives. Some programmers genuinely
love Java, but I'm pretty sure it's a much smaller number. In the startup
scene, where technical founders pick the stack, Ruby is actually more widely
used. Take a look at the HN Jobs category (linked at the top of the page) and
count the number of Ruby web dev listings, then count the Java web dev
listings.

(Cheat sheet in case you didn't feel like counting: There are zero listings
for server-side Java. The only Java listings are for Android.)

You can argue that it _shouldn't_ be this way, but that is how it is. A lot of
people hate Java. Rails' whole initial marketing campaign was essentially
"Java sucks — we do everything opposite of them."

~~~
anuraj
And you think HN is the horizon of entire programming world? Hope that is a
self fulfilling prophecy. If you believe HN, Ruby is taking over the world -
but in reality, Ruby use is going down
([http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)).
If you really want to know which language is gaining popularity fast - it is a
pretty old language called Objective-C! Recheck the reality distortion field.

And about love - I have a family to love - programming languages are tools -
hardly objects to love or hate.

~~~
emil0r
I would believe it on the basis that every programmer I've talked to, from a
couple of years after Java was introduced, until today, didn't really like
Java. Things became very complex very fast for the language that gave birth to
FactoryFactoryPattern.

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

~~~
munificent
> never seem to be able to point to any company (in the current generation)
> that achieved massive success by starting in a fast language?

Didn't Google start in C++?

~~~
kemiller
Google is not the current generation. In 1998, hardware was not fast enough to
make dynamic languages feasible.

~~~
wmf
Weren't a lot of Web sites written in Perl in 1998? And there was the
AOLServer/Tcl crowd, but we won't speak of that.

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

~~~
FuzzyDunlop
I think question that could be asked is, how long can any one tool, used
correctly, defer the need to scale?

For some services, Node.js may give you more time and capacity. For others,
Ruby or Python might.

You might need a static website, and you can develop it and push out the
'compiled' HTML to your server. For all the scaley goodness Node.js or
whatever may seem to offer, for that purpose it'd _never_ compete with NginX
running a static server with appropriate caching.

Up until that point becomes visible on the horizon, you're just wasting time
(and money) on a problem you don't or, if you're unlucky, might never have.

~~~
wmf
_how long can any one tool, used correctly, defer the need to scale?_

Probably longer if the tool automatically supports multiple cores.

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

~~~
btipling
The stack of callbacks piling up is definitely not a great feature of node.js
code. You can mitigate it by using declared functions instead of anonymous
functions but that also becomes burdensome when all your callback function
does is call something else that also requires a callback.

This will be an interesting problem for node developers to solve. I like the
Go approach of using channels. Twisted uses deferreds and inline yields
depending on your preference. There are some libraries out there that people
have written for node.js that also help.

~~~
untog
tame.js solves this to an extent by allowing await and defer calls in your JS
code. Not native, of course.

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

~~~
dc-tech-fan
> The only technical problem where I've seen node be a unique solution is
> dealing with third party apis concurrently.

Use a library like Async, it makes this really easy.

<https://github.com/caolan/async>

(assume redis, mongo, facebook, and callback are all functions)

async.parallel([ redis, mongo, facebook], callback);

callback is called when all of the others are complete. If you have
dependencies, like facebook needs the output of redis and mongo then use
async.auto which will automatically run things in parallel and in the order
you need them.

~~~
mcs
Yes, what I was saying is that Node makes that really simple, and PHP, Python,
Ruby, etc don't. That's more of a side effect of having everything be
asynchronous though.

~~~
anonymoushn
This is really simple in Python using greenlet, stackless, or gevent.

~~~
falcolas
Or threads. Simple, non-shared state threads are not that difficult to write,
and for IO bound operations, they are not terribly inefficient.

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

~~~
wtracy
It seems odd to me that we had Javascript as pretty much the default server-
side scripting language back in the Netscape days, then JS on the server
pretty much disappeared as IIS and Apache took over, and now with Node
Javascript on the server is "new".

~~~
apaprocki
We adopted server-side Javascript at Bloomberg to build all of the
applications for the terminal starting in 2006 using a custom environment
built around Spidermonkey. So Node isn't that new a concept around here :)

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

~~~
ndcrandall
I initially had the worry that I had no idea what I was doing with Node.js and
MongoDB. Honestly I still don't know what I'm doing. I wanted to learn these
technologies eventually so I figured why not fumble through the process of
learning and failing now so I'll be better with later project?

Keep in mind that my project isn't time or language sensitive. It's a practice
project that could go somewhere with more work, but I can take all the time I
need. I highly recommend a project like this if you want to learn these or any
other new technology, otherwise you can keep with what you're familiar with.

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

~~~
happycube
This makes the "READ SICP" meme rather ironic ;)

I've dabbled in node a bit and have an odd idea that Javascript is much like
Python with C syntax and a bit of quirkiness. I've got a ~400 line program
that parses a Debian packages file and lays out build dependencies - sadly I
hadn't learned of germinate at the time.

And having to change languages to scale the website further because you've
Made It can be a _good_ problem to have...

~~~
neilk
There is a subset of JavaScript that is Python-like with C-syntax. But at some
point you're going to have to abandon that analogy and learn more idiomatic
ways of working in JS.

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

~~~
dochtman
Knowing (in Python, for example) when to use a list, a tuple, a dict, a set or
a deque makes a rather big difference, and is a skill I probably use almost
every day at work.

See also this tweet from last night for a real-world application:

<https://twitter.com/#!/djco/status/202490834472542210>

~~~
jakejake
Interesting. Thanks for that. Curious what kind of work that is - do you have
real-time critical apps that you have to tweak milliseconds or watch RAM
consumption carefully?

I sometimes feel like I could be lazy, but I just never seem to need to deal
with that type of tuning due to the nature of my work which is business apps.
Don't get me wrong, I do deal with performance tuning - but never at the data
structure or algorithm level. I would say I spend time architecting to
preventing huge data structures to begin with. Also SQL tuning, interface
design and things that I have to deal with. The low-level stuff like sorting
algorithms are just built into whatever language I'm using and they don't seem
to be a bottleneck.

~~~
beagle3
> I just never seem to need to deal with that type of tuning due to the nature
> of my work which is business apps.

and

> Also SQL tuning

Are at odds with each other. Although the terminology is different, you _are_
in fact doing it if your SQL tuning includes things like adding an index and
selecting the right kind of index for your workload (every database has
different names, but the different kinds usually include hash, btree, and a
couple of others).

~~~
jakejake
I suppose that is true. Indexing is something I deal with but I guess I don't
really think much about the underlying storage mechanics.

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

~~~
bphogan
I would love to see a concrete, documented example of this code sharing
between the server-side and client-side. I'm not interested in "context
switching" but I am extremely interested in how to actually share code between
the two environments; I believe this is part of the key to creating more
accessible content.

Could you point me to something I could look at further?

~~~
iambot
You should check out the Browserify module by @substack. It packages even
native nodejs code to work in the browser. Seriously just check it out, I
can't do it justice: <https://github.com/substack/node-browserify>

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

------
rmATinnovafy
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?

------
Locke1689
Node.js people: do you actually _like_ Javascript?

~~~
edtechdev
Every language sucks to various degrees, but for what it's worth there are
over 100 alternative languages that compile to javascript:
[https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS)

~~~
Locke1689
That's true, but not what I was asking. I can write a compiler from any
language to any other language, so I'm not asking if you like other languages,
I'm asking if you like Javascript.

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

------
derekorgan
That article could easily be half as long

~~~
IsaacSchlueter
So could this comment.

~~~
mansoor-s
yours or his?

------
mcginleyr1
vibed.org

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

------
hackermom
This makes me think of all the people who insist on using jQuery for _exactly
everything_.

