
Why Node.js is becoming the go-to technology in the Enterprise - ghalusa
http://www.nearform.com/nodecrunch/node-js-becoming-go-technology-enterprise#.U3I50K1dWts
======
dang
This article is promotional fluff. It has also been submitted more than once
before. We're going to bury the post. Please don't post it again.

[https://news.ycombinator.com/item?id=7401564](https://news.ycombinator.com/item?id=7401564)

[https://news.ycombinator.com/item?id=7397637](https://news.ycombinator.com/item?id=7397637)

------
dubcanada
And then as soon as Derpys Mansion new language comes out all the newcomers
will flock to that and you're entire staff will leave to go work for some
startup.

The reason why "Enterprise" uses the software they do is not because it's the
fastest, or most suitable for the job. It's that it's been in production for
many years and has a large ecosystem and strong commercial backing. Along with
a strong workforce that isn't going anywhere.

Not that I don't think NodeJS awesome. The javascript language is just a bit
meh for Enterprise development. I'm not sure if you've ever seen "Enterprise
Javascript" but I sure as hell would not want to see "Enterprise NodeJS" I
would much rather see a strong typed compiled language that requires things to
be done a certain way. Rather then the clusterfuck of libraries NodeJS comes
with.

Just my 2cents...

~~~
twistedpair
Amen. I'd add that while JS is great for form validation, trying to make it
into a first class language is a bit laughable. For example, if you want to
define a function in a namespace, it's up to you which half dozen "patterns"
you use to emulate namespaces in the language that lacks them. Same goes for
private method/variables, continuations, classes... or more features of other
common language. Add to that the type coercion cluster and the ability for
attackers to redefine core language types (make 1 evaluate to false) and JS is
still a bit of a anything goes wild west of a language (first class functions
are fun).

FWIW, I've written a few 100KLoC of production JS code, but man, I'd really
rather use Java/C#/PHP as everyone in JS land has to bend over backwards to
try to have the features that are standard out of the box in other languages.

~~~
SideburnsOfDoom
> while JS is great for form validation, trying to make it into a first class
> language is a bit laughable FWIW, I've written a few 100KLoC of production
> JS code

Having written a few KLoC of js with angular.js and about the same in tests on
it, it definitely is a first class language now ... for the browser. On the
server, you have other better options with types, threads and the whole works.

Also, if you've _actually_ written over 100KLoC of javascript, then either you
work on high-end web apps for google and co, or you're coding badly wrong.

~~~
twistedpair
Various large enterprise one page apps mainly in ExtJs (i.e. 70KLoC per app),
predating the many new Xjs libs. Admittedly, they are likely terser these days
than a few years back. However, I like to stick to GWT now and write JS
compiler plugins to get the JS I need. :)

------
beering
These stories about switching to node are pretty funny: "I switched from a
dump truck to a motorbike and now I can drive way faster!" Node.js isn't
really faster than most other popular languages with an evented library, but
if switching to Node involves scrapping years of enterprise cruft, then maybe
it's worth it.

By the way, enterprise adoption of Node is surely a sign that we need to jump
ship. Glad I got out of Rails before enterprise adopted it!

~~~
kbanman
I don't think enterprise ever has or will adopt Rails. Even node.js isn't at
the point where it can really be considered "enterprise".

Java is dead. Long live Java!

~~~
jzumbrun
Paypal uses node.js extensively. [https://www.paypal-
engineering.com/2013/11/22/node-js-at-pay...](https://www.paypal-
engineering.com/2013/11/22/node-js-at-paypal/). They even open sourced their
implementation of it: [http://krakenjs.com/](http://krakenjs.com/)

------
wasd

      > The old story of linkedin where moving to Node.js from Rails 
      > for their mobile traffic, reducing the number of servers from 30 to 3 
      >(90% reduction) and the new system was up to 20x faster.
    

It isn't as simple as that. There was a great article from a former linkedin
engineer about why the original API server was so slow. [0]

[0]: [http://ikaisays.com/2012/10/04/clearing-up-some-things-
about...](http://ikaisays.com/2012/10/04/clearing-up-some-things-about-
linkedin-mobiles-move-from-rails-to-node-js/)

~~~
awj
Yeah, of course the thing was faster. I would be upset if you _didn 't_ get
this result after rewriting from a crufty old system that was never intended
for the purpose it's serving into new code that uses appropriate technologies
and benefits from all of your experience.

Other than Rails vs. Node as an appropriate platform for proxying slow api
requests, the technology involved is basically irrelevant here.

------
chrramirez
Trying to sell Node using soft arguments: "Argumento ad populum" and
"Argumento ad novitatem", which BTW are fallacies. No technical arguments, no
polls, no facts. Just fallacies.

------
badman_ting
“Why go to Facebook and do PHP when you can go to PayPal and do Node.js”

Why choose the company you work for based on technology when you can choose
the company you work for based on the company you will be working for?

~~~
billmalarky
I thought that was pretty funny line as well. Say what you will about
Facebook, but next to Paypal Facebook looks like one of the most innovative
companies in tech. Who cares what you are programming in if the product isn't
exciting. Heck even Elon flat out called paypal a dinosaur recently.

------
yid
It's a little tiring to see some of the same old fallacies about Node repeated
ad infinitum in this thread. I suspect a lot of the complaints stem from poor
development practices or not understanding norms in JS.

JS isn't without its flaws, but can we at least put a few fallacies to rest:

> callback hell

There's no reason to be in callback hell if you use an asynchronous control
flow library and stick to the standard style of function signatures. I love
@caolan's async [1]. In particular, there's a control flow pattern called
`auto` that really (IMO) demonstrates some of the power of async programming:
it's a full dependency graph resolver [2].

> single-threaded

There's the cluster module, but nevermind that -- you can always just use the
child_process library [3] to access spawn() and fork(). Remember those?
Processes are a more nautral match for distributed computing than threads
anyway.

> lack of strict typing

Strict typing won't make you a better developer, and you can enforce some
degree of type correctness with Closure compiler annotations.

[1] [https://github.com/caolan/async](https://github.com/caolan/async) [2]
[https://github.com/caolan/async#auto](https://github.com/caolan/async#auto)
[3]
[http://nodejs.org/api/child_process.html](http://nodejs.org/api/child_process.html)

~~~
jerf
But... if you're going to bolt on an "async" library, bolt on threading, and
bolt on strict typing, why not use something that _starts_ with that stuff?
And ends up doing it better since it was actually created with that stuff in
mind, instead of aftermarket bolt-ons?

Saying that those things "fix" Node amounts to an admission that you shouldn't
have started with Node in the first place.

~~~
twerquie
Because bolting reusable libraries together is 90% (meaningless number alert)
of what we do when assembling modern applications. And in this respect, Node
is perfectly suited to the job, boasting

a) A small core API instead of a sprawling standard class library

b) A highly composable export and require mechanism, better in some
interesting ways than what exists in other systems (1)

c) The fastest growing and soon to be largest community repository of packages
(2)

d) asynchronous by default stack and ecosystem.

With those things in hand, "bolting on" is a virtue and not a disadvantage.
That Node is general-purpose - you can build cross-platform desktop
applications, streaming servers, web applications, console utilities, etc -
and does not impose its package opinions are major factors in its success.

1) [http://blog.izs.me/post/1675072029/10-cool-things-you-
probab...](http://blog.izs.me/post/1675072029/10-cool-things-you-probably-
didnt-realize-npm-could-do)

2) [http://modulecounts.com/](http://modulecounts.com/)

~~~
awj
Bolting reusable libraries together is great for some things, not so much for
others. How much of that large package repository uses different (or worse,
conflicting) solutions for abstracting async programming? Some batteries
really are better off being included.

~~~
jerf
And I'd observe that all three of the things I mentioned ("async", threading,
static typing) are _firmly_ in the "not" camp.

If the Node community admits these are desirable characteristics of a
programming development environment, then they've lost, because they can not
compete on any of those three fronts. The _entire value proposition_ of Node
was basically that those three things weren't important. If they are, Node's
arrogant swagger turns into a frantic attempt to cobble together enough
functionality to pretend to have the features that exist better elsewhere.

Don't think you can sell me on fundamental weaknesses in your language of
choice being features, twerquie. I've got too much experience in too many
environments to fall for that.

Why, it's almost as if Node is built on fundamentally 1990s scripting
technology based on fundamentally 1970s event-based ideas or something,
instead of being the radical revolutionary departure we all know it _really_
is.

~~~
twerquie
It is true though that many js deficiencies have turned out to be factors
contributing to node's popularity. A lack of namespaces, standard library and
import/require come to mind.

I'm not interested in arguing about technical superiority, I'm sure node is no
where close to ideal. But, like javascript itself, it's popular, interesting,
useful, and here to stay. From my perspective, for better or worse, javascript
is the most important programming language of the decade.

------
noir_lord
"the main backend node.js consulting company in Europe" asserts that Node.js
is becoming the go-to technology in Enterprise.

Provides a couple of big name companies and essentially zero evidence.

This is fluff at best.

------
SideburnsOfDoom
The article says "good developers like to learn new things and to use new
technologies" ... therefore the language that's briefly cool this year is an
_excellent_ bet for your enterprise's long-term future. Right.

~~~
antjanus
On top of that, "Killing legacy code and rewriting hacks into permanent
solutions yields speed improvements!"

------
bowlofpetunias
Somebody should start a "Vogue for Developers", so we can just stop
pretending. Most of this article and most of this thread is about fashion, not
technology.

But that applies to a lot of topics on HN.

~~~
VLM
Unfortunately its not a startup topic. Decades ago we used to absolutely dread
seeing a non-technical manager walk into a meeting with a copy of PC Magazine
or similar, knowing that we're about to be lectured about "how it really is"
and "the right way to do everything".

------
iamwil
I had used node.js for about two years, and it's not without its share of
pain. Trying to find some way out of callback hell, and then finally adopting
a rack-like way of writing the controllers, it's somewhat manageable.

It takes quite a bit of getting use to, think and write in promises, futures,
or whatever other shenanigans we come up with to deal with callbacks. I
suspect it's a weakness of the language design, bent to the will of the
reactor pattern.

I can't imagine what sort of enterprise cruft will layer on when people are
doing that with callbacks, etc.

------
EGreg
Actually with HHVM, PHP is faster than Node.js!

Facebook developers can sometimes outperform Google developers, although the
comparison has a lot of extaneous variables here :)

~~~
frik
True, and HHVM is awesome.

Where Node.js shines is Web Sockets and similar things. But one can use
libevent with PHP (though not as easy).

I found some useful comparision benchmarks on that site:
[http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=query)

~~~
EGreg
Do you know of a way to use libevent to make concurrent queries to mysql? Or
mysqli to do this? I mean hitting MULTIPLE database servers / shards.

That would speed up my php by a lot. I an cache results of queries in PHP but
can't batch things together before they are sent. In JS I can wait for 50msec
to do requests in batches. That lets higher lawyers (ViewModels) query the
model without worrying about batching!

~~~
frik
IO related PHP API are a problem, one needs non-blocking functions for optimal
performance.

Sorry, as HHVM doesn't expose libevent yet (at least last asked the devs on
IRC), I moved some portions of my code to node.js for now. (plus HHVM relies
itself on the older libevent 1.4, instead of the 2.x that PHP exposes as API)

I would be interested in the answer too. Maybe ask it on stackoverflow.com or
so?

------
CSDude
I develop with Node since it is 0.4, and I can safely say that Node is as good
as your abilitiy to manage callback hell. If you can, it is pretty awesome,
however you need to study some patterns for that, otherwise it is messy.

------
wwweston
I'm currently a tangential part of a project that just went from being a Java
backend/middleware project with a Flash front end, to a Java backend with and
HTML/JS/CSS frontend with a node-ecosystem build/package tools.

Two weeks ago I complained that we have two build tools (ant and grunt) and
three package managers (ivy, bower, and npm) involved... but doing a
build/deploy is a 5-step manual process that results in dependency errors.

This week things have improved -- the first build is a dozen manual steps,
subsequent builds are only 2-3 steps, and though the deployment seems to be
botched, there are no dependency errors.

Not sure how I feel about enterprise node.js.

------
markbnj
There are some good points in the piece, but aside from "You can easily hire
people to work on the latest hot thing" the benefits boil down to some back-
end architectural patterns that make good sense, and are achievable on many
different stacks. We too build "small modules piped together" however we use
python, java, and redis or rabbitMQ for the plumbing. I have some problems
with python as an enterprise development language, but many more with JS.
Lately my colleagues and I have been talking about Go a bit, so we'll see
where that... um... goes.

------
thsealienbstrds
Arithmetic has a uniform syntax. Here’s an argument for standardizing the
syntax of well understood programming concepts:

"Node.js programs are developed using JavaScript, this means that the silos
that existed between frontend developers and backend developers are now broken
down, and this results in significant efficiencies in the development process.
With Node.js it’s possible to merge web and backend teams into one unit which
makes things much more efficient."

------
eldelshell
Really?

[/me searching job postings for Node.js]

NOT!!!

But hey, the more developers jump ships to Node the more money I make. Look at
the Cobol guys and their salaries.

------
williamcotton
I frequently write modules that I use on both the client and server side of a
web application because I'm writing in the same language on both the client
and server.

This sort of convergence is why node is so popular.

Pretending like this is some sort of fashionable trend like bell-bottoms is
just plain silly.

------
EvenThisAcronym
On the bright side, if Node.js is adopted for "enterprise programming", all
the hipsters that write blog posts about how great Node.js will abandon it
overnight.

------
voidr
> With Node.js it’s possible to merge web and backend teams into one unit
> which makes things much more efficient.

That sounds good, however in practice it's not that much.

------
m1117
Depends on the purpose, I always find rails more fun due to large community
contribution and huge number of gems that work well, very convenient active
record etc.

------
moomin
Is it just me or does this look like Jenn Schiffer wrote it?

------
mantrax5
The real reason is quite simple. And I'm not trying to be bitter or anything,
rather think like a businessman.

The reason is... it's full of JavaScript kids out there, and because they're
so many, they're all replaceable, and cheap. Like the commodity hardware
servers they're programming.

It's neat to cast this as "easy to attract and retain talent", but "rapid
innovation" and "developer happiness" (especially considering the lack of
strict typing, lack of basic primitives, single threaded-ness and callback
hell of Node.JS) are just B.S. reasons of the kind a Node.JS consulting
company would add so it doesn't all look so cynical.

~~~
colechristensen
JavaScript is the new Java... sigh.

------
gss77
"OUR THOUGHTS. YOUR EXPERT TECHNOLOGY ADVISORS"

Quite possibly the most arrogant tag line I've ever read.

------
amrit_b
Then why no job?

