
Why Node.js is becoming the go-to technology  - pmcpinto
http://www.nearform.com/nodecrunch/node-js-becoming-go-technology-enterprise#.UyLJD_vIfGh
======
matthewmacleod
I know this is advertising, but there are a couple of particularly
objectionable points…

 _Increasing competition between rival internet companies, the speed of
delivery and the ability to iterate are the key traits of market leaders. In a
competitive scenario, reacting to end user needs, incorporating their feedback
into the offering and delivering updates and changes regularly is essential._

This is _literally nothing_ to do with Node. It's to do with good architecture
and project management. The style of architecture generally used and
encouraged in the Node community does tend to push SOA etc., but that's
nothing to do with the language.

 _It’s extremely difficult to hire top talent these days; good developers like
to learn new things and to use new technologies._

Node will not continue to be 'new technology' for long. This is a shoddy basis
on which to select a tool.

 _double the number of requests per-second and reduced response time by 35% or
200 milliseconds._

Measuring reimplementations of code in alternative languages is frequently
absolutely pointless, because that reimplementation will _always_ go hand-in-
hand with massive re-architecting, and absent second-system effect this will
result in better performance. For example:

 _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._

Because all of the rendering was pushed to the client, no doubt.

Node is great, but it's one of many valid choices for developing huge, modern
web apps. It's not that Node is becoming the "go-to technology in the
Enterprise" (it's not), but that SOA, loose coupling and the reduction in use
of monolithic frameworks are everywhere, and that's something that Node is
good at.

~~~
davedx
Agreed. In the other story about node.js I challenged people to describe the
"Node way" of doing things, and was given a laundry list of things that
applied to every technology, like "modules".

We are currently living through a programming language and tools renaissance
the likes of which have never been seen before. Why are good developers
deliberately blinding themselves to all the goodness throughout the whole
programming ecosystem, choosing instead one tool (e.g. nodejs) as the One True
Hammer? It's so unnecessary and so limiting.

~~~
gaius
Interesting choice of words _re_ naissance, as what we are actually seeing is
people blindly reinventing things that were known in the 1970s. At least the
true renaissance thinkers knew they were rediscovering things that existed
before the Dark Ages; today people genuinely think they're onto something
novel.

~~~
unoti
While it is true that the basics of computation did exist in the 70's, it's
very clear that programmer productivity today far eclipses what we were doing
even 20 years ago. I started coding professionally in the 80's. Today much of
what I used to do is now handled by users on their own with spreadsheets and
query tools. A small team of 1-2 people today can routinely take on a task
that would have taken teams literally 10x as much effort back in the day.

For example, anything involving interfacing computer systems together in any
way took an order of magnitude more time back in the day. There were no real
widely accepted, simple to use methods available. Networking and
communications over modems tended to be so unreliable and difficult that
systems tended to be made as monolithic things that just did everything for
themselves.

It occurs to me that a book could be e written describing why and how
programmer productivity is better today than it was a couple decades ago.

It is true that computer technology has been around a long time. And it's also
true that a lot of the best stuff such as Lisp has been around for a long
time. But there are all kinds of factors that make programmers complete
projects in a matter of days today that they wouldn't be able to 10 or 15
years ago.

~~~
gaius
And yet, an incredible amount of software was written on VT100s. Software that
is rock-solid reliable, does things on old hardware that would be impossible
on even on modern hardware with scripting languages, and is still relevant and
doing useful work after many decades. What looks like "productivity" today is
just fluff, pretty interfaces that still offload their real work to old-school
systems.

~~~
unoti
Get off my lawn!

------
hartator
I think Node.js is overrated.

The Node.js/NPM community is going through a lot of issues and seems,
unfortunately, immature. People also tends to choose Node.js for the wrong
reasons. Mainly they want to have only one language for everything:
Database/Frontend/Backend/Deployment... JS itself as a bare language is a far
from perfect. A good point to start will be to just compare a sample selenium
test in ruby or python and node.js. The Ruby/Python one is clear and
expressive whereas the node.js one is just a callback nightmare. Finally,
node.js single thread blocking nature means you have to deal with
threads/forks anyway for any serious application.

~~~
lunarcave
I think calling a technology overrated by pointing out a sample selenium test
is pointless.

Like any technology, there are some things that node.js is good at, and
somethings not good at. The callback-hell is something that will eventually be
ironed out in ES6 and as a language, that'd be something that any dev will
find non-appealing about javascript.

~~~
krsunny
Callback hell has been my biggest stumbling block with node but there are
libraries such as asynch and Q which have provided me with adequate solutions.
Also since were talking about things to be ironed out, I hope they make it
easier to run node behind Apache or some other webserver thats tried and
true.. why abandon all that progress?

~~~
dham
Phusion
Passenger([https://www.phusionpassenger.com/](https://www.phusionpassenger.com/))
supports Node.

------
mgkimsal
The issue about happy developers because they are using 'new technologies'
(use node! it's a new technology) is a wrong conclusion. This is like Rails
7-8 years ago. People using node now are essentially doing greenfield projects
- they're writing 'from scratch' code without any major requirements to keep
existing code going.

Come back in 5 years when someone has to maintain the Paypal nodejs stuff
which has become a moderate mess due to weird edge cases, changed business and
legal requirements, and try to hire node developers to come in and maintain
code written by people who are no longer working there, having moved on to
scala/f# projects in 2015. All the new attention will be in 'node 2017', but
you'll be stuck trying to make 2017 modules work in 2013 code, and you'll be
left trying to patch/maintain something that wasn't as forward-compatible.

For true irony, some of those same developers will be brought back as
consultants to develop the next-gen 'paypal 2018!' based on some new Scala
framework, and the maintainers will have to watch the experts write the next
generation of what they'll be maintaining 4 years on.

EDIT: "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." I strongly suspect that if the team
had been given X months of "rewrite the Rails system using all the current
knowledge and techniques, as a new system vs patching the live one", they'd
have seen similar results in less time.

To the extent that some companies are more SOA flavored than they were 5-10
years ago, this will be easier for everyone involved, of course, but let's not
pretend that developers are happy because they're using 'new technology'.
They're generally happy in any language when they don't have to work within
bone-headed constraints leveled on them by predecessors who were chasing the
latest fad before really understanding it.

------
buster
Wow, a node.js company writes a blog post how node.js is the next technology
and you should switch over (and hire them, they do node.js consulting!)

Uhm.. yes.. node.js is great but this article is not. I can write the exact
same article with success stories about PHP, Ruby, Python, Erlang, Perl and
with a little bit of creativity about brainfuck..

~~~
walshemj
Hell you could probably do one about how you should use Fortran for big data
instead of this modern OO Java rubbish :-)

~~~
octopus
Fortran is the oldest programming language in existence today, because of this
it has a lot of cruft. However, if you put your compiler in standard mode
(2003 or 2008 standard) you have a pretty modern language: modules,
interfaces, functions that contains functions etc ... You can do OOP in
Fortran if you use a modern compiler and stay close to the standard.

Where Java beats hands down Fortran is at the huge ecosystem and libraries
available for a variety of domains. Another weak spot for Fortran is that it
doesn't stop you to shoot yourself in the foot and you can use implicit types,
case insensitivity and globals all over the place.

------
jeswin
The author makes a point about getting high-quality node developers. That is
primarily for two reasons.

1) Early adopters generally tend to do well, whatever the language may be.

2) And more importantly, the asynchrony in nodejs is not easy. Writing
maintainable JS is harder than writing Python or Java. So if someone has been
through that grind, chances are they could be good developers.

Being able to do everything with a single language is kind of a big deal for
many companies; the only thing holding back JS of the messy nature of
callbacks (and promises, yuck). I would expect real adoption of JS to begin
when ES6 features (generators, classes, etc) become available.

~~~
collyw
"Being able to do everything with a single language is kind of a big deal for
many companies;"

Its a shame that so far JavaScript seems to be the only language you can use
on the client and server. I come from a Perl background and every time I try
to do something in JS it seems like a kludge.

~~~
joshuacc
Decent compile-to-js languages can work as well. CoffeeScript is probably the
most prominent, but ClojureScript seems especially promising to me.

~~~
collyw
Is debugging not a pain in these languages?

~~~
joshuacc
I don't have experience with ClojureScript yet, but CoffeeScript is trivial to
debug since the source and the compiled JavaScript are structurally very
similar.

------
pgsandstrom
While I really like node.js, I always feel skeptical about "re-implemented
gave X% improvement". Often a re-implementation is done because the domain-
knowledge has improved significantly since the project was started. There
should be an improvement even if the re-implementation was done in the same
language.

~~~
adrianoconnor
When I see people talk about X% improvement because of some new tech, I always
think about Fred Brooks and the No Silver Bullet essay. Nothing changes under
the sun.

------
davidw
* Because Erlang is difficult to grok and hire people for, even though it probably does a better job at a lot of the same things.

------
lucian1900
This is all bullshit.

There is one reason Node is popular: it's JavaScript (extremely popular) on a
server and mostly works with little effort (unlike most similar runtimes).

~~~
mackwic
Javascript is _extremely popular_ ? Since when ? Oh, wait, since node.js.
(Even if node is not the only cause of the JS popularity)

~~~
lucian1900
No, since browsers.

------
insertnickname
>“Why go to Facebook and do PHP when you can go to PayPal and do Node.js” >\-
Bill Scott – Dir UX PayPal

Why don't I just kill myself?

~~~
Sirenos
Or... you could just avoid Paypal?

But good god you gave me quite the chuckle. Thanks for making my shitty day a
little better.

------
prottmann
Oh my god, on some parts i agree and on some parts you exaggerate massive.

Node is a step into the right direction, but the Node.js way is only the base
for building up new or other technoligies.

Yes programmers want to experiment with new things, but when programmers grow
up, they want to use things that work without inventing the wheel again.

Node grow up now and it is exciting to see what node will be.

It seems that iam too old with my 35 years ;-) because i see things like node
as a tool, a tool to solve a problem. I use node, but i did not say "yesssss
it is the best thing in the world, wohoooooo" ;-)

~~~
mantrax
I'm 32. Let's just point at the overexcited crowds and have a chuckle as
another fad is about to peak.

I like Node.JS a lot, as you say it's a tool in my toolbox. But due to the
it's nature the code is quite fragile. It's best to keep Node.JS apps small
and simple and play to Node's strengths, which are a high volume of
computationally simple (and potentially long-running) requests.

That article is definitely hype-inspired.

------
vjeux
I'm a developer at Facebook I thought I'd share my experience.

Before I joined, I wasn't really convinced by PHP. My experience using it was
good for quick and dirty work but quickly resulted in a mess. However, the
Facebook codebase was nothing alike.

The PHP stack uses generators to deal with async requests and doesn't suffer
from callback hell. To write the UI, you write new custom components using XHP
(XML in PHP). It heavily uses classes, traits, and most badly designed native
php functions have a better counterpart available.

On the javaScript side, all the code is written using CommonJS modules. It
runs a custom version of JSLint and Jasmine for unit tests. React as the main
framework. We also have source transform for ES6 classes, arrow functions,
spread operator ... It definitively feels at home for any node.js person :)

~~~
jerf
"The PHP stack uses generators to deal with async requests and doesn't suffer
from callback hell."

This is one of the problems with the Node hype; it claims to be this unique
and special snowflake, when in fact pretty much any similar language (Perl,
Python, PHP, Lua, etc.) has just as much stuff working for it. Even the "but
our libraries are 'designed' for async!" isn't as big of an advantage as is
claimed, since in many cases the other languages have good libraries too. (Or
in the case of something like gevent, a reasonable ability to _convert_
libraries to async.) It's really a throwback, not the awesome step forward it
claims to be.

------
catmanjan
I was listening to a podcast by the PM in charge of the WalMart node.js
deployment, he had nothing but good things to say about node, but using the
CPU graph as a measure is stupid and misleading.

The project was using node as a middle-man for some old Java based API which
spat out products, prices and stock levels. So node was basically set up to
serve static pages, in the hope that later they can migrate the API to node as
well.

Anyway, I'm sure it's all great, but unfortunately since I know the WalMart
statement is a load of BS I distrust the rest of the metrics provided.

------
neverminder
From what I read around I understand that node.js is good for simple projects,
but not for heavyweights where concurrency and scalability is the key. This is
where I'm pretty sure something like Typesafe stack (Scala/Play/Akka) blows it
out of the water. Personally if I work on something I'd like to at least hope
that it will be big someday, which is why I'm willing to spend some extra
time, but choose the most solid platform that I can afford. Typesafe stack is
the most impressive one at least for now, in my opinion.

------
daraosn
I really like node.js, but Ruby gives you way more 'happiness' and
productivity, imo. Until I don't see ALL (or at least 80%) of the stack that
frameworks like Ruby on Rails have in node.js's frameworks, I will still
prefer Ruby over node.js for most of my web projects (of course node.js is
sometimes more suitable for certain things, especially asynchronous services,
but you can still use Ruby).

------
gaius
Erlang is hard, let's go shopping!

------
KaiserPro
"sidestep threading issues"

I think displacing them is more apt.

complex Callbacks just as nasty as complex threads.

------
adamors
Do people actually use Node in production for serious things? I actually don't
know anybody who shipped anything done in Node. Sure, they do side projects or
hobby projects, but nothing more than that.

~~~
mkohlmyr
You're not being serious..

[https://github.com/joyent/node/wiki/Projects,-Applications,-...](https://github.com/joyent/node/wiki/Projects,-Applications,-and-
Companies-Using-Node)

In fact I work at a company which is on target to process more than 2bn events
/ 1bn page views this year on a node / python based service oriented
architecture. I'd say that's a handful more than your average hobby project.

~~~
zorked
We're doing 3.5 billion requests a month on Node and I'm sure it's still a
small number compared to what other people are doing.

------
exabrial
Because the hipsters thought it was a good idea? Once they realize it's
impossible to maintain your codebase they'll all moved on to create their next
disaster.

------
CSDude
When I saw go-to in the title, I thought it was about callback hell. I use
NodeJS heavily in my projects since it was version 0.4 still have difficulties
in writing good code. Other than that, it seems fast, but of course there is
no point believing node is 15x faster than our old implementation. Any
complete re-building of a system would be faster when you have more experience
with the domain.

------
dschiptsov
"Write server side apps the way you wrote stupid web pages" meme? And all the
difficulties with resource management and efficient I/O is someone else's
problem. Ok, good luck for those who never learn Java's lessons.)

Btw, pamphlet forgot to mention compared to what they got many X increases and
reductions. Ruby, I suppose.)

Well, V8 complies into native code, but server side is mostly about I/O and
RPC and data persistence, which requires a bit more skills than
getElementById, so assumption about 1/2 number of developers is
overoptimistic.

Also would love to see, same as for java based "solutions", the ratio between
memory used and the size of served data set , especially compared to Golang
which I think is little more appropriate for server side.)

"Let's add it all together" section is especially convincing.)

------
Kiro
> NPM effectively kills the possibility of experiencing dependency hell

Am I the only one feeling that package management is the cause of dependency
hell? Doing it the old school way where you just always have all the
dependencies in the repo will never lead to these problems.

------
puppetmaster3
4 reasons its good and 2 way to make it better:

1\. it's async! most developers can't do threading. it does not do locking at
all! let me say it again: no locks. java devs: what is faster, hashmap or
hashtable?

2\. it's dynamic. compare to old static langs.

3\. it uses same syntax as browser.

4\. npm. compare it to the maven.

A way to make it better?

1\. thick client, not server side rendering of ui. use a CDN and phonegap
build

2\. npm -g install typescript (to make it a bit less dynamic)

cheers.(I myself now like D libs, such as [http://vibed.org](http://vibed.org)
)

~~~
darkarmani
> 4\. npm. compare it to the maven.

NPM is probably the worst part. It solves the easy problem using brute force
and 20 copies of the same library, but punts on actual packaging. Joyent's
advice is "don't use NPM to deploy -- use tarballs." What kind of package
manager requires you not to use it for deployment??

I really think NPM is a solution for immaturity on the node libraries. Think
about the attack surface when you have 20 different versions of the same
library scattered throughout your application.

Not having to understand your library dependencies means you don't understand
all of the security bugs from old versions of libraries. You should understand
your library dependencies. Forgetting about them doesn't make those
relationships go away.

~~~
puppetmaster3
What are you comparing it to? I compare it to Maven and one is clearly better
- if you used both in anger.

------
CmonDev
The new Silver Bullet is born! Will get you best developers, cut bad things
50% and improve good things 2x! JS is the only language you will _ever_ need!

------
hiisi
Feels like the "Easy to modify and maintain" part is confusing the benefits of
using Node.js with benefits of good application design.

------
edem
I wonder how can you build a reliable e-commerce platform on a database which
is not ACID...and node users typically use MongoDB and other NoSQL databases
which does not support transactions.

~~~
camus2
It's true that the most mature DB framework on nodejs plateform is Mongoose,so
usually nodejs devs use mongoose to deal with data. No need to say that
MongoDB is not the right choice for apps that need transactions or when datas
are heavily relational. And Mongoose doesnt support cascade operations.

Sequelize or Bookshelf are not mature enough for now IMHO,compared to what one
can find on other plateforms like Java,Ruby or PHP. So you either need to
write raw sql queries or delegate all transactions to another app layer.

------
rbanffy
JavaScript seems to be enormously popular among non-programmers. ;-)

------
sdfjkl
> Black Friday the WalMart servers didn’t go over 1% CPU utilisation

So they massively overprovisioned? Hopefully they didn't buy all that
hardware.

~~~
dspillett
Using CPU utilisation as a measure like that is pretty pointless anyway.

Without knowing over what period (instantaneous measure across the farm, a ten
minute average from a typical node, a ten minute average over the lot, ...)
that reading was taken it could mean many things.

If they have pushed a chunk of the rendering duties client-side then the CPU
is not going to be their bottle-neck anyway: the back-end data-store and
network bandwidth will be.

------
staticelf
I write php at work, mostly. But all my free time projects are in node because
I love it.

------
tyler-codenvy
I have read the article and this thread with keen interest. I am curious to
solicit community feedback on our choices as we faced the Node vs. Java choice
in 2012. In particular, does our business ultimately suffer long term
consequences by our stack choice? We think we ultimately have strong
advantages vs. any competitor built using Node.JS, but the beauty of HN is
that we can open up the thoughts for everyone to contribute.

I am the CEO and founder of Codenvy. We make SAAS developer environments, and
have been working as a team since 2009. Starting in 2012, we recognized the
limitations of our initial system and needed to rebuild the entire system from
the ground up. We had three criteria: performance, security, and modularity
(of our core base and an ability for ISVs / enterprise to plug-in their own
customizations). We raised $9M in Jan 2013, so we now have big investors and
aspirations equally large. Our target market is primarily enterprises and ISVs
that build Eclipse plug-ins. Individual developers and consultants are a
secondary audience.

We chose to go with a pure Java stack, after a careful evaluation of Node.JS
vs. Java. We wanted to provide some of our thoughts, as we continually ask
ourselves whether there are downsides to the approach we chose. For the
record, we have competitors like Eclipse Orion and Cloud9 that are pure
JavaScript / Node implementations, but we are - as far as I have seen - the
only Java implementation in our market.

Our team is currently 40 people, with 35 or so in R&D. Our engineers have
experience with Java, Scala, JavaScript, AngularJS. Prior to this project,
most engineers were working on server systems for content and document
management firms. The hard stuff: sync, versioning, correlation, and so on. As
for myself, my career started as a Java engineer in the 90s, but for the most
part have been hands off as a technologist for a decade. My skills may have
faded, but as a CEO, I am conversant.

We did 2 prototypes on Node.JS where the client and server were combined
systems. We ran a battery of performance tests and did conclude that we could
probably run a large scale system on fewer physical nodes with Node.JS than
with Java, but the gains were not enough to justify the choice.

Our long term architecture was different from our competitors. Most SAAS dev
environments provision each user / group their own VM, give you root access,
and let you control that system. We chose an approach that would optimize
overall system density by by offloading builds, debugs, and editing onto
separate clusters. User environments will be virtualized and routed to the
appropriate cluster on-demand. The user will feel like they have a personal
VM, but our elvish helpers route traffic between the nodes across performance
queues.

After offloading LDAP (for identity), event / log management (for analytics),
and cloud administration, the only core systems left was our API services
(account / builder / runner / auth) and editing. These core systems would be
subject to heavy iterative development, and Node's architecture could offer
higher density of requests / users than Java, but by our tests the comparison
was 10-20% difference, not 300%.

By way of scaling, for every 10,000 concurrent developers, we average 20
editing nodes (I/O constrained), 75 debugging nodes (memory constraining), 5
builder nodes (CPU constrained). A similar TS / VDI implementation would
require nearly 5,000 nodes of the same shape / size to service the same
population.

So, we saw a disadvantage to Java as we could have reduced our editing node
even further. But we chose Java because: a) The library selection. Broad and
mature. In particular, it's data structures, file management, REST services.
b) GWT. This library gave us cross-browser portability of code written in
Java. c) Eclipse Plug-Ins. We knew we wanted to target Eclipse plug-in
developers and saw the Orion project as optimized for Web dev, leaving a gap
in Eclipse. We saw it as a business gamble that Eclipse devs who needed to
move their plug-ins would find a pure Java plug-in architecture that was
similar to RCP more attractive than a newer (but have to learn new tech &
rewrite) approach. d) Our history. We did a straw poll of our engineers before
we started. We asked them if they felt that they would rather do Node or Java,
and 75% said that they would enjoy Java more. When asked why? They had tool
familiarity, were confident in the maturity of maven, and better job
prospects. This last one completely surprised me. e) JVM. The number of
optimizations of the JVM would give us advantages for enterprise deployment.
We built our system to be automatically installable on-premises. We do so with
Puppet, but recognized that we would be encountering many IAAS and PAAS
standards internally. Enterprises had security and performance tested the JVM,
so we saw an opportunity to win hearts and minds of system admins, datacenter
architects, and security specialists by our choice of architecture.

So, we carried forward. Since we started working on our next generation
architecture, we have focused hard on the best practices associated with
agile, devops, and continuous delivery. We have 7 teams of 4-6 people, each
focused on a different aspect of our stack. We are able to release any Jira
issue at any point in the day. Each team can push into acceptance, staging or
production without coordinating with the other teams. At the same time, we
have achieved modularity and a rapid development tempo. While we haven't
released our new system to the market yet, we find that the performance of the
environment is similar to a desktop environment, and it scales cleanly with
simulated load tests. We have also been able to give out our SDK
(github.com/codenvy/sdk) to 6 different partners, some of which are Eclipse
plug-in developers, who are able to code, build, test, integrate, and publish
their plug-ins without complicated dependencies to our core team. Their
feedback was that the port of their plug-in took about 1/2 the time of the
original development. And there is no real way to estimate what the effort
would be to do the same in a Node-based offering like Orion.

What we can't measure is whether our competitors are able to release faster &
more functionality than we are. It seems like a crap shoot. One other variable
we can't account for is the cost to maintain legacy. The system we have
Codenvy.com is legacy for us, and will be retired in Q3. We have to
continually allocate 3-5 people to work on bugs, special partner projects, or
other related items to keep that system live while we also work to roll out
the new system. We know this is a drag, and some of our engineers think we may
more than double our productivity once we consolidate to a single
architecture. I am a bit skeptical at that - but I find that it's unwise to
disagree with my engineers. I tend to lose.

So at this point, we feel like we made the right choice. But time will tell -
we begin selling our enterprise offering earnestly once we ship our new system
in Q2.

Looking forward to the discussion.

------
camus2
nodejs will live on because it uses js which is mandatory in the browser,for
better or worse. Hopefully ES6 and futures versions will make this awfull
language much better.

~~~
VeejayRampay
I really wish ES6 does that because as it is, Javascript only has two things
going for it: the speed provided by the big boys (V8, xMonkey, etc) and the
fact that it's only language available on the web. And none of those are
merits of the language itself. Kind of sad.

------
jbeja
When Lua will become the go-to technology?

------
AgLiAn
Propaganda.

------
pjmlp
Err, no.

