
Node.js - Convincing the boss guide - neovive
http://nodeguide.com/convincing_the_boss.html
======
DanI-S
Here's something oft-understated:

As a web developer, you sit on the intersection of engineering, design and
art. You're lucky enough to live at a time where there are numerous
production-ready tools with which to do your job. If you choose a tool that
you're excited to explore, with an active and fast-moving ecosystem, your
excitement and enthusiasm will make you happier and more likely to do a better
job.

Someone down the thread said this:

> So far I don't see any benefit in node.js over mature enterprise frameworks.

If I was only allowed to work in ASP.NET, I'd be looking to change careers
pretty fast.

Don't underestimate the value of enthusiasm - especially if you're a boss.

~~~
javajosh
"Excitement and enthusiasm for something _new_ " was left off that list for a
very good reason: it's a _terrible_ reason to pick a technology like node (or
anything else).

In fact, I'd go so far as to say that enthusiasm for mere new-ness is one of
the more pernicious, counter-productive parts of modern hacker culture. Rich
Hickey implied this at his RailsConf keynote when he talked about how great we
are at judging benefits, but terrible at judging trade-offs. Here's a man
who's certainly not afraid of newness itself (I mean, he single-handedly
released a new JVM hosted LISP) but I think he has his head in the right place
about the cost of new, and what something must provide to justify that cost.

For example, it makes absolutely no sense to use Node and then layer on top of
it a web framework that is an isomorphism from some other environment.

Last but not least, I think the key reason we have different perspectives is
_age_. Hickey and I are about the same age. I assert that anyone who trumpets
the inherent value of "new" hasn't been around long enough to understand that
there is a never-ending stream of new things and that, as Teddy Sturgeon
famously quipped, 90% of everything is crap.

The real market for technology adoption should fueled by demand for
simplicity, rather than demand new-ness (something else Hickey strongly
implied in his talk).

~~~
DanI-S
I carefully avoided making the statement you've just deconstructed. Nothing in
my original post mentions newness.

The point I made is that enthusiastic and excited developers are valuable.
Developers tend to find learning exciting. They could be interested in
learning Rails or Django for the first time, trying out Sinatra when a full
Rails app seems overkill, or exploring Node for a small and non-critical part
of your architecture. Hell, they might be excited about learning PHP.

Allowing people to explore their curiosity brings material benefits. It
doesn't have to involve new technology, and I didn't suggest that it does.

As an aside:

> The real market for technology adoption should fueled by demand for
> simplicity, rather than demand new-ness

I think part of node's mass appeal is that it has introduced an element of
simplicity to a generation of developers who have grown up around bloat.

~~~
jshen
If only a group of more than 5 developers were enthusiastic about the same
thing! Your enthusiasm for node is another persons pain. I've got 1 coder
enthusiastic about node, another for clojure, and another for scala. Should
every project be a different language and ecosystem? What happens when
programmers move around in an organization.

"I think part of node's mass appeal is that it has introduced an element of
simplicity to a generation of developers who have grown up around bloat."

Who are you talking about? Right now I'm dealing with a generation of
programmers that came up on ruby. Node isn't simpler than sinatra. In fact, we
just tried to use node for a "small and non-critical part of your
architecture". You know what happened? It took much much longer to finish
because it needed to talk to an API that uses digest authentication and node's
http library doesn't support that so we had to roll our own.

~~~
rachelbythebay
Does node let you use things like libcurl? I only ask because there are
libraries which already have that implemented. I don't use node so I have no
idea if it can hook into system-level stuff like that.

~~~
jshen
The difference is that it's a 5 minute thing in ruby with any of the major
http libraries. Is libcurl evented? No matter how you slice that cake, it's a
lot more than 5 minutes of effort.

------
tzaman
Don't use Node if you have a lot of CRUD, because you'll still have to do a
lot of stuff manually. Node's ecosystem is relatively young which means you'll
have to do a lot of manual labor (as opposed to something like rails and
mature, production-ready gems) and stitching of components. It cat get messy
rather quickly, so my advice is "the right tool for the job".

These guys nailed my point pretty good:
[http://www.perfectline.ee/blog/optimizing-ruby-on-rails-
appl...](http://www.perfectline.ee/blog/optimizing-ruby-on-rails-application-
with-nodejs)

~~~
tferris
I have to disagree. I understand that you can get quickly the feeling that you
have to do a lot of stuff manually with node because node packages (gems in
node) are more kind of atomic and not full-blown like rails. You can quickly
setup a rails-like-environment with node packages. There are different web
frameworks which are a refreshing take compared to rails and provide same or
better functionality. ORMs like ActiveRecord for SQL DB are available as well.
Deployment is easy and the overall ecosystem reflected by npm (node packet
manager) is very advanced and brings some innovation into this space (compared
to rvm/rbenv).

~~~
tzaman
Prove it:

What is node equivalent of: "rails g resource User email:string
password:string"? AFAIK there is none. At least not one that would take care
of migrations, validation, security, logic and views.

And if I want to use postgres? Sure, there's a npm package. But it's for
queries, I still need to define models and validation manually.

....

~~~
tferris
as spyder posted there are npms providing this functionality. there are 8,000
packages for all your needs.

But the point is another: the npm world is much more modular than the Rails
mononblock, there is _much_ less magic involved. You setup your own stack
which is simpler than setting up Rails, rvm, gems. Rails isn't bad—it's great
but getting off track or looking behind the magic can get a tedious task ...

~~~
danneu
There really isn't a Rails vs Node dichotomy, though. More like Sinatra vs
Express -- you can write glue code in the Ruby ecosystem as well if that's
what you want to do.

You use Rails because you want and understand the magic, not because it's
magical. You might be initially allured by the terseness of Rails, but the
learning curve of what Rails is doing is why you use robust frameworks in the
first place -- because you want shortcuts and optimize away from trivial
things like form parameter passing and route generation. Learning what
`resources :topics` does is "tedious" in a much different way than the tedium
of scoping out:

    
    
        app.get '/topics'
        app.get /topics/:id'
        app.del ...
        ...
    

Because then you see an npm package like `express-namespaces` that lets you do
this:

    
    
        app.namespace '/topics', ->
          app.get '/', ->
          app.get '/:id', ->
    

And after a while, some people agree to consolidate this into:

    
    
        app.resources 'topics'
    

And soon a part of the community decides that they might prefer these sort of
conventions and it becomes the seed that blooms into a robust framework.

...And then another part of the community will complain that it's "too
magical" while I do the Jackie Chan 'wtf' gesture because there's a crystal
clear API and they'd rather form a Cloud Chorus against alleged "magic" than
humbly accept that they might not appreciate the same things that other people
appreciate.

------
hamidpalo
Why is non-blocking IO radical? Tons of libraries and frameworks offered it
much before node, including twisted, Java's NIO, and the entire System.Net
namespace in .NET.

Other than that, surprisingly sensible advice.

~~~
jbooth
It's not radical, it's just occasionally more confusing than blocking io to
implement, and doesn't really have any performance benefits in the multicore
world.

I'm actually using node for a side project right now as part of re-learning
web development (been back-end the last few years), and using javascript as a
client language, server language, and db query language via mongo is a neat
environment. Also, npm rocks. But don't listen to anyone who tells you they
use node+mongo to handle their WEB SCALE PERFORMANCE. If they really had that
problem, they'd be better off using the java ecosystem or, if they really
wanted to go hardcore, using a lot of C. But Java's unfashionable and C's
ridiculous to write a web app.

~~~
mcantelon
>doesn't really have any performance benefits in the multicore world

AFAIK, Node's cluster API, which can spawn workers for each of a machine's
cores, will, when delegating requests to a worker, factor in OS-level core
utilization info.

~~~
jbooth
From what I could tell, that spawns actual child processes and communicates
with them over pipes. Fine from an architectural standpoint, but a penalty
compared to shared memory from a performance standpoint. And it still has the
problem of a single heavy CPU request on a given worker blocking all the
requests behind it on that worker.

Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying
if you really need to crank out performance, use java.util.concurrent, or
maybe Go. They both offer event-driven i/o if you really want it, and have
better threading models.

------
cageface
Go seems to me to provide the benefits of Node's non-blocking IO with a much
easier programming model and a much less warty language. But I haven't
actually built anything real in either language yet.

Anyone with experience in both care to contrast them? Their problem domains
seem to overlap quite a bit.

~~~
dsl
We did some bake-offs with node and Go (and other languages of course). Go won
pretty much across the board, except in the time to write category.

The other big downside to Node is hiring. You have two types of "JavaScript"
developers. People good with JQuery, and people who have written JavaScript
books. There is extremely little middle ground from which to hire good to
awesome developers.

Go is the C replacement. Node.js is going to be a Ruby replacement one day.

~~~
cageface
Interesting. My own limited experience with Go suggests that it requires more
time to write but less time to test and debug and tune so it might b a wash
overall. Where did you find you were spending most of your time?

~~~
dsl
What I meant was that Node is super fast for cranking out proof-of-concept
stuff, and that was its big win. When it got down to trying to close the
performance gap between Node and Go (an order of magnitude requests/sec) we
sunk a lot more time into Node unfortunately.

~~~
cageface
That jibes with my intuitions after looking briefly at both of them. Node
seems like it would be quick for quickly banging out prototypes but I can
imagine that all the other metrics might tilt pretty quickly towards Go.

I've recently rediscovered the joys of static typing so that alone inclines me
much more toward go.

------
arturadib
> _Bad Use Cases: CPU heavy apps_

I wouldn't say that Node (i.e. V8) is a bad use case for CPU-heavy apps. In
math/statistics for example, V8 stacks up well against other scripting
alternatives. See e.g. the benchmarks here:

<http://julialang.org/>

Of course it's still not as fast as C++, but not terribly off either. Expect
dramatic improvements here thanks to the push for making web apps faster.

~~~
jbooth
In that example, V8 javascript was 400x slower than the alternatives for
matrix multiplication. That's because it's not binding to the BLAS libraries
like the 'real' statistical languages. Of course, node supports calling out to
C APIs, but that's not an argument for javascript, dynamic languages will
naturally be terrible at math compared to C.

More to the point: Node does nonblocking i/o but cpu work is in fact blocking.
This means that a CPU-heavy request queues up all requests behind it, waiting
to get access to the CPU. You're better off using a threaded architecture for
CPU-heavy work.

~~~
arturadib
That's silly. No one in their sane mind would serve web requests AND do heavy
processing in the same thread - no matter what language.

In Node, you would have a process responding to web requests, and launch a
separate process -- via a convenient child_process with built-in pipe
communication -- for doing the heavy CPU work.

The only case where that wouldn't make sense is if you need BOTH a ton of
concurrency AND heavy CPU work. In that case, threads would make sense as they
would be cheaper memory-wise. But my point remains: CPU-heavy applications
don't necessarily rule out Node as a feasible alternative.

PS: V8 was 40x slower, not 400, in that one benchmark result you picked.

~~~
jbooth
Well, in Java I serve rpc requests and doing heavy processing from the same
thread all the time, and it works great.

What would we have to do in node to get the same level of performance? We'd
need a front end instance delegating requests to 8 back-end instances for each
core? Writing all these bytes over internal pipes and blowing L1/L2 cache all
the time as the data moves across cores? At a certain point, isn't it just way
easier and more effective to have one thread spinning an accept loop and a
threadpool handling the requests, all within one process bound to a port?

As I said upthread, I'm using node for a side project right now and I'm liking
server-side js for a variety of reasons, but squeezing every cycle out of the
CPU is not one of them.

------
pjmlp
So far I don't see any benefit in node.js over mature enterprise frameworks.

~~~
famousactress
That's funny, cause I'd prefer literally anything that isn't called an
enterprise framework.

~~~
wolraf
Bash cgi?

------
hack_edu
Lately my problem has been convincing my boss NOT to use Node on every little
project. Don't get me wrong, Node is versatile and fun, but not the most
appropriate choice for systems work and your usual DevOps tools.

To him, any little one of script written by the team (except his own) must be
re-done in Node. Then, the code being "his", he'll upload it to his own
personal github account. Meanwhile, we have to reimplement the new Node
written tool.

------
dylanz
"So don't try to build hard realtime systems in node, that require consistent
response times. Erlang is probably a better choice for these kinds of
applications."

Erlang is actually suited for soft realtime systems as well. I've never seen
it recommended for hard realtime systems.

------
j2labs
I love that this started with bad use cases.

------
jroseattle
We're running a nodejs+nosql+js-heavy-client project right now. While
evaluating any stack component is an important task, it is certainly more so
important in this environment.

This guide is OK, but it's insufficient. If you're going to do a technical
evaluation of the node/nosql/js-client stack for risk assessment, you're going
to need to get much more granular than what this guide offers. This is a fine
guide for a project lead, but this is somewhat useless for the system
designer.

For example, in reference to "nosql+node+buzzword+bull$#!t", the advice is to
use nosql when you "really" know it, otherwise stick with mysql/postgres.
While the devil-you-know-vs-devil-you-dont is a fine project mitigation
strategy, it's not a very good technical strategy. Maybe the guide's author
assumes one would do so, but the nosql/rdbms comparison exercise is not
trivial and requires you to do your homework. Understanding and contrasting
the finer points of comparing nosql operations vs. relational data stores is
much more useful than a blanket comment.

Like I said, it's a fine guide, but it's much more useful for those who aren't
necessarily responsible for determining the stack's applicability to a given
project.

------
hsmyers
JavaScript seems to be having the same problem that other languages have
developed over usage time. It becomes increasingly difficult to know what
package does what and more importantly information of the pros and cons of the
package. Does anyone know of a link to something similar to what I'm talking
about? Say something meaningful about the top N (where N might be 10 or so)
packages---what they do, the good and the bad?

~~~
mnutt
Check out the Node Toolbox: <http://toolbox.no.de/>

It doesn't seem as fleshed out as the Ruby Toolbox (<https://www.ruby-
toolbox.com>) and could use a bit more editorial for your purposes, but it's a
good place to start.

~~~
bmelton
Thanks a ton for posting that. I'm new to Node, and it's a great help.

Of course, it'll never go anywhere until whomever is maintaining it either
allows for crowdsourcing of the data or tries harder, because the first couple
of packages I looked at had very poor descriptions.

Coffeescript, for example, is defined as "Unfancy JavaScript". CS is one that
I happen to know about, and by that definition, I'd have never ever switched
to it.

------
daemonza
I seriously think Node.js is one of those things that get's overhyped. Yes
it's fun to code...until the nested callbacks get's too much. For me
personally I will stick production code with ruby/sinatra and eventmachine and
play with node for personal projects.

------
neovive
Somone is proposing Node.js for a project and I was wondering if the
advantages/disadvantages in this article are still current. This is for a web
application with lots of CRUD, but will also require a custom JSON API.

~~~
jerf
There are tons of existing fast, mature existing options that do great CRUD,
JSON APIs (they might call it "REST"), and even have some integration between
the two. There's no compelling reason to go with something like Node if that's
your use case. That's not so much because Node is intrinsically bad at such
things as that the things that it was relatively good at were not that, so the
focus hasn't been on that use case. Displacing the existing incumbents in that
space would be an incredibly tall order.

------
c10n_2
The usecase of building JSON api servers are often used. Can someone give some
examples of node JSON api implementations?

~~~
jedschmidt
I recently built SAJAK (Simple Authenticated JSON API Kit) to suit my own
needs: <https://github.com/jed/sajak>

~~~
Sivart13
Good name.

------
Sivart13
The table of contents at the top of this article makes it look 10 times more
intimidating than it really is.

------
ChrisArchitect
this is great. in general, need more of these sorts of 'convincing x' guides
...purely for need for the right 'language'/points to convey benefits without
getting lost in tech/trendspeak.

