Why I love Node.js | Hacker News Reader

Why I love Node.js

medium.com

55 pointssakulstra68 comments

It's not complicated to love nodejs when you come from PHP…

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?

I can understand not wanting to work with Twisted.

I was a happy Django user. I'm still fond of Python.

I'm not simply preferring JS out of spite.

Why do you prefer JS? As a current Pythonista, I can't stand its inconsistencies.

"How dare you talk to me?"

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.

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.

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.

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!

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

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!

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

No. When you start a transaction, you hold onto the particular connection you started it with, and that connection is busy in your connection pool and won't be assigned to unrelated queries. See for instance: https://github.com/brianc/node-postgres/wiki/Transactions

(If you're just saying "other unrelated queries could happen between opening the transaction and closing it," well, yes, but that's true of any web application, whether it uses threads or events.)

Usually a thread or an app holds a connection. But here the connection may be shared among many evented handlers!

JavaScript is evolving towards addressing this, with promises in ES6 and async/await in ES7. The latter is a game changer.

FYI, async/await didn't make it into ES2016 (aka ES7).

See here: http://www.2ality.com/2016/01/ecmascript-2016.html

Doesn't matter much, it will reach Stage 4 soon, which is equivalent to being standardized.

in my experience, node definitely starts to seem complicated (in comparison to other languages) when doing operations that require multiple callbacks. its sometimes hard to tell where errors are occurring.

async helps, but when doing a series of operations with dependencies and shared data between steps it can lead to headaches. It took me quite a bit of time before I could think about these operations in a way that was a better fit for an event driven model, and once my mind set changed, things felt simpler.

i've had success recently moving complicated multiple step operations into their own functions. If you follow the callback/error conventions this can be much easier to debug, and you can add your own error handling at each step.

There are libraries that handle database transactions cleanly. See for instance: http://knexjs.org/#Transactions

I also find this annoying. The reason is because there are no locks in Nodejs. It never waits for a query to execute, so you have to use callbacks. This makes your app super performant. You can now run your service on one CPU core where you needed twenty physical servers to handle the same traffic before.

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.

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.

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

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

I'd actually say that JavaScript is the weak point of Node.js. It's got some good points, to be sure, but there's plenty of pitfalls (let's talk string concatenation vs addition, for instance) and the new language extensions of ES6 add more opportunities for confusion until people are very well adapted to them.

But as far as providing a nice nonblocking event loop, and a consistent ecosystem built around that event loop, it's pretty neat.

Pretty much. Node is amazing. Too bad the Google genius had to work with JS. Thing about what they would have accomplish if they had to create a V8 for a decent language...

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.

> server-side DOM manipulation makes a bunch of possibilities possible

Can you explain what this has to do with node.js? I've done server-side DOM manipulation for years, in both .NET and Python.

You can run well known client libraries on the server with little or no modification, and testing them is also easier since you can pop open DevTools and prototype code rapidly.

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

I made a batch file to run npm 3 times when they had a bug in assuming atomic file actions. They have fixed this bug and the latest versions of npm. It only happened on cloud servers for me and it was assumed a result of slow IO highlighting the bug.

Eh I'm not sure that is the same problem. We could reproduce this behavior on everything from MacBook Airs to honking i7s with fast SSDs as well as the cloud.

The case you describe definitely sounds "broken" to me. I think it'd be very, very helpful if you could provide your test cases to the npm project.

It's already well documented here https://github.com/npm/npm/issues/10727

> 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)

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.

Ok thanks for down voting me but see others having the same problem here https://github.com/npm/npm/issues/10727

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.

I have to wonder if you're doing it wrong. We have a very large angular/node app, which has been in production for 2.5 years, with many packages. We npm-install several times per day on different networks and different machines. The only time we have had problems is when the actual npm site itself goes down (thankfully that's rare now but it was annoyingly frequent "in the beginning"). Npm-shrinkwrap is a little painful but gets the job done. I don't hear a lot of people having problems with npm. It kind of "just works" for almost everyone.

Don't get me wrong, we are lucky to have npm at all and I don't want to turn this thread into a vendetta for "my issue" because I hate when people do that but I've obviously struck a chord with the community. I don't think it's just me.

Maybe npm is broken and everyone is either just apologizing for it or complaining instead of fixing it (myself included).

I agree. Fantastic is not what I'd use to describe npm. Mostly it usually works a majority of the time... It's tough to get reproducible deploys even when we have our versions pinned.

Recently I ran into issues with npm global, Jenkins, and Windows Server and I was ready to burn the building down. I give npm a share of the blame, but not all, but the major issue was where npm global installs tried to install when run in Jenkins as a service.

The best thing about JS are the debugging tools in Chrome!

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.

The kindergarten developers at Netflix and PayPal (to name a few) use NodeJS in production.

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

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.

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

> 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?

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.

How much of that is because the second time you come to solve a problem, you have already learned all the solutions?

not negating the power of node.js, but if you google enough you can see success stories of migrating from any to any other language, including https://blog.twitter.com/2011/twitter-search-is-now-3x-faste...

by your logic PHP/Hack should be used by everyone because it can handle the site-scale of Facebook...

Everyday amazes me that people actually think bigger companies write better software.

When you are talking large companies, you have to understand that any opinion is a partial opinion. it could be one team that likes a tool, it could be most of the organization. Also, having something in production doesn't mean it's liked: Maybe something that looked rosy and nice at one point now is seen as a nightmare. It's just that when big corporations regret something, they rarely do it publicly. It's amazing how many projects that are seen as wonderful tech successes, are big failures in practice.

When talking specifically about NodeJs, in at least one of the cases you mention, there is a lot of skepticism about their experience, and barring a few champions of the faith, high profile Node uses would be rewritten into something else.

So what 2011 vintage technology would you advocate using?

Reply on news.ycombinator.com