
If you're using Node.js, you're doing life wrong - fogus
http://codeslinger.posterous.com/if-youre-using-nodejs-youre-doing-life-wrong
======
irahul
_The Ruby and Python communities are just now, many years after the hype has
faded, learning that stuff like dependency injection and proper modularization
are actually good things that help you maintain code over time._

This remark is off the mark. Dependency injection, as in _injection by
parameters_ and _injection by constructors_ are so obvious people do it sub-
consciously. A fluff word isn't needed for it. As far as _IoC containers_ are
concerned, I don't see Ruby/Python communities using it, mainly because half
of it is fighting static typing.

And people are learning proper modularization now? Seriously? Python/Ruby has
proper namespaces(ruby doesn't have it), modules, classes et al. Like any
other languages, Python/Ruby has it's share of programmers who write spaghetti
code, and programmers who don't.

Again, if he writes AbstractConnectionDepenencyInjectioManagerAbstractFactory
and calls it proper modularization, I am happy Python/Ruby isn't picking it
up.

~~~
crcn
This was my first thought. Languages require different design principles. If
you're calling JavaScript "spaghetti code", then you're doing it wrong.

~~~
batista
_Languages require different design principles. If you're calling JavaScript
"spaghetti code", then you're doing it wrong._

He's calling node style callbacks spaghetti code. Which it is, and it's a
known problem, and there are several half-baked solutions for it.

~~~
crcn
Node.js isn't picking up a new paradigm. The issue is very present in
JavaScript, and it's easy to write spaghetti code since the language by itself
doesn't offer much structure. It's possible to write very clean JavaScript /
Node.js code, but it takes a different approach over how you design / develop
apps versus a class-based language.

------
karterk
Ok, as someone who has been actually building apps on Node for about 1 year
AND working with a largish Scala codebase for the last six months:

> Not to mention the fact that its balls-ass slower than some straight un-
> optimized Scala.

I don't see the point of comparison here. Slower/faster is meaningless without
the context. Apples to Oranges. And, Scala has it's own issues. Yeah, the
JVM's performance is there, but bringing your team onto a Scala codebase is
not easy either.

> It provides the least amount of aid and comfort to the programmer and its
> nigh-on-impossible to follow the code 6 months later.

Anyone who has developed more than a Hello World in Node will know that the
problem of callback sphaghetti can be circumvented using events, promises and
async libraries. Yes, until the language itself offers an async construct,
this will be an issue, but frankly there are ways to get around it.

> JavaScript has very little support for any of those nice things: it doesn't
> even have namespaces, for chrissakes.

Client side JS has no module system. But Node.js has. At this point, I really
wonder if the OP has actually worked at all with Node.

> It seems to me that people who are really crazy about Node.js are people who
> only knew JavaScript to begin with and to whom none of the above would ever
> even occur.

Another baseless claim. I urge you to go see the GitHub profiles of Node core
committers. Seriously.

~~~
rgarcia
Nit: _Client side JS has no module system._

Check out requirejs: <http://requirejs.org/>

I've used it to handle both server-side (node) and client-side module systems,
and it's been great.

~~~
karterk
Yes, I am aware of requirejs. I was talking about native module support.

~~~
MatthewPhillips
Native module support is a feature of Harmony and,it's pretty fantastic. I
hope Node adopts this method of module loading as an alternative to require in
the future.

edit: phone keyboard typos

------
jim-greer
If you get really angry about the choices other people make for their own
work, you're doing life wrong.

~~~
zzzeek
Approaches that become popular and highly publicized definitely impact
everyone else's work in that field. Teams decide to migrate to those
approaches, discarding others, based on perceived popularity, shallow
impressions, small amounts of experimentation. Often, this is all we have to
go on. But team members who have an intuition that the approach may have more
problems than are first visible now have a choice, to either silently go along
with the new decision, or to document their reservations. The anger is an
issue though. It's a product of when you perceive a waterfall of hype crashing
over your own perception of better judgment (please note: _perception_.
subjective viewpoint). It's worth it to try adjusting those perceptions since
anger doesn't really get you anywhere.

~~~
bunderbunder
Couldn't agree more.

We're all aware of the Internet Hype Machine. We've all been duped by it
before. Heck, my big project today consists of frantic backpedaling from an
overly hasty decision, prompted by the IHM, to use SQLite in a project that
had no business being based on SQLite. We should all be open to hearing
criticism about choices to use X or Y technology.

-But- if you start by saying, "You're so stupid," then the person you're talking to will start by thinking, "You're such a jerk." And nobody really pays much attention to the opinions of people they think are jerks.

~~~
DevX101
Socratic method for the win. Keep asking questions until THEY come the
conclusion that what they were thinking was a dumb idea.

~~~
awj
That works, but I think it's overkill. Generally the "don't argue like a jerk"
method is sufficient.

~~~
bunderbunder
And if you aren't good at it it's easy to come off as condescending. Thereby
also causing you to be written off as a jerk.

Socrates was smart. He was also executed for being irritating.

~~~
batista
No, he was executed for "advocating for new gods and against the gods of the
city" (that was the actual charge).

You know, much alike someone insulting Mongo, Rails or Node in certain
communities... (or Java, CL etc in others).

~~~
rfrey
Also for corrupting the youth.

Again, much like Mongo, Rails, and Node. :)

------
andrewvc
I'm really pretty anti-node, but this article isn't very good. The concerns
here are mixed up and not very thorough. All these points need graphs, charts,
something solid to anchor them to. This is the sort of article that polarizes,
but doesn't add to the discussion.

It starts off strong talking about a high bug count, but never gets into
specifics there.

As far as scaling across cores goes, it's disingenuous to suggest that node
can't do this, there are a number of options here. Message passing, for
instance, does indeed work.

As far as nested callbacks sucking, I totally agree. But a walk through why
would add a lot more substance here as well.

~~~
nephics
Unfortunately, this way of stating unqualified arguments as basis for
reasoning is quite prevalent on the Internet.

Keeping it to node.js bashing, this guy takes the discussion to a slightly
lower level: <http://youtube.com/watch?v=1e1zzna-dNw>

~~~
highace
Ha, I liked that. But slagging aside, are the points he makes baseless?

------
substack
> JavaScript has very little support for any of those nice things: it doesn't
> even have namespaces, for chrissakes. Why would I want to repeat these same
> mistakes over and over again in a new language?

Javascript doesn't have this (by itself) but node has a very nice require()
system that is really excellent for long-term maintainability. When you bump a
dependency in a node project that change will only affect the code near it
because of how node_modules are resolved to the most local copy. You can bump
dependencies without worrying how this will affect other packages.

Plus, require() just returns an object. It doesn't puke a bunch of objects
into the current scope. This is massively useful for readability. I've sunk a
lot of time on other systems tracking down unqualified exports to figure out
which package's documentation to consult.

I've got nothing against scala and am sure it's a useful language but I wonder
if the author has even used node.

~~~
josephcooney
How can we even be talking about node and long-term maintainability when it is
about 2 years old? And require is younger than that?

------
davidw
I don't really have a dog in this fight, but I see node.js as being
"disruptive":

* It's "not as good" as languages/environments like Erlang.

* But it's good enough, and significantly simpler, as an approach to tackle a certain class of problems. This, combined with widespread knowledge of Javascript, will probably make it fairly widely used.

~~~
cube13
I disagree about it being that "disruptive". The concepts that it uses aren't
new. They've existed in POSIX environments for decades.

At a very basic level, Node.js is a callback-based API that's based around
some(probably select) notifier loop. That's not particularly new.

~~~
karterk
The disruption is not about whether the paradigm is old or new. The fact is -
today if you are building a small app and need some form of real-time
features, your best bet is Node.js. Right from etherpad lite to socket.io you
have the tools you need to be up and running and to support a few thousand
concurrent users out of the box.

Of course, scaling it past that will be a problem with Node being single
threaded and so on - but I believe that these are problems that Node.js will
eventually address.

------
didip
Everybody is angry if bugs keep punching them in the face. I get that. But
this post needs more info to be informative:

* If I read correctly, OP is using Chrome/V8 directly. I don't see if the bug list is on V8 itself or his bindings?

* "Callback Spaghetti". To each his/her own. I happened to read callbacks easier than other solutions. And this is coming from Python programmer, not JS programmer.

* The last 2 points are also information-less rants. What happened to HN?

------
jessedhillon
Here's my problem and why I don't care to use it:

It's a community built around an implementation of a language which they do
not control. Who is Guido or Matz in node.js? Ryan Dahl I suppose; does he
take requests or hold discussions concerning the future evolution of the
language? Does he issue any rationale documents concerning his language design
philosophy? Could he add multithreading to V8 and if so, why hasn't this
happened?

It's a community built around someone else's tool, and Google develops it for
entirely different reasons. Case in point, someone posted IcedCoffee, which
adds an "await" keyword to CoffeeScript -- you have to implement a compiled
language on top of Javascript to have the language features you need!

Finally, to preempt questions about my being concerned about other people's
language choices -- other people are choosing, inexpertly in my opinion, the
technologies with with I will contend in the future. Future employers may
value and demand experience in node, and future employees may have to be
disabused of bad habits accumulated during the learning of it.

~~~
chc
This comment is just wildly off the mark. You're comparing a framework to a
language. DHH can't add features to MRI Ruby any more than Ryan Dahl can add
features to V8 JavaScript.

~~~
jessedhillon
Off the mark? Perhaps. Wildly so? Unlikely.

But if that's so, then simply view this as an explanation for why I don't use
server-side Javascript. And Node is still a tool built around a language
implementation which is going in a different direction from where a server
side environment/general-purpose language needs to go.

~~~
chc
You're welcome to use whatever you like, of course — I'm just saying that you
haven't really raised any specific objections that couldn't be (and haven't
been) leveled against most other languages. Ignoring the confusion of a
language and a framework, so far, your concrete objections seem to be:

• Node.js is a framework built by people other than the language's core
maintainers (which is true of most frameworks)

• If you want to add fundamental language features, you can't just force it
into the core implementation, but will have to implement your own offshoot
(which is true of most languages, including, for example, Clojure)

If you're really concerned about other people's language choices, you're going
to need concrete reasons, not just generalities, vague insinuations and your
own personal preferences.

(Edited a bit to clarify and because the original phrasing sounded more
combative than I intended.)

~~~
jessedhillon
No, there is no language v. framework confusion on my part. What I'm arguing
_is_ a concrete, fundamental fact that pertains to both the framework and the
runtime.

I'm not sure what I can do to clarify the point anymore: the V8 engine is
created and maintained for the purposes of speeding up a web browser's
processing of Javascript within the context of an HTML document. The goals of
the team implementing the runtime are not to create a general purpose
language, they are to create an engine which excels at one specific use case,
and granted this use case is broadening over time.

But to address your point: yes, the developers of Pyramid (to take an example)
have not to my knowledge submitted code to e.g. optimize networking
functionality in core Python so that it better suited their specific needs. On
the other hand, the Python team has had an excellent track record in observing
and adapting to trends within their community -- the introduction of WSGI is
one such example.

The Python community has a PEP process for generating discussions about what
the language needs. To my knowledge, there is no discussion within the V8
developer community about how to make the engine more suitable for server-side
programming. And how would you begin the process of adding general programming
features to the language itself? Join ECMA?

 _If you're really concerned about other people's language choices, you're
going to need concrete reasons, not just generalities, vague insinuations and
your own personal preferences._

Excellent editing. Much less combative.

EDIT: Actually I'd like to add a couple more things:

 _Node.js is a framework built by people other than the language's core
maintainers (which is true of most frameworks)_

That is not a point of contention. That is a simplistic reduction of my point
which conveniently serves your argument.

 _If you want to add fundamental language features, you can't just force it
into the core implementation, but will have to implement your own offshoot
(which is true of most languages, including, for example, Clojure)_

This entirely misses the question -- why use a language whose core feature set
does not cover your use cases? Why use a language where you _must_ extend the
language to get fundamental features? Moreover, no you will not have to
implement an offshoot to get core features. At the risk of repeating myself:
when you have control over the direction of the language's evolution, you can
petition and propose changes.

~~~
chc
With regard to getting changes made: Both V8 and the ECMAScript committee have
development mailing lists and issue trackers where you can submit and discuss
suggestions. AFAIK, this is basically the same way Ruby operates. They aren't
likely to make vast, crazy changes, but I don't think, say, a PEP for static
typing would get very far either.

And I think it's kind of a basic misconception that V8 is made just with web
browsers in mind. If you look on the V8 developer site, nowhere does it say
anything close to that. Their stated objective is "fast execution of large
JavaScript applications." They go out of their way to draw a distinction
between the browser and the engine, explaining what is and isn't part of
JavaScript (e.g. the DOM is just an interface that browsers choose to expose).
Is Chrome the original client for V8? Sure. And shell scripts were the
original use case for Python. It seems to me that "V8 is just a browser
language" is the new "Python is just a scripting language."

And I wouldn't describe the language-level ability to write asynchronous code
in a synchronous fashion a fundamental feature. It's really cool and allows a
lot of expressiveness, but so would a lot of potential changes in, say, Ruby.
If you don't want the language feature, there are really nice libraries that
get you most of the way there. (And I don't really see how the existence of
CoffeeScript or ICS is any more an indictment of V8 than the existence of
Scala is of the JVM. Choice is a good thing. Lots of people prefer vanilla
JavaScript.)

------
antrover
It's posts like this that make me embarrassed to be a programmer. The author
basically states, "Node.js is not a good fit for my company, therefor everyone
using node.js is wasting their time." It's generalizations like this that just
blow my mind.

I don't go around saying, "Snickers is the worst candybar, therefor anyone who
eats a Snickers is wasting their time."

I bet the author is not a pleasant person to work with.

------
virmundi
I guess it depends on what I how I want to do my life. If I want to live my
life by learning new ideas and using those ideas for something tangible,
Node's a pretty good choice. If I want to live my life as a person with a
particular language/architectual ideology, then anything that is not in that
world view is wrong.

I like node for system level scripting. I find bash annoying and non portable
to windows. I really don't want to have to learn batch scripting for dos on
windows. But I can use JavaScript with node to script in both environments.

On the server I think that node might be helpful for certain network level
tasks. But I haven't used it for much. But honestly what type of person would
I be if I don't even consider it? The OP seems to be making an emotional
decision rather than a technical one. Interestingly he's using Scala. There
are many similar posts about Scala being the wrong way to do life. I just
can't agree with any of those views.

Finally I wonder what the value is for these rage posts. They just seem to
further divide people. I do see the value in the posts about I've used node
for X months, here's my thoughts or here's why I'm going back to X paradigm.
But just a rant where faces should be punched seems out of place for HN.

~~~
brunoc
If you like Node for system level scripting, you're gonna love this:
<http://www.jsdb.org/>

Don't let the name fool you, it's not only for databases. I would say that
it's probably more suitable for general purpose scripts than Node, though some
of the APIs are a bit clumsy.

It's not open source, but it's free and cross platform and actually pretty
good for a lot of general purpose scripting. Seems that it is developed by a
single guy. I found out about it a few years ago and used it to get some
things quickly done.

------
hello_moto
Article like this needs to be sliced-n-diced in different ways:

1) If you don't know technology X and use it due to hype, you deserve to get
burned

Let that be a lesson for anybody.

2) There's no silver bullet

Choosing node.js over web-framework just because you want the front-end and
the back-end to use the same code-base is to trade one feature for another:
Ruby and Rails still have better tools than Node.js while you get JS all over
the place (assuming you're good with JS).

3) Complaining about the language is a sign that you have no clue

I used to think that Java is better than some of the hype dynamic languages
out there but I was wrong: Java is better for ME because I _KNOW_ Java Better.
If I know Ruby more than I know Java then Ruby is better than Java FOR ME.

4) Don't program using another language's idioms

This is documented left and right already. If you use technology X, find best-
practices for technology X. Don't just apply best-practices from technology Y.

<http://dirtsimple.org/2004/12/python-is-not-java.html>

Or some of the comments here about Dependency Injection (which is quite common
in Java but not so in Python/Ruby).

In the past, I had one instructor that noticed that my QBasic code looked like
Fortran. He asked me if I knew Fortran beforehand and I told him that I've
taken Fortran before this class.

People see and notice.

------
jconley
Node enforces a programming model that puts you down the path to extreme
vertical scalability, you know, actually using all the hardware you are paying
for. CPUs and the kernels that manage them are good at running code. They suck
at waiting for things to happen.

Out of the box the callback model can be difficult to wrap your head around.
But if you are serious about writing a vertically scalable IO-bound service,
it is currently the only option. There are some add-ons to make the code less
ugly, but you still have to have the mental model down.

It's a lot like multi-threaded programming, or functional programming. It's a
matter being able to visualize the flow and pass context around. This takes
time to change the way you think.

If you approach problems in Node like you'd approach a problem in a functional
language the spaghetti of callbacks becomes much less of a burden.

For the async haters out there operating at scale. How many of you have farms
of machines with idle CPU's, maxed out memory, and practically idle network
interfaces? Yeah, I thought so.

------
tingletech
Node is not for every use case,

This tech talk on node is pretty interesting

<http://sna-projects.com/blog/2011/08/nodejs/>

I watched it last weekend, and from what I understood/remember from the talk
the reason the node people picked javascript was not because they liked
javascript. It was because they wanted to do async programming, and they found
other languages had too much synchronous baggage. In javascript, node.js could
start from a clean slate and build a pure async culture and environment.

------
brianshumate
The problem I see with all these kinds of negative posts concerning Node.js is
that they essentially boil down to "this is so radically different and
uncomfortable to me that it cannot possibly be good for anyone else." and do
not provide any concrete business examples of why it should be avoided.

Until I see an actual example of how "Node.js crashed my business, cost us N
dollars, and here's exactly how...", I will continue to look at such posts as
developers complaining about having to learn to do things a new way —
something that has been going on since there were developers.

------
robinduckett
I have to agree with the rest of the commenters here. You make a blanket
statement about something you've obviously never used. You're leveraging
hearsay and third party complaints against a framework and language that you
don't appear to be overly familiar with.

------
hamidpalo
The spaghetti code of node.js callbacks is really a problem of Javascript
lacking monads, and in this case something like the Async monad from F#.

TameJS is a step in the right direction by adding a C#-style await.

------
jdelsman
His comment about node.js only being able to use a single core is bullshit,
and has been for a while:

* Before native support: <https://github.com/learnboost/cluster>

* Now, native: <http://nodejs.org/docs/latest/api/cluster.html>

------
bunderbunder
I've got my doubts about Node.js, since it seems like rather a one-trick pony.

But it is a good trick. Node.js deserves credit for calling attention to an
underappreciated design pattern that has a lot to offer in certain
circumstances. (Personally I think the .NET team hit the nail more squarely on
the head with TPL, a pony that can do that trick as well as many others. But
.NET doesn't have the sex appeal it takes to be a spokesmodel so meh.)

Javascript isn't my favorite language, or the most performant one. But as a
"Lisp with C syntax", on a semantic level it's much better suited to the
higher-order programming techniques that the pattern requires than most other
popular Web languages are. Ruby also has the right features, but it isn't
exactly the poster child for high-performance computing either. Might as well
flip a coin, because either way opinionated folks with blood pressure
conditions will call you an idiot.

------
crazygringo
Programming with Node's async model makes it extremely powerful and fast to
run database queries and file functions in parallel, but the downside is the
potential for huge callback spaghetti indeed.

But the callback spaghetti problem can be largely solved by dropping in, for
example, the IcedCoffeeScript fork:

<http://maxtaco.github.com/coffee-script/>

Or the previous JavaScript TAME functionality:

<http://tamejs.org/>

There are of course many other async helper solutions as well, and if you're
doing serious Node development, it's kind of insane not to use one of these.

~~~
MatthewPhillips
If you expect a lot of callback it makes more sense to design that
functionality as an object rather than as a single function. That way you can
spread callbacks over many functionality and still maintain modularity.

~~~
crazygringo
Not necessarily -- the issue is not so much code modularity as much as
control-flow issues, which separating out functions (mandatory) doesn't
necessarily help with (because of all the flags of what function should call
what other function afterwards, etc.).

------
libria
I haven't used node.js before, but I see 2 main points being made about it, by
proponents and detractors respectively:

* It uses non-blocking evented IO so it can scale well.

* It is single threaded so it can't scale well.

Someone teach me: which of these statements is true?

~~~
ender7
Neither are true.

Non-blocking evented IO is mostly attractive from a usability point of view:
it's much easier to write programs that aren't multi-threaded. It can also use
much less memory than a threaded model _in certain situations_.

Non-blocking, evented systems tend to be single-threaded. Single-threaded
systems don't automatically scale across multiple cores. To scale, you spawn a
separate process for each core (for example, this is the suggested practice
for node). You must then find some way for the different processes to
communicate with each other, which is usually through a database (or some
crazy pub-sub thing).

Node can scale just fine if you design your program to do so. It just scales
in a different way.

~~~
marshray
Personally I love it, but some programmers find non-blocking evented "async"
IO completely counter-intuitive. So it's debatable on the usability.

Async IO is an absolute win from the scalability perspective because it allows
you to service a great many clients with many fewer threads. OS thread context
switches are relatively expensive. Ideally you would have exactly one OS
thread per physical core and they would never need to block on exclusive
access to any shared resources.

Now that we have a system where the user code inside the async handler doesn't
need to manage exclusive access to anything, from the usability perspective it
can has some of the simplicity of code that is fully single-threaded. But
that's subtly different from saying ASIO makes it easy.

My guess is that many of the same programmers who aren't comfortable writing
multithreaded code aren't going to find it completely intuitive to rethread
their stack around an ASIO model.

------
bryanh
Nonsense. Perhaps your choice to use Node.js is suboptimal? That isn't an
indication of Node.js's quality, it's an indication of your inability to
choose the right tech. People choose tools that make it easier to do
something, Node.js accomplishes that for a wide range of tasks.

I just spun up a IM API we needed in an _evening_ thanks to Node.js and
community contributed packages. It's humming along great, I even wrote up a
piece about it: <http://news.ycombinator.com/item?id=3547664>

------
sktrdie
It seems to me like the author overly cares about languages, when the power of
Node is the community and its simplicity of use - there's very little
boilerplate even for complex things like network programming.

Who cares about the language. Use JS if you want, or use Scala. At the end of
the day is the maintainability of the product you're developing that matters.

I feel, for example, that NPM is much easier and simpler to use than something
like Maven. If it makes my life easier, I'll stick with it.

------
chrismealy
"The Ruby and Python communities are just now, many years after the hype has
faded, learning that stuff like dependency injection and proper modularization
are actually good things"

WTF?!

------
Kilimanjaro
Node solves a problem I don't have in a so convoluted way that if I ever have
that kind of problem I won't be using node for sure.

Is there a need for webstackers to go play at the server side? YES! but node
is not THE solution, it is just ONE solution. I venture to say, as javascript
evolves more towards a coffeescript flavor, then a coffeescript flavor on the
server is what is needed.

And I'll support something along these lines.

------
mustardamus
If you're using [your fav framework], you're doing life right.

Just use it and see if it works out for you.

------
lightblade
All the points that OP mentioned, whether they are correct or not, are
irrelavent.

The only factor that drives technology success is the people, aka the
community. There are a lot of people on board of nodejs. This just creates
more gravity and pulls more people toward it. Together, the community will
carry the momentum that drives its success. If v8 is not server technology
like OP said, there are enough open source developers to make its on fork.

------
steele
Never take life advice from someone who responds to hype with a compulsion to
"punch faces" while donning "rageface". To be fair though, I bet this is just
a casual blog entry that the guy didn't know would hit HN.

<http://meyerweb.com/bkkt/okaythen.gif>

------
gumbo
Please give me a break. This guy made some points: spaghetti code, .... He
state it in the wrong way, however one should admit that node.js is not mature
enougth for many use cases. I'm still learning but, haven't seen how just by
using node.js you get a scalable server.

------
rdouble
I recently evaluated Node and Scala for a presence server for an iOS app. With
my naive understanding of both platforms, it was way easier to do this with
Node. It would be interesting to hear more detail about how Scala was used and
why it was better.

------
IsaacSchlueter
This is hilarious.

------
Lazare
Okay, let's play a little game. I'm going to describe a scenario (using
Python; feel free to substitute the equivalent Ruby terms if that makes it
more relevant for you).

You're a pretty good Python developer. You know, and feel comfortable with,
not just Python, but the entire ecosystem. Virtualenv, pip, the whole nine
yards. And now you're working on a really nifty Django app, maybe a CRM or
something, when you realize...

...damn. This app really needs a lot of functionality ripped out and shoved in
the browser. I'm losing my marbles writing spaghetti jQuery code, but what I
really need is some client side templates.

So you poke at it, and think about it, and you realize that the proper design
of your app is _really_ a bunch of client-side code using Backbone, and a
server that just handles authentication and is otherwise a thin RESTful
wrapper around your database.

Great! But at this point, most of the actual code you will be writing is
Javascript. Your server could be written in, practically, anything. And
there's some compelling reasons to leave it in Python. On the other hand, if
you switch to node.js it means all your code is in the same language (which is
nice). It also opens the door to being able to use the _same_ code on both the
client and the server - which is really good. Client-side templates are nice,
but being able to render them on the server when you need to is practically a
requirement. And Python's support for rendering Javascript templates is very
limited. And if you're a Python coder, you'll probably want to be writing your
client in CoffeeScript anyhow, which requires having node.js installed, so, at
least for development, just have the whole damn stack in node.js. You can
always hack together a little RESTful server in Python later if you decide
that node.js isn't right for production.

Seems simple enough, right? And as you can probably guess, I just went through
this process. And so now we have this blogpost, which is saying...well, it's
not really clear what it's saying. That I should be using Scala, I guess. This
is, frankly, so wrong it's embarrassing.

1) Even if the JVM was just so amazing and awesome, I'm not a JVM developer.
The ecosystem is radically different. As a Python developer, I'm able to
install, configure, and be productive with node.js very quickly. npm, nvm,
coffeescript, and we're away. My IDE of choice (PyCharm) even supports
CoffeeScript. There is very low impedence. Switching to Scala...where would I
even _begin_?

2) I'm doing this because I need to write a client side app. That must be
written in Javascript, or something that compiles to Javascript. Scala is
neither. And while there are JVM language that _do_ , there are some major
concerns with their suitability, maturity, and tooling. Clojurescript looks
great, but it's not something you pick because you think coffeescript is too
new and little used!

3) The rant would be more compelling if the author came across as someone who
actually knew anything about Python, Javascript, or node.js. Contrary to his
assertions: Javascript does have namespaces. Python and Python developers have
ALWAYS been convinced that modularity is good. And Python developers are still
quite aware that dependency injection is a way to solve problems with the
design of Java which aren't even relevant to their language of choice.

4) Also, if you don't grok callbacks, it doesn't _mean_ you are a bad
programmer. But it might be worth keeping in mind that there are plenty of
programmers who do, and they're going to laugh at you when you reveal you
don't. Not to mention that there are plenty of ways of programming in node.js
WITHOUT callback spaghetti, and revealing that you have no clue about the
framework your slagging is not going to improve your credibility.

5) To continue the theme, insulting a framework for not scaling well may work
better if you don't reveal that you don't know how it scales in the same
paragraph.

~~~
curun1r
Two points for you: 1) CoffeeScript does not require Node...npm may make it
much easier to install, but you can definitely run it without installing Node.
We run the compiler as a Maven plugin, but it's distributed as JavaScript and
all you need is an interpreter. 2) There are templating languages that have
interfaces in both JavaScript and other languages to allow the same templates
to render on both the client and the server. We use Java on the server, so
we're looking at Closure Templates, but for Python, you might want to look at
Mustache.

If you've already finished your project, I'm not going to try to convince you
to move away from Node, but if you've got a lot to do still, you might
consider sticking with Python. I'm not saying that Node isn't a workable
solution on the server side, I just don't think it's proven that it is the way
that Python and other, more mature platforms have. I don't give too much
credence to inflammatory posts like the one being discussed, but when I see
posts like: <http://news.ycombinator.com/item?id=2519674> from a developer I
respect, it gives me pause. That post is 18 months old now, so the situation
could have changed.

There's something to be said for building things you know are rock solid and
won't result in 2am notifications. That's my perspective, so I try to stay
away from the bleeding edge. For stuff that's not critical, I'm more ok with
taking a few risks. But someone's got to be the one that takes those risks in
a mission-critical environment to figure out which of the new technologies
will become proven and which will fail, so I disagree that these people are
doing life wrong. If it wasn't for people like them, my way of doing life
right wouldn't work.

------
eliaskg
What's the problem if someone creates great stuff with it?

------
alexchamberlain
Glad to see someone has been brave enough to come out against this. I too
don't like Node; JavaScript was never designed to take on this sort of load.

------
EhevuTov
Certain tools are used for certain jobs. Node.js is a different tool and I
welcome it. I don't curse a hammer because it is not a screwdriver.

------
skrebbel
I love articles like this. All the dry analyses, the subtle counter-counter-
arguments, that the usual tech opinion articles on HN have make me nuts.

The little layer of emotion and drama added here gets the point across much
better, IMHO. Of course it doesn't do anything but preaching to the choir (hi
there), and not convincing anyone not already in the choir, but it's a great
read! (and so is this thread).

In other news, if you're voluntarily using a dynamically typed language and an
editor without an integrated debugger, you're not fit for programming!

------
nathanwdavis
Wow, this guy seems like a very angry person.

------
mnot
Wow, seriously? This is just as bad as the fanboy "you'll use X for
EVERYTHING!" posts. Please.

------
dhconnelly
different tools for different jobs

------
aiscott
From the article: "The hype around Node.js on this issue makes me want to
punch faces."

"But the kind of misunderstanding going on in this video clip seems to pervade
the Node.js hype and gives me rageface."

This seems like a really over-the-top response to people that have a differing
opinion. I can't take the rest of his post seriously after reading these
parts. This certainly isn't the sort of thing you read in an informed opinion
piece.

~~~
Zancarius
That's also what I took away from it. Aggressive writing, insults, and
condescending tone isn't a way to win friends and influence people--except,
possibly, those who already agree (judging by the HN comments).

He seems to have some valid criticism, but I can't say it's anything I've
heard before. If anything, the article itself is flamebait and at least partly
intended to troll.

After browsing through the comments here on HN, I think he succeeded. But
then, everyone likes a good flame war once in a while...

------
funkah
Node seems unnecessarily complicated and faddish, but if you really want to
mire yourself in callback soup then go ahead. I'll just be over here, not
tearing my hear out.

------
indutny
You're just using it wrong

