
Why I love Node.js - sakulstra
https://medium.com/@sakulstra/from-php-to-node-js-meteor-a94d18e6511b#.tstf79c2c
======
wut42
It's not complicated to love nodejs when you come from PHP…

~~~
pluma
As a former Pythonista who currently likes JS a lot after having used it
practically nonstop for the past three years... what do you say to me then?

~~~
dplgk
I say... can you show me the light? I love django...it's no bullshit and no
frills yet has everything I need. Node.... is hellish. Callbacks haunt me. New
tools come out every day. The JS dev process is so over-engineered.

~~~
manyxcxi
Callbacks, arrow code, error handling, and the daily shifting sands of the JS
landscape really pained me when I was first getting my bearings with node but
I was determined to build a continuous deployment server with it until I was
happy with my feature set and comfortable with node. I was going to be
building the system no matter what, but I figured it was the best time to
learn node and that the async-ness of the language would be a huge benefit (it
mostly was).

Eventually, I found my rhythm and I now really like node (it's been three
years). It has a lot to do with picking packages that are stable, or at least
have responsible leadership, and a modicum of documentation. You get used to
minimizing arrow code, and you learn to pass errors until you run into that
one obscure darned library that throws them (or leaks them) and you have to
write a bunch of stuff to seal it up.

The deployment system runs great, and I really like writing tiny to medium
sized worker applications, parsers, scrapers, and web services with node. I
find running node in production to be a bit of a chore compared to Python,
PHP, and Java- but like all things JS it's evolving and I'm still learning.

------
wslh
The last time I criticized Node I was heavily downvoted here (downvotes
already started here too! Please educate me, I am here to learn), so I will
proceed with caution now:

We developed some applications in Node, it is a headache to maintain an
application that uses an SQL database (e.g: MySQL) because the code for
executing a transaction involving several queries is unreadable afterwards. We
use the module async to have some kind of readability but there are many
implicits where small errors are natural to occur.

On the positive side, I found some specific modules in the cryptocurrency
space that are not available in other programming languages. This is why we
are playing right now with Trireme and Edge.js to use Node modules from Java
or .NET.

~~~
EGreg
Can you explain?

Due to Node's evented architecture, you should be executing all the
transaction code in ONE sql query -- otherwise the transaction can be
interleaved with other queries!

~~~
wslh
(downvotes started here too! please educate me instead of downvoting, I am
here to learn)

Yes, that is an additional issue that I suppressed for my comment trying to
narrow the criticism to executing several SQL queries in a readable and
maintainable way.

I will not expand on how we solved that specific issue, just say that the
transaction in question is fired by external events that can't be fired until
a previous one finished.

But, following your suggestion about executing all the transactions in one SQL
query, how do you do this without using a store procedure? Because we were
thinking in using store procedures but we couldn't implement all the logic
inside the transaction with a SP. This is where other languages solve the
problem but I couldn't find a concrete solution in Node, so any suggestions
will be very appreciated.

~~~
EGreg
I was also worried I'd need stored procedures (which MySQL requires root
privileges to create) until I realized (by trying) that felixge's mysql module
(and probably others) simply accept queries with multiple statements :-D

So that solved it for me!

~~~
manyxcxi
We did exactly that- create stored procedures- to get around certain
transactional issues we were facing. We didn't have any problems being able to
create them as we manage the schema outside of the application. In general
this has been a fine trade off for us and hasn't caused any pain. I remember
way back in the day when using stored procedures is what you were SUPPOSED to
be doing...

------
brightball
I'm not a big JS guy, but I totally support what this guy is saying here. Use
what works for you.

JS is a fine choice for some things. It wouldn't be my preference, but you
don't have to make decisions based on my preferences.

~~~
romaniv
Most developers don't control their tool-chains. Plus, some tools act like
black holes for software. They bend all the infrastructure around themselves
and there is no coming back once you cross the adoption event horizon.

~~~
cal5k
This is perhaps the best analogy I've read all year!

...and I've read quite a few.

------
nailer
JS land is pretty sweet right now: npm is fantastic (particularly on the
frontend), ES6 and ES7 finally extend the language to include basic stuff like
multiline strings & array.includes(), server-side DOM manipulation makes a
bunch of possibilities possible, the post-react virtual DOM libraries are
making data binding and components simpler than ever, node and iojs merged, we
have an LTS node, I could go on: things are better now than any time in the
last 5 years.

~~~
tbrock
> npm is fantastic

We must live on different planets. Our eng team and CI tool needs to run npm
install multiple times to coerce this lumbering beast into writing all of our
requirements into a directory.

Every time it unreliably installs my dependencies as specified (after
declaring exact versions required in my package.json) I scream into the void
"you had one job!". It's a frequent cause of frustration for me despite
providing access to a wonderfully colorful library of software.

Availability of packages on npm and in the larger JS ecosystem is at an all
time high and yes, JS as a language seems to be doing well, but npm is, in my
opinion, in dire need of some tlc.

~~~
nailer
> Every time it unreliably installs my dependencies as specified (after
> declaring exact versions required in my package.json)

Declaring exact versions in your package.json doesn't make installs
consistent. An example:

    
    
         A's package.json says A needs exactly B version 1.2.0
           B's package.json says B needs C version 2 or newer
             C can be any version.
    

shrinkwrap will help you with this. It's better in npm v3 (install updates
shrinkwrap by default)

~~~
tbrock
I'd agree with you but it misses packages at the top level entirely until I
run install twice. I am saying install blah@x and it doesn't realize I need it
until round 2.

~~~
tbrock
Ok thanks for down voting me but see others having the same problem here
[https://github.com/npm/npm/issues/10727](https://github.com/npm/npm/issues/10727)

~~~
nailer
FYI it's not me that's downvoting. Your original comment was just 'I know but
it still happens' so you may have been downvoted by someone who thought it
lacked detail.

------
SadWebDeveloper
For toy projects and fast prototyping... JS ecosystem looks awesome but for
enterprise grade software it looks like: toy for kinder garden developers.

Mostly cause the enterprise love to support legacy software from 5 years ago
(your nice webapp won't work that fast on IE8) and requires minimal support
for the next 5 to 8 years.

Web Development future looks fragile IMHO.

~~~
joshmanders
I'm sure Netflix, PayPal, Walmart, LinkedIn, Uber, New York Times, Medium, IBM
are all kinder garden developers.

~~~
SadWebDeveloper
Everyday amazes me that people actually think that when an a "Big Corporation"
announces a new technology adoption they actually believe they rewrite
everything for that new technology and don't consider it a
PR/SnakeOil/Smokeware movement.

~~~
joshmanders
You do realize these companies have posted blog posts explaining the benefits
of them doing just what you say they don't do... PayPal's Mobile.de team
blogged about rewriting their Java system in Node.js and how performance was
improved and how much faster they can work.

Netflix has also blogged about similar experiences.

Walmart blogged about how they rewrote their site in Node.js and was able to
handle traffic on Black Friday way better than with previous systems.

PayPal themselves wrote about rewriting the account dashboard in Node and how
it improved things.

This isn't snake oil or a PR movement. These are real companies using Node.js
to make their businesses better.

Uber talks about how their whole infrastructure is built on Node.js

IBM bought Strongloop, self proclaimed "The Node.js Company".

~~~
pikzen
> was able to handle traffic on Black Friday way better than with previous
> systems.

>how it improved things.

> how performance was improved and how much faster they can work.

Do a full rewrite of some ten years old software in any language and it's very
likely to be faster. Architecture and software engineering made it faster, not
Node. Had they used brainfuck and gotten better perfs, would you have praised
brainfuck?

~~~
brndn
You are just speculating and can't possibly claim that the Node played no role
in their performance/productivity increase. I'm sure they improved their
architecture and fixed mistakes, but they didn't switch to Node for no reason.
They could have rewritten in the same language.

