

Node.js is good for solving problems I don’t have - latchkey
http://xquerywebappdev.wordpress.com/2011/11/18/node-js-is-good-for-solving-problems-i-dont-have/

======
shtylman
Troll. Post made no sense and came to no conclusion.

"The content server should not need to do hardly any IO. Why would an HTML
content server need to write to the filesystem?"

This just shows a blatant lack of knowledge about what constitues IO. FYI,
network is IO, writing to console is IO, logging is IO. The point of an
evented system like node (and others based around the 'select' or 'epoll' type
calls is that you can use one thread to do other things when you are waiting
for the kernel to tell you your socket is ready.

Yes, I too get frustrated when 'front-end' people think they are systems
engineers or super server coders, but that doesn't mean I am going to write a
blog post that goes nowhere about it and completely misses the point of an
evented system like this.

~~~
shuzchen
Post also shows a blatant lack of knowledge about what an event loop is. Node
and Tornado (two event-loop based servers) are by design single-threaded. This
is because for certain setups, having a separate thread for each connected
client (the norm for something like Apache) can destroy your server.

IMO the main problem that event loop systems were designed to solve was the "I
have a ton of people connected concurrently but the majority of the time these
connections are idle". Think if you were building a chat application. Your
users are connected to your service constantly (they want to get messages as
soon as they arrive), but most of the time they AREN'T receiving or sending
data. If you had a thread for every connected client your server would melt
due to the ram overhead, even though most threads aren't doing any work 99% of
the time. In an event-loop based system, you don't have this issue because
everything gets handled by one thread.

~~~
MostAwesomeDude
Yes and no. The problem solved by event loops is the problem solved by
select(): You never want to wait for a single person to do something; you want
to wait for _anybody_ to do _anything_.

~~~
nakkiel
You certainly mean "the problem solved by select() alternatives such as
kqueue(), epoll(), etc..". :)

------
jat850
I guess I don't understand - is this meant to be an object lesson or warning
to people against using the wrong tool for a given application?

The author self-identifies their problem as: "The problem I have is processing
a lot of data quickly"

Clearly, then, don't use node. But why write a blog post about not using
something? A post involving a lesson learned ("I tried using node for
processing a lot of data quickly, and it was terrible!") would have been more
valuable.

I fully offer up the idea that I may have missed the point.

------
schleyfox
Someone should tell the Nginx guys that blocking IO is not a problem that web
servers actually have. I'm sure they will be thrilled to not have to do
complicated event programming anymore.

------
nakkiel
The whole website is a PR/FUD base for Mark Logic. Check their Wikipedia page
too.

<http://en.wikipedia.org/wiki/MarkLogic>

I guess they're tyring "to fully utilize the potential of the internet".

~~~
dextorious
Actually they mention Mark Logic in the article a couple of times, but what
they say totally stands (at least as an argument) on its own.

I could care less about Mark Logic. I _do_ care about what the article says,
and I agree with it.

~~~
dmpk2k
Having skimmed the article I found it relatively unenlightened. What do you
agree with?

------
jphackworth
_Node was created to provide an event-based web server programming model_

This is not true, and it's probably why the author seems confused. Node was
not primarily designed to be a _web_ server, nor is it particularly good at
that. It is much better as a server that keeps sockets open, like for a chat
application.

------
stateless
I think the author was dead on despite some confused points - the number of
problems that node is the best solution for is a fraction of what its
currently being used for. It seems obvious that it's popularity is tied to
server side javascript.

------
nakkiel
I was about to extract a few quotes showing a blatant lack of understanding
whatsoever. In the end it got too lengthy. Looks like a Ninja stepped on the
wrong land today.

All the references to threads are probably the most difficult to understand
for me. Node is single threaded and one can't spawn a new one. The author seem
to be using it as some sort of magical artefact.. it's beyond comprehension.

------
geuis
Exactly, node is useful for solving problems that you don't have. So you
wouldn't use node for them, then. The answer to your own question is your own
statement.

Node makes it possible to do completely new things that would be difficult to
do otherwise.

I take exception to this statement: "Node enthusiasts are front-end coders not
wanting to do server coding." The number of engineers who _only_ do server-
side programming these days are few and far between. I haven't worked a job in
the last 4 years where no one touched the frontend at some point or vice-
versa. Sure, we usually have niches where we do the majority of our work,
either front or backend. But at no point are they exclusive.

Node has been a blessing for me, as a frontend engineer, because I can finally
code servers in the same mindset as I write client-side javascript. We
(frontend folks) live in an asynchronous world. We eat parallel requests, xhr,
and async callbacks all day. It turns out that when you apply those same
concepts to the server, it opens up a whole new world of possibilities.

~~~
zzzeek
"Node has been a blessing for me, as a frontend engineer, because I can
finally code servers in the same mindset as I write client-side javascript. "

That was _precisely_ the author's point. You'd rather stick with what you know
then bother to deal with traditional server side techniques.

~~~
maratd
Uhmm, I've been writing server side code for the last decade. I've also been
writing front facing code for just as long.

JavaScript works well for Node because it is a language that has evolved to be
asynchronous. Not because some front-end web monkey n00bz know JavaScript.
Although that is certainly a plus.

Node.JS shines when you need to write network applications. It was advertised
for this purpose by its creator. That is its stated goal.

Traditional server-side solutions SUCK at this. Try writing a non-blocking
server-side WebSocket server in PHP and distribute the load across all of the
cores. Yeah. Exactly.

Don't get me wrong, I love PHP. But for every job, a proper tool.

Node.JS takes care of the network server and hands off the work to PHP via
FastCGI. That's how it should be. Node.JS solves real problems right now. If
it isn't doing that, you're trying to hammer in a nail with a screwdriver.
Stop it.

~~~
_delirium
_Traditional server-side solutions SUCK at this. Try writing a non-blocking
server-side WebSocket server in PHP and distribute the load across all of the
cores._

Wouldn't the traditional way to do it server-side be to just write it in C/C++
or Java with a thread pool? Or if you prefer the evented model, Python+Twisted
isn't old enough to _really_ be traditional, but is pretty widespread; and
some Java server-side apps have been moving to an async model as well.

~~~
maratd
> Wouldn't the traditional way to do it server-side be to just write it in
> C/C++ or Java with a thread pool?

I was a bit vague. What I should have said was that _dynamic_ language
solutions are bad at it. Certainly you can pull out C/C++, Java, Erlang, etc.
but at that point, you need to compile and recompile when you change your
code. You are dealing with dependencies, libraries, binary compatibility, and
the usual complexities that come with compiled languages.

> Or if you prefer the evented model, Python+Twisted

Well, Node.JS isn't the only game in town, certainly. Competition is a good
thing.

------
spyder
If you don't need node than don't use it, and yes it's not for serving static
pages, but more for interactive real-time web applications. And the part where
he says that focusing on serving the HTML is less important because it's just
3% of the content seems flawed, because if serving html is slow then the other
contents too will be loaded later (the HTML is what requesting them).

------
wicknicks
_"The problem I have is processing a lot of data quickly"_

It seems that the author needs something like super performant Hadoop++. Node
doesn't address these problems.

 _"Node enthusiasts are front-end coders not wanting to do server coding"_

I think he missed the point there. Using Javascript as a server side language,
node has bridged a gap so many web programmers have been crossing. With node
and mongodb, JSON is a language native to the entire webstack -- which is a
very powerful idea. We are able to sync datastructures across server and
client now.

This rant sounds very similar to "NoSQL DBs will never reach the competence
and performance of the RDBMS".

~~~
MostAwesomeDude
You have solved a problem that didn't exist -- XML and HTML were both
reasonable linguafrancas prior to JSON's invention.

JavaScript as a server-side langauge is not a good thing; JavaScript is not a
good systems language. We've already had an era of a poor systems language
(PHP) being predominant in the web application space, and the conclusion was
that there are better languages which can more effectively represent both
general systems tasks, and specialized web tasks.

NoSQL databases will never be relational DBs because they _explicitly_ eschew
the relational algebra that powers the latter. Similarly, Node isn't a serious
server-side solution explicitly because of its reliance on JavaScript.

Finally, I should point out that JSON isn't a subset of JavaScript. This means
that you can't exec it as JavaScript in all cases, and even if you could,
exec/eval is massively dangerous and should be avoided. This means that you're
parsing JSON, which means that you no longer have an advantage over other
languages -- Perl, Python, and Ruby all have very strong JSON support. (Python
even has it in its standard library now.)

~~~
ender7
\- XML and HTML are good ways to structure data...sometimes. Other times,
they're godawful. Especially if you're trying to pass data from one piece of
code to another piece of code in order to do RPC-like things (server->client,
for example). There's a reason that JSON is popular, and it's not because
"it's the cool thing to do".

\- JSON _is_ a strict subset of Javascript syntax. You can always eval() a
JSON string to convert it (not that you should). Many browsers support native
JSON parsing now, so it's also very fast. I'm not sure what the downside is
there.

~~~
MostAwesomeDude
<http://timelessrepo.com/json-isnt-a-javascript-subset>

JSON isn't a strict subset of JS. Moreover, no, you should _never_ eval()
things which are untrusted. Do you really trust everything the browser tells
you? No? Then why trust JSON?

I'm not anti-JSON, I'm anti-JS. Browsers don't support other languages (except
for VB, which bites, and Fx nightly support for Python, which I wish would
become more widespread) so there's no choice in a browser. On the server side,
though, you have a chance to use real languages, so you really should.

Oh, and also, you _do_ know that XML-RPC, bless its ill-specified heart, is
still around, right? There's a whole world of enterprise that isn't prepared
to accept JSON-RPC.

~~~
ender7
...I understand that eval() is dangerous. As noted in my comment.

Anyway, what do you count as a "real language"? I assume you mean Java. Which
is...fine. But Java is not the answer for everyone.

~~~
MostAwesomeDude
Java, C, C++, Haskell, Python, Perl, Ruby, C#, Go, Scala, and Clojure are all
better languages for systems development. (In no particular order.)

~~~
human_error
No love for OCaml and Erlang?

------
vph
Your friend might not be nodejs, but it might be .... Javascript. One way to
speed up data processing on the server is to avoid processing it as much as
possible and delegate such processing to the client side. Hence, Javascript is
your friend there.

------
viscanti
His biggest problem seems to be the "community". There's certainly some people
doing projects in node who would probably benefit from doing it with something
else. But to judge the framework by some "community" is silly. The node
community seems friendly and helpful and have created a large library to help
do things node is good at.

~~~
MostAwesomeDude
If Twisted, Event Machine, Rails, libevent, httpd, nginx, and Mongrel are all
judged by their communities, then why does Node get a free pass?

~~~
ksetyadi
If the community is the problem, I think he should focus on the community
itself rather than discussing on what Nodejs is incapable of.

------
InclinedPlane
"I don't like brussel sprouts."

Then don't eat them.

