
Node.js has jumped the shark - bascule
http://www.unlimitednovelty.com/2011/10/nodejs-has-jumped-shark.html
======
Spyro7
Am I the only one that considers all of this ranting about Nodejs to be a
little bit strange?

I would have never expected a post that was obviously a troll to prompt this
much of a reaction on both sides of an issue. That so many of these rants and
counter rants made it to the front page of Hacker News is somewhat
discouraging.

I have been playing around with node for a few months, and I have tried to
stay completely out of this "conversation". With that said, I would like to
contribute just a few points:

Bad programmers will be bad programmers regardless of the tools that they use.
If they use node and fail to write code that is completely non-blocking, then
that is what we call a teachable moment. There is no magic button, all
technologies have downsides and tradeoffs.

People keep talking about how nodejs is not good for computationally intensive
tasks, but v8 is not a slow environment. Am I the only one that puts
computationally intensive tasks into a queue to be taken care of by a pool of
seperate processes? I am only just getting into web programming, and it seemed
fairly obvious to me that you would not put something like that into your main
event loop.

Also, if you find that you must put something computationally intensive in
your main event loop, then you should use something like node-proxy or nginx
to proxy those requests to a number of "nodes".

Over and over again, I have seen that people complain that node is not a good
multithreaded environment. Well, yes... That is the tradeoff of using
something that is closely tied to the concept of the event loop.

If you are using node because you feel comfortable with threads and you need
threads, then you are making a serious mistake. If you are a new programmer
and you are using node because someone told you that it is cool, then you are
making a serious mistake. If you are using node because you have a problem
that can be solved or addressed with an event loop and you understand the
tradeoffs inherent in this approach, then you are doing the right thing.

To use nodejs effectively will often require rethinking your approach to fit
the tool that you are using.

~~~
wyuenho
I think this post is about ridiculing the childish behavior of the Node.js
fandom. I have to agree that I've never seen anything quite like this before
except the Church of St. Jobs. I always thought that we software engineers are
reasonable people. But apparently a subset of us aren't.

However reluctant I maybe to join in this time-wasting back and forth. I'm
just glad that someone has taken the time to point out just how inexperienced
the crowd and ridiculous the whole situation is. We have enough technology in
the world already. We don't need another one that makes making mistakes so
much easier than before.

Lastly, I'm extremely disgusted by the misleading tag lines Ryan Dahl put on
Node's front page. Programming isn't easy. It can only be easy for so long.
Scaling is even harder because it actually requires deep knowledge and insight
into how computers and networks work, something that I very much doubt that
many of the current Node.js crowd understands. If your solution to your
multiprogramming problem is to spawn more Node.js processes, maybe you've
picked the wrong tech.

~~~
jrockway
I've seen it from the following communities: PHP, Ruby, Perl, Python, Java,
C++, C, C#, Haskell, Emacs, Vim, Common Lisp, and Scheme.

People are tribal. Some people are attracted to tribes, become attached
without really knowing why, and start having the strong urge to fuck with the
other tribes. Apparently this was good for the survival of the human race.
Perhaps it's a bug now that we should consciously compensate for, like the
desire to eat a box of doughnuts. mmm.... doughnuts... Good when you were a
caveman. Bad when you sit in front of a desk for 16 hours a day and sleep for
the other 8.

What's the alternative to scaling an application by running multiple copies?
Scaling an application by running multiple threads? Exact same thing. The only
advancement over this model is when the runtime can automatically parallelize
your code, and you actually scale linearly when it does that. In the mean
time, if you use a database server and not an in-memory database, guess what,
you're "using queues" and "scaling by starting processes". People do it
because it's easy and it works.

~~~
skeptical
__People are tribal. Some people are attracted to tribes, become attached
without really knowing why, and start having the strong urge to fuck with the
other tribes. Apparently this was good for the survival of the human race.
Perhaps it's a bug now that we should consciously compensate for__

That this tribal behavior occurs among software engineering is a rather
disappointing fact. Computers are pretty much the edge of technology in many
aspects, technological achievements by Mankind should be the prove that we're
able to use our brains in more advanced ways than basic instincts and produce
great achievements like modern software.

This flood of programmers that prefers to join a tribe instead of enjoying the
good things from many different 'tribes' just makes me wonder how many of us
are really devoted to do something useful/positive.

~~~
generalk

      > That this tribal behavior occurs among software engineering 
      > is a rather disappointing fact. 
    

It occurs amongst software engineering _humans_. All humans get this to some
degree, it's basic ingroup/outgroup psychology.

We're all humans here. It's nothing to do with "devoted to doing something
positive" or "using our brains in more advanced ways." It's just the reality
of being an evolved ape, and the lack or presence of this trait doesn't make
anyone any better/worse than anyone else.

~~~
jrockway
Yes, thank you for writing this. We are all humans, even if we don't want to
be, and we have to think about our actions in the context of our genetic
programming. In the case of tribalism, even though it's a strong feeling, we
have to ignore it because it doesn't get us anything in programming language
debates.

The best attitude to have is one of acceptance and an open mind, because the
right programming tool applied to the right problem can make solving that
problem orders of magnitude less difficult. You can have programmer friends
even if you don't unconditionally hate the enemy. In fact, it seems, most
people don't care about who you don't hate.

------
jarrett
It seems we now have three camps:

1\. "Node is the magic bullet."

2\. "Node sucks."

3\. "Nothing is that simple. Learn you some computer science."

#3 is the correct answer, but I'd like to see this point explored in more
detail. The current back-and-forth isn't productive. What would be productive
is if we had an informed discussion of what Node is good at, what _not_ to do
with it, and how it compares with other tools and approaches.

Specifically, I'd love to hear opinions on some of these points:

* Node is opinionated about threads. Negatively so. See <http://nodejs.org/#about> . Do you agree with these claims?

* Non-blocking IO doesn't solve every performance problem under the sun. Far from it. But what problems does it solve exceptionally well?

* Is Node a breakthrough in computer science? Events and callbacks have been around for ages. What new ideas does Node bring to the table?

* Why exactly is Node supposed to be so scalable? Is scaling to more machines easier with Node than with other approaches? How about scaling to more cores on the same machine? Does Node provide any special support for distributing a task across multiple workers and possibly over the network, e.g. with something like MapReduce?

~~~
nknight
#3 isn't even necessary -- you're telling someone to go learn calculus when
all they really need is basic algebra, at most.

2-3 hours spent on layman's summaries of the practicalities of modern CPU
architectures (special attention to cache coherence, what fun), user vs.
kernel space and switching between them, select() and its cousins, and TCP
would do most of the people involved in these debates a world of good.

~~~
jarrett
I'd venture that 2-3 hours is far too little for someone to learn the topics
you list from the ground up. But I'm just nit picking :). Your point is well-
taken.

But one big problem is that these are unknown unknowns for many people.
Suppose a new but intelligent programmer finds Node and wants to decide
whether it's good for some new project. How would that programmer know what to
look up? How would s/he know that, e.g., user vs kernel space is even a
relevant concern in the decision to use a single-threaded, event-based
framework?

------
ender7
All right guys, this is getting absurd.

I am having a ton of fun using NodeJS to _actually build stuff_. It's fast,
it's scalable, it's maintainable, it's great.

Yet another pants-on-head troll has decided that NodeJS is a crime against his
tech religion? _I don't fucking care._

~~~
zedshaw
Actually, this is getting pretty funny. Don't bring your logic and reason to
this and ruin for those of us who just bought a bag of popcorn.

------
markbao
This is the worst rant I've read in a while.

It starts with lambasting the fact that Ted Dziuba didn't intend the Fibonacci
example to be the one role model of comparing Node.js and other languages, and
then the Node.js community (or at least a few members of it) rallied around
showing that Fibonacci was actually fast in Node. I agree with this. We should
be talking about the big picture, not just single implementations.

Then, it goes on for 4 paragraphs about how slow Node.js was with Fibonacci.

Wasn't it the point that Fibonacci _wasn't_ the point? If the point is to show
that Node.js is inefficient with computation, and Fibonacci was just a dumb
example, why was the rest of the article about the dumb example mentioned
previous?

~~~
ctide
I thought the point of this article was to generate a cliff notes version of
the last week of arguments, coming from the side of someone who thinks node is
cancer. Why are we even discussing this?

~~~
markbao
Yeah. I really want to see this discussion taken in a direction where we're
_actually_ talking about Node.js and its computational (non-?)efficiency,
instead of this needless back-and-forth.

------
klochner
Best part of the post was where someone suggested he increase his heap size to
1GB to get a fibonacci algorithm to run.

    
    
       After pointing this out, a member of the Node.js
       community (post now deleted) suggested I might have an
       obsolete version of Node with a 1GB heap limit and that
       I recompile without the 1GB restriction so that this 
       retarded algorithm can continue eating up all my system RAM.

~~~
chc
It is curious that an array with 1 million doubles would take anywhere near a
gigabyte in V8. 1000000 * 8B is about 8MB. Even with 5000% overhead for the
data structure itself, that's only 400MB. Where did the other 600 MB go?

~~~
calloc
Call stack?

------
IsaacSchlueter
Author seems to have missed that node-fib is a joke.

Ted Dziuba is clearly a person suffering from profound intellectual
insecurity, and a lack of technical acumen. We should offer him our sympathy
rather than enable his self-destructive behavior by praising his "previous
trolling" activities.

This article, like the poor sad unfortunate Mr. Dziuba himself, seems to be
combatting a strawman: the idea that Node.js users and developers are
advocating that it be used for everything. It's a fun platform to use, and
pretty good for a lot of tasks, but any grownups close to the project (and
there are a few of us) are quite vocal about the fact that it is targeted at a
very specific use case: IO-bound network programs.

People get excited about the programs they use, and want to see how well it
can do things. When your hammer is fun to swing, you want to see what happens
with you hit stuff with it. Ted Dziuba has previously advocated using xargs
instead of Hadoop for parallel map-reduce, so I would have thought he might
understand that sometimes you use the tool that you understand (if it works)
rather than something else, even if that other thing might be objectively
better for that particular task.

I don't know what node users articles like this or Ted's are talking about.
I've been using node almost as long as Ryan, and totally love it. I don't know
how we could be more clear about what node is and isn't good for.

At NodeConf, in the Committer Panel, someone asked, "What _isn't_ node good
for?" We all rattled off a variety of things. The node community is actually
pretty sane. We just laugh at stuff like this, since it's so ridiculous, and
make jokes like node-fib.

~~~
justin_vanw
> Ted Dziuba is clearly a person suffering from profound intellectual
> insecurity, and a lack of technical acumen.

Perhaps, as the one responding to a criticism of a piece of software with
personal attacks, you are the one that is insecure? I can understand how, as a
fanboy of something that was criticized, you would now take it upon yourself
to hurl insults on the person who has wronged you so. This is the internet
after all!

> We just laugh at stuff like this, since it's so ridiculous, and make jokes
> like node-fib.

Actually, you opened this comment by personally attacking Ted, because he
insulted some software you happen to be a fan of. I think the most likely
reason that you would contradict in such an obvious way something you just
wrote is that you don't have a great deal of working memory. Looking at your
code on github (<https://github.com/isaacs>) seems to confirm that theory.

~~~
IsaacSchlueter
> I can understand how, as a fanboy of something that was criticized

Can you define "fanboy" for me, please? I don't know what it means.

> Actually, you opened this comment by personally attacking Ted

I wasn't attacking Ted. Actually, my heart really does go out to him. I mean,
he's a human being, right? Could you imagine living with such a crippling
psychological disorder? Just think of it. The pain, the emptiness. The worst
part is that he's almost certainly too proud to ask for help. It's tragic.

> I think the most likely reason that you would contradict in such an obvious
> way something you just wrote is that you don't have a great deal of working
> memory.

Sorry, I lost you like a third of the way through that sentence.

~~~
justin_vanw
How is saying that someone has a psychological disorder not attacking them?

~~~
IsaacSchlueter
Your comment is indicative of the anti-mental-health sentiment in our society:
that diagnosing or treating mental health issues is an admission of failure,
rather than a sign of courage and responsibility.

You should check your priors, and maybe help create an atmosphere where people
with these problems don't feel like their only options are denial or self-
destruction.

~~~
justin_vanw
Since you're giving out free diagnosis over the internet, would you mind doing
me?

~~~
IsaacSchlueter
I'm just saying we should be supportive of Ted's recovery, rather than enable
him, that's all.

------
jchrisa
tl;dr;

Don't use JavaScript for numerical computation. Don't block your IO loops for
CPU intensive stuff.

commentary:

I've never met a Node hacker who would ever do any of those things. This post
should be called "Straw man Node.js n00bs jump the shark."

I've written web apps in a wide variety of dynamic languages, and you know
what, I've never done anything CPU intensive in the request response loop,
ever. This has nothing to do with Node, fibonacci in PHP is just as bad an
idea (although it might take you a little longer to realize it, as you've
probably got lots of PHP threads running behind your Apache).

~~~
wyuenho
If you've been following this argument from the beginning (I'm very sorry to
say that I have), you'll notice that Ted's point is not that you _WILL_ do CPU
bound tasks in Node, but that Ryan Dahl's misleading statements on Node.js's
front page is absurd. Of course no one with any sense will put CPU bound jobs
on the same process/thread/event queue as the one processing the request. But
you do have to realize, it is exactly that no one will ever do the above that
renders Node's existence rather pointless. Threads/processes or events, you'll
still pass off the heavily computational stuff to a different processing
queue. Events or threads, when that single process starts topping out, you'll
still have to launch another process. What makes Node.js different from any
other technology that have come before? Nothing except that it comes with a
server and it's written in JS. If you like the Node REPL and JS, that's fine,
just don't propagate the urban myth that's on Node's front page. I think this
is Ted's point IMHO.

------
ntoshev
This only proves that many in node.js community and some trolls outside of it
don't really understand programming at the event level, BUT insist on writing
about it.

First, you shouldn't judge anything by the worst of its kind.

Second, why I keep seeing related stories piling one misunderstanding on top
of another on Hacker News?

------
thenduks
Hmm, sounds more like reddit is the thing that has jumped the shark :)

Most people using Node I've had contact with are firmly in the 'right tool for
the job' camp. No one sane does CPU intensive tasks inside the event loop...
that's what delayed job processor stuff is for.

~~~
balloot
That's my takeaway as well. Who cares how long a webserver takes to do a
Fibonacci loop anyway? The point of a web server is to process lots of
relatively small requests quickly and concurrently. Testing node.js with a
Fibonacci loop is like testing a Ferrari by seeing how much weight it can tow.

~~~
dfox
Testing Ferrari by seeing how much weight it can tow would actually get you
pretty useful performance metric.

Point of this whole thing is that you cannot reasonably do complex
computations in Node. While most "Web 2.0" applications probably does not need
to do that in response to request, there are also many web applications that
actually do something that might be reasonably called complex cpu-intensive
processing in response to user request (although most such things are hard to
scale). So it really boils down to "right tool for the job" - and for many
practical (but maybe un-popular) problems, Node simply is not the right tool.

~~~
cube13
This is a serious question, because I honestly don't know the answer. What
purpose does node serve in more complex(i.e. non-static page) situations?

Should it just be the intermediary between the users and your database
process? Heck, should the database process also handle all the formatting of
the data as well as the queries? That is fairly CPU intensive(and doesn't
scale well at all), especially if you're getting to larger data sets.

------
InclinedPlane
I'm just tired of this, it's beyond dumb.

I remember the spectacle of the Java hype machine and the dot-com 1.0 hype
machine. In comparison the node.js hype doesn't even register on the meter.
Moreover, I don't see a rash of people misusing node.js to the degree that is
prevalent for pretty much every other web technology out there. Are some
people going to misuse technology? Always. Is the node.js community out there
trying to proselytize to the world, selling node as the solution to every
problem on the planet for every developer on the planet regardless of whether
it makes sense? Not in the least.

This is a faux-controversy.

------
EGreg
And the point of this is?

You use Node.js for writing evented programs using Javascript. It is awesome
for that. It is better than PHP, and a bunch of other solutions, for actually
handling web clients. Heck, it brings us back to the days where we can handle
the C10K problem without much work! And it's friggin Javascript!

All these politics are missing the point. This blog post is missing the point.
Things SHOULD be simple. There SHOULD be an insanely fast evented solution to
do things. And there is. Get over it.

~~~
AlexC04
I'd never heard of the C10K (<http://www.kegel.com/c10k.html>) but I love
scaling issues and this looks to be some fascinating reading. Thanks!

 __EDIT __Interesting annecdote... Cal Henderson is the author of "Building
Scalable Websites"<http://www.amazon.com/gp/product/0596102356> and has worked
in "the trenches" as the lead engineer of FLICKR and developer at B3TA.

Apparently his newest company <http://tinyspeck.com/> is using node.js for
their game engine.

Assuming he's planning on scaling to a reasonable size, that seems to be a
pretty resounding endorsement that there's at least something going for it. I
mean ... that guy's got a bit of experience in working at scale.

------
sreque
I'm very glad the node.js community got trolled so effectively. It's been
clear for a long time that these most of these advocates are not grounded at
all in reality, and it was very entertaining to have them revealed in their
ignorant zealotry. Evented solutions have been available in every modern
language for some time. They aren't used that often though because they have
serious inherent limitations!

I understand the appeal of node.js. It makes the web stack feel much less
complex, and I like to reduce complexity as much as the next guy. But in the
end, node.js is just a thin wrapper on top of a simple C library. In the end,
it really only excels at solving a small, narrow, niche problem.

------
strags
I use node.js for long-lived connections (sending/receiving large amounts of
data, or long-polling). This is a task to which it is ideally suited. Putting
CPU-intensive operations inside a HTTP handler is something that is
_obviously_ not going to work in a single-process, single-threaded event-
driven framework. Ted's complaining because node.js is unsuitable for
something that it's not intended to be used for.

Defending CGI, in my opinion, also hurts his credibility. The "good old days"
weren't so good. Spawning a new process for each request? Re-establishing
database connections every time? That shit only worked because there were
three people on the internet at the time.

~~~
icebraining
_> Defending CGI, in my opinion, also hurts his credibility. The "good old
days" weren't so good. Spawning a new process for each request? Re-
establishing database connections every time? That shit only worked because
there were three people on the internet at the time._

Apparently the server behind SQLite.org and Fossil-scm.org, which gets 250M
requests/day, spawns a new HTTP server for each request. There's no database,
though.

[http://www.mail-archive.com/fossil-users@lists.fossil-
scm.or...](http://www.mail-archive.com/fossil-users@lists.fossil-
scm.org/msg02065.html)

~~~
dchest
fossil-scm.org uses SQLite database (in WAL mode), and the website is the
repository itself.

[http://www.fossil-
scm.org/index.html/doc/trunk/www/selfhost....](http://www.fossil-
scm.org/index.html/doc/trunk/www/selfhost.wiki)

~~~
icebraining
Oops. Thanks.

------
jrockway
This article is terrible. It boils down to "Ted stirred up some shit in the
node community, which I like to troll because I wrote my own programming
language and see node as the enemy. As a result of the shit-stirring, people
that don't know much about programming defended node. Meanwhile, I wrote my
own programming language that nobody uses because nobody is as smart as me,
the creator. What's up dawg?"

OK. You have to realize what the community is and isn't. The community isn't
every person with a blog. Those people are fanbois; and they exist everywhere.

You've got to filter the noise out. Don't submit every article about something
to HN. Don't tell your friends "hey, read this article about a guy memoizing
fib, completely missing the point that it was an example CPU-bound algorithm".
This is all noise, people that don't know what they're talking about talking.

So, is accidentally blocking an issue in node? YUP! Is leaking space in
Haskell something you should worry about? YUP! Is passing a string to a
function that requires an int something to worry about in Ruby? YUP! Should
you lose sleep at night worrying about whether your Java application is
leaking memory? YUP! Should you have nightmares about input data causing your
C program to write to memory it didn't allocate? YUP!

Why do you think writing working software is difficult? Because we all have
phenomenal tools but are just morons? Nope, we're all morons and we have
shitty tools too. All programming languages suck. So you must use them for
their strengths, not their weaknesses.

Node.js' strength is that it was designed from the ground up to do everything
that can be done asynchronously asynchronously. This is mostly due to the
standard library and a bit of C, rather than something intrinsic to the
runtime or language. The problems it runs into are CPU-bound computations.
People are afraid to split applications into many processes and have some
existing tool "scale" them as necessary. As a result, node.js does not work
for them, because it doesn't have Java-style threads, which is the hammer they
want to use to drive in their screws.

Anyway, I don't really even like node.js that much, but it just feels worth
pointing out that no other language solves the denial-of-service problem. If
you use preemptive multitasking, you eventually run out of memory for threads.
If you use an event loop, blocking starves the other handlers. If you use
multiple processes, your process table fills up. The question is: how are you
going to deal with it. If you write a thread-based application, you have to
figure out how to collect blocked threads (and hope the OS schedules your
collector thread). If you write a process-based application, you have to
figure out how to collect hung processes. If you write an event-based
application, you have to figure out how to ensure you never block. In the end,
all three problems are equally hard. It's just that node makes it easy to make
100000 connections hang without killing your Chrome session with your blog
editor in it. Write a CGI script in C, use mpm_prefork or something, hit
Apache with a million connections, and watch the OOM killer annihilate your
system.

Programming is hard. Let's stop blogging.

~~~
zedshaw
> You've got to filter the noise out. Don't submit every article about
> something to HN. Don't tell your friends "hey, read this article about a guy
> memoizing fib, completely missing the point that it was an example CPU-bound
> algorithm". This is all noise, people that don't know what they're talking
> about talking.

>... Programming is hard. Let's stop blogging.

The problem with this sentiment is right now too many programmers equate
popularity with quality. Their only esthetic is "X number of people follow the
project on github". Combine this with the relative inexperience of most
programmers and we've got a situation where you can easily flood the market
with shitty technologies that only work because everyone believes in them, not
because they actually work.

I'm not really talking about Node here, but more your assertion that "this is
all noise and us serious real programmers should ignore it". The sad reality
is, real serious programmers should speak out about shitty popular
technologies before every job requires "20 years Node.js experience".

I'd love for the state of the art to be defined by the state of the art, but
sadly, it's currently defined by the best marketing and propaganda. Answering
that propaganda with criticism _and_ writing better software is the real
answer.

~~~
hello_moto
Didn't a similar event occurred a few years back (in HN as well)? Like around
2006-2007 with Ruby on Rails and the framework war? Big waves, big
disagreements, flame-wars.

Good prediction though Zed, I'm seeing ghetto Ruby (Rails related code)
lately.

Then it becomes the language wars between newer dynamic/functional languages.

Now it becomes Node.js vs the rest of the world. Are we going to see crappy
JavaScript code soon?

PS: At the very least, Rails brings real productivity value to the table
(cause all other frameworks sucks back then).

~~~
samstokes
_crappy JavaScript code soon_

Is there any language in which a larger quantity of crappy code has _already_
been written?

~~~
hello_moto
Good point. Should've put "Server-Side JS code" maybe?

------
ryan-allen
I think the way we talk and reason about tech has jumped the shark.

* JavaScript is a nifty little language. * V8 is a nifty little VM. * Node is a nifty little project. * Isn't it lovely that Ryan Dahl had an idea and like, actually did it! He doesn't write ranty blog posts (often), he writes code for people! * There are worse things to rant about. Things that come to mind are the GFC, the US Govt. Bailout, indications it didn't work, education, unemployment. Lots worse things than Node JS.

P.S. If you ever deployed a Rails app to production then, well my friend, the
joke really is on you!

------
9oliYQjP
Jumped the shark posts have jumped the shark.

~~~
raganwald
"Jumped the shark” considered harmful.

~~~
urschrei
"Jumped the shark" posts are an antipattern.

~~~
politician
"Jumped the shark" joke comments are the sort of thing HNers vote down.

~~~
mcantor
Is """'"Talking about being down-voted before you voice an unpopular opinion"
posts have jumped the shark' is dead!""" the "Considered Harmful"-Killer?

~~~
politician
I think that's what happened. I guess my meta joke was misunderstood...

~~~
MrMan
jokes are not appreciated

------
mschwar99
Besides entertainment value doesn't all of this back and forth reduce down to
the age old "use the right tool for the job in front of you"?

Node.js as it currently stands isn't the best solution for applications that
will involve CPU intensive tasks. Perhaps at the outset of a project you don't
know when and where those types of tasks will pop up so basing an entire
architecture on it might be risky.

However, it seems to me that regardless of the above, there are tasks Node
excels at and it would be silly to dismiss it as a technical solution all
together. I'm building browser based games with it and love working with Node.
The bulk of the logic is in the client and Node serves as the glue that allows
people to play games together from different clients. Nothing I have read
gives me pause about this implementation.

------
Detrus
I'm pretty sure the only sane way to implement CPU intensive tasks in Node and
browsers are web workers. Not sure about the state of web worker support in
Node but the resulting code should be straightforward. Even so, the speed of
JavaScript is limited, so any serious number crunching will be a pain in the
ass.

Node and browsers are seldom used for CPU intensive tasks for now, so it's not
a priority.

There are alternatives that handle node's current warts elegantly, can do
serious number crunching painlessly, but just don't have the cool factor.

------
shoo
Javascript integers can only reliably represent values up to 2^53, as they are
implemented by 64-bit floats [1]. This means that fib(73) and below are
correct, but fib(74) and onwards are almost certainly going to be wrong.

The one-millionth fibonacci number, fib(1000000), has 208988 digits when
written as a decimal. It takes about a minute to compute fib(1000000) with
python 2.6 and write it to file.

I am completely missing the point, but this does amuse me. Framework/language
pissing match descends into performance benchmark battle where no-one cares
about correctness?

1\. [http://www.jwz.org/blog/2010/10/every-day-i-learn-
something-...](http://www.jwz.org/blog/2010/10/every-day-i-learn-something-
new-and-stupid/)

~~~
d0mine
Minute is too long:

    
    
      $ time curl -s http://localhost:1597/sicpfib/1000000 >sicp.out
    
      real    0m1.856s
      user    0m0.000s
      sys     0m0.000s
    
      $ wc sicp.out 
           0      1 208988 sicp.out
    

<https://github.com/zed/txfib>

------
scotty79
I have a question about Node.js I hope it's legitimate.

If I have a endless loop in some method that is supposed to generate some part
of some webpage of my webapp will it stall the whole app until I restart the
server?

From my tests it seems so.

What additional facilities are required to be used so that single bug won't
kill the whole app for all users?

Rant mentiones putting nginx in front of node.

UPDATE:

It seems that there is a tool called monit that can restart your server when
it stalls:

<http://howtonode.org/deploying-node-upstart-monit>

------
jevinskie
Isn't it the point of all this madness that jumping the shark for these small
and trivial problems is fun and thought provoking?

~~~
Miky
Jumping the shark is the moment when something, such as a TV show, or in this
case a community around a web framework, begins to decline in quality beyond
recovery, so “jumping the shark for these small and trivial problems” really
doesn't make sense.

~~~
wccrawford
No, "jumping the shark" is a single event so monumentally stupid that the show
can never recover from it.

Node.js didn't jump the shark. It has some stupid users, but what language
doesn't? That he got stupid answers from the community doesn't mean Node.js
itself is bad.

------
jeffreymcmanus
I remember having debates like this about the TRS-80 in middle school. These
guys need to give it a rest, srsly.

------
PLejeck
I decided to take it a step further and add fibonacci generation as an Express
Middleware.

<https://github.com/nuckchorris/express-fibonacci>

------
glenjamin
I'd like to point out that by the time this article was posted, and thanks to
some constructive discussion about the approach, the node-fib "project" on
github has been updated with a much faster recursive approach which doesn't
use loads of memory and doesn't resort to memoisation, but still doesn't block
the loop and serves almost as many requests/sec.

My point here, and in writing the lib in the first place was that naive
implementations are naive in any language/vm. I lump splitting an algorithm
across the loop into the same band as deciding this task should spawn a
thread/worker. And using child processes as workers is still an option in
node.

------
perfunctory
I don't get why all these back and force rants get upvoted.

------
jwingy
Geez, so many generalizations and false arguments. Some of you could use a
basic reasoning class (possibly Philosophy 201 or something of the sort).

------
greenail
right tool for the right job. solving real problems is hard. unix, microsoft,
beos python, java, brainfuck whatever. experts tend to be overspecialized and
one dimensional. pundits have their own agenda. religion closes the mind's
eye. forget about your preconceptions and embrace the world around you.

------
swah
Does the same criticism applies to code written with Greenlet/Gevent (see for
example Brubeck web server)?

~~~
seanmcq
Yes, not yielding control from a function in any evented framework will block
the main event loop.

In programming languages that support coroutines, yielding a sleep every few
loops will release the event loop. In languages without coroutines like
javascript you will need to write your algorithm in CPS to release the event
loop.

------
gersh
Huh. Just write the algorithm in say c, and have node do a callback when the
algorithm is complete.

------
wavephorm
I don't see how discussions like this signify the decline of NodeJS. Quite the
opposite. Lots of people are thinking about how to do this kind of computation
the right way, within the context of NodeJS.

Honestly this discussion has kind of highlighted how bad almost all other
platforms are and how much room for improvement there is.

~~~
jerf
Actually what I have found it has highlighted is just how many of the Node
advocates completely and _utterly_ fail to understand their competition. I
really, really wanted to think it was just a few isolated people, but the
evidence suggests that the meme that Node is actually some sort of
multiprocessing breakthrough has spread further in the last few months, rather
than dying out.

So let me lay it out for you: Node's multithreading is _primitive_. There are
in fact other languages that can simultaneously do long-running computations
_and_ serve web pages at the same time, because they are _not_ single-threaded
under the hood. That is a _Node_ limitation, not a fundamental computing
limitation. Many of those other environments can also trivially use multiple
cores within the same OS process.

We are discussing the limitations of Node with regard to long running
precisely because it is a limitation that Node in particular has, and that
there are other environments that do not have it. We are discussing this
limitation precisely because the casual presumption you make in your last
sentence that Node is the epitome of programming platform, and therefore if it
has a problem then everything else must suck too, is false.

I am staggered at the degree of ignorance of other platforms being displayed
by the Node partisans here, because it's not "well, OK, that's nice but in
practice I don't care", which I would disagree with but would at least
consider debatable (and I mean that quite honestly), but rather just a
continuous talking past the Node partisans entirely, with little evidence that
they even understand what is being said. I say this from experience over the
past couple of days, where it's pretty clear the Node partisans seem
fundamentally incapable of considering the concept of "environment that does
not have the fundamental limitations of Node".

Several of you seem to be expressing confusion about why some of us aren't
coming around to seeing the light. To you all, I'd recommend this essay:
<http://www.paulgraham.com/avg.html> Hint: _Node is blub_.

Let me be clear about my motivation in writing this, and generally trying to
tamp down on the Node hype. First, it's bad for Node. I've seen this cycle
before, and as fun as the ride up is, when it is predicated on false claims it
tends to explode at some point and the whole thing goes down in flames. (A
process that may now be starting.) Second, those of you who only know Node and
think it is the epitome need to have it explained to you that there are in
fact other tools that are more useful in these cases, so if you ever encounter
those problems you can use the right tool for the job. Otherwise, you'll blow
untold manhours trying to force a old paradigm to do something you could have
done in a more modern one much faster and more effectively. I don't hate Node;
I hate the hype, and the damage it is doing to a large group of people by
lying to them about what the competition does.

~~~
michaelchisari
_how many of the Node advocates completely and utterly fail to understand
their competition_

I agree, but as someone who is generally excited about Nodejs, I see it as
necessary growing pains. These kinds of criticisms and back-and-forth and
flamewars, if a language or platform is having them, it doesn't make it fade
into obscurity, it forces it to mature, either technically or socially. It
also has the benefit of bringing it's most ideological advocates down to
earth. I feel as though I watched this whole process with Rails, which went
from The Greatest Thing Ever(tm) to simply another framework with some big
advantages to go with it's known disadvantages.

And now it's happening with Nodejs, and I think that's ultimately a good
thing.

~~~
chc
As somebody who got into Ruby shortly before Rails (because I'd heard it was a
"modern Smalltalk") and was writing JavaScript back when DHTML was the new
shiny thing, that's my perspective too. The evolution of Node.js reminds me a
lot of Rails. It lent an air of legitimacy to a language that a lot of people
used to look at sideways if at all, and it's rather overhyped by an influx of
people who were plagued by the problems it solves, but it is fundamentally
pretty good even when you drill past the hype.

------
hugacow
Bulldonkey. Javascript on client side will continue for the foreseeable future
which means those developers would want to use the same language to do server-
side. Just because it hasn't taken hold, doesn't mean it won't.

------
deleo
Another boring, silly "jumping the shark" post

------
xianshou
The man is butthurt about trolls trolling trolls trolling a man who's butthurt
about bad software.

All I have to say: the cycle continues.

------
felipemnoa
I finally decided to do some research into what Node.js actually is and it
turns out that it is just another web server. Seriously? That is what all the
fuss is about? Its main feature seems to be that it has an event driven loop.
Yay, an event driven loop, is not like they have not existed for a really long
time. Whomever is marketing this thing must be a marketing genius.

On the other hand, the real appeal might be that it allows a lot of
programmers that only know JavaScript or that feel most comfortable with
JavaScript to do sever side programming with JavaScript. Something that as far
as I know wasn't available before which is why this thing has become popular.

