Live data from Hacker News

After a year of using Node.js in production

geekforbrains.com

31–40 of 248 posts

Re: After a year of using Node.js in production

#31
We couldn't even stand 6 months let alone a year. Broken pack depts make it hard to CI, poor performance, memory leaks, huge docker base images due to deps, lots of single cpu only tasks that were too hard to scale out, an ugly language compared to ruby or Python and on top of all that how poor the package management with NPM has been. We've just ditched it and gone back to Python/Django/flask and ruby for the ops tooling.

Re: After a year of using Node.js in production

#32
> You use Grunt!? Everyone uses Gulp!? Wait no, use native NPM scripts!

Although couched as a criticism this is actually the community fixing itself. The evolution from Grunt > Gulp > npm scripts is movement away from needless complexity towards simplicity. Npm scripts are effectively just Bash commands that build and manage your project, which sometimes employ small, unixy tools written in Node.

This self correction was pretty quick, it happened within a few years.

> Unfortunately, there isn’t any one “standard” (like everything else in Javascript) for implementing or using Promises.

Yes there is. It's called the Promises/A+ spec, and its built into ES6.

Re: After a year of using Node.js in production

#33
post #23

These types of articles make me laugh. Typically a dev with many many years experience with one language, learned all it's quirks, standards, etc decides to try Node.js because it's the "new hot fun toy", and expect it to work like their old language, and realize that is not how it works, doesn't know where to find what and fails real hard to realize that JavaScript in general is in a huge influx of updating at this…

> JavaScript in general is in a huge influx of updating at this moment Isn't that the case basically all the time? Which is a perfectly suitable reason to avoid it at all costs except for the bare minimum required for front-end..

> Isn't that the case basically all the time?

No, ES5 to ES2015 is a HUGE leap. ES2015 to ES2016 is a very minor jump as it only adds 2 new things to the spec.

> Which is a perfectly suitable reason to avoid it at all costs except for the bare minimum required for front-end..

And honestly, that is not my job to tell you not to do. If you want to avoid Node.js go ahead. I feel Java is something I should avoid at all costs. Doesn't make Java any worse or better. Same with Node.js.

Re: After a year of using Node.js in production

#35
post #25

I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used. The whole async situation needs to settle down, it's completely unacceptable to write code with callbacks, promises, etc. This is because they are not just challenging to deal with, but intrinsically wrong in concept. I have to wait for a database query to complete, then pass…

Agreed. Checkout RxJS to hold you over while you're in Javascript land.

Re: After a year of using Node.js in production

#36
post #25

I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used. The whole async situation needs to settle down, it's completely unacceptable to write code with callbacks, promises, etc. This is because they are not just challenging to deal with, but intrinsically wrong in concept. I have to wait for a database query to complete, then pass…

Yes, I too find callbacks an obstacle to readability, among other things.

If one uses mongodb (popular on node.js), and one needs multiple queries to 'join' several documents, the cascade of callbacks is an obstacle to readability, let alone debugging.

Re: After a year of using Node.js in production

#39
post #25

I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used. The whole async situation needs to settle down, it's completely unacceptable to write code with callbacks, promises, etc. This is because they are not just challenging to deal with, but intrinsically wrong in concept. I have to wait for a database query to complete, then pass…

Agreed. Checkout RxJS to hold you over while you're in Javascript land.

Please don't use event streams for handling asynchronous code, that's not what it's for.

Re: After a year of using Node.js in production

#40
The Netflix.com site and webapp runs on Node (and talks to a number of services written in mostly JVM based languages). While we encounter challenges just as we would with any other language -- it works for us and I would argue that it's a pretty big application.

There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best. Don't treat any one language as an end-all-be-all and you might find yourself much happier and more productive. Of course, YMMV.

Post reply on HN