Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After a year of using Node.js in production

geekforbrains.com

Post reply on HN
Print view View original

161–170 of 248 posts

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

#161

Post by spriggan3 »

raarts wrote: post #41
snappy173 wrote: post #26

Earlier quoted context omitted.

>async/await in my experience, async/await is a great way to layer indirection and obfuscation over what is still callback hell. it may look better in the editor, but it's hell to debug.

When I initially encountered event -based processing (libevent in C), those callbacks were indeed difficult to wrap my mind around. But I learned to structure the code in the editor, keeping everything together which made it manageable. I 've worked with node for a couple of months now, and I find promises to be more confusing, because it obfuscates the callback in my mind, and makes it look like ordinary function ca…

The advantage of promises is that you can return them as a type, you can't do that with a callback. If you fetch something from a database , your data access object can return a promise and let the client code deal with the result. Promises are composable by nature, callbacks are not.

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

#162

Post by MichaelGG »

tylerlh wrote: post #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…

How big is the Netflix webapp, though? There's what, 5 or 6 main content "views", then around 20 user-editable forms? Plus the help site. Am I viewing this incorrectly? It doesn't just doesn't feel like Netflix is a large app from the UI perspective - maybe that's just good design.

Hope this doesn't come off as "I could do this in a weekend", just questioning how big the actual webapp is.

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

#163

Post by MichaelGG »

anonyfox wrote: post #143
kansface wrote: post #119

Earlier quoted context omitted.

> 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Mov…

Elixir/Phoenix, Go/ , Rust/ ... should all outperform node.js easily, plus they're actually parallel and not just concurrent AND are much more solid languages to begin with.

But aren't all Node.js deploys fronted by a reverse proxy (like nginx) to multiple node processes? That gives them actual parallelism in practise, right?

Or is it remotely common to just have a single node process and never use more than one core?

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

#164

Post by ldehaan »

CJefferson wrote: post #153
kansface wrote: post #119

Earlier quoted context omitted.

> 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Mov…

I haven't found the overhead of threaded frameworks to be anywhere close to that -- in practice it can be close to even, maybe 2x slower. And a big advantage of threaded is that it is (obviously) easier to scale to multiple CPUs, and I don't have to worry about one connection taking more than a handful of milliseconds and jamming up my server. Node is fine, but I feel many of the speed benefits come from V8 vs cpytho…

seriously? rtfm. Node has supported multiple CPUs for Years, it's called cluster.

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

#165

Post by pron »

placebo wrote: post #98

I usually don't respond to anything which I feel is just another "language war" provocation, but whenever I see these type of reviews I'm mystified. I've developed in many languages and frameworks, both well known and lesser known - decades of client and server side of C/C++, Javascript, Lua, Java, Python, PHP, Perl, Lisp. Pascal (just to name a few) in projects of all sizes, and not once did I have the thought "this…

No language is good enough to make a boring job pleasurable[1]; no language[2] is bad enough to ruin the pleasure of interesting job.

[1]: At least, not for long.

[2]: created in the past thirty/forty years

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

#166

Post by xentronium »

dustinlakin wrote: post #59

I think the switch to an async back-end can be more initial work than many expect. It may take some time to feel as productive, but promises become powerful and became a game changer for me over my previous work with callbacks. Error handling also becomes manageable. What I really enjoy is jumping into new community and getting to work with tools that have built. Choosing the right ones can make or break an experienc…

> Bookshelf.js/Knex

After ruby orms, Bookshelf felt very, very underdeveloped. Anything I tried to do beyond "hello world" only brought me pain, especially dealing with associations, but honestly just about everything. I guess I've been spoiled, but getting anything done in express/bookshelf combo seemed like a chore.

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

#167

Post by morgante »

pron wrote: post #165
placebo wrote: post #98

I usually don't respond to anything which I feel is just another "language war" provocation, but whenever I see these type of reviews I'm mystified. I've developed in many languages and frameworks, both well known and lesser known - decades of client and server side of C/C++, Javascript, Lua, Java, Python, PHP, Perl, Lisp. Pascal (just to name a few) in projects of all sizes, and not once did I have the thought "this…

No language is good enough to make a boring job pleasurable[1]; no language[2] is bad enough to ruin the pleasure of interesting job. [1]: At least, not for long. [2]: created in the past thirty/forty years

C++ is 30 years old and it certainly has made interesting projects horrible.

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

#168

Post by romanovcode »

kansface wrote: post #119
uptownJimmy wrote: post #103

Earlier quoted context omitted.

Speaking only for myself, a middle-weight .NET dev who was, not too long ago, working desperately to find my footing in all this: 1. I think the learning curve to doing good work with Node is really shallow at first, and then it quickly gets almost vertical. 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a…

> 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Mov…

They are probably 10x faster. You'd be surprised that Node is actually pretty slow by itself and only selling point is async which for the most part is not even used e.g. callbacks inside callbacks.

And if you leverage parallelism of those languages they become 100x faster since they can do multi-threaded processing unlike Node.

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

#169

Post by kalms »

MichaelGG wrote: post #159
Kequc wrote: post #155

Earlier quoted context omitted.

I'm still not all the way on board with promises - from the sounds of it this article says there is already a successor down the pipe. As you've pointed out some of these libraries make things behave a lot more similarly to other languages. And in such a case you may be better off just using one of them. However you're giving up on a lot of the power and benefits javascript provides, so of course you'd want to use so…

How is JavaScript so special with async and streams? JS lacks any syntax for async, so it's not on par with languages that do. What's special there? Same for streams: they're implementable in any language, and JS has no special capability there. Or am I unaware of something JS has that other languages lack (besides popularity)?

I think it's more a matter of it being the only way to get things done in JavaScript and Node.js specifically (an overstatement, but that seems to be the sentiment).

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

#170

Post by spriggan3 »

The biggest problem is dealing with callbacks (and yes even promises use callbacks , and generators need to be wrapped in a cor-routine framework in order to work as cor-routines ).

I want to write a quick script doing some busy work , I now have to think about synchronicity even though the script does not need to be non blocking. Of course in these circumstances, I want to move back to Ruby or Python, which actually let me code the thing I want to code without forcing callbacks on me.

So when you have to do 20 i/o operations in sequence, using nodejs becomes really tedious.

Post reply on HN