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

Node.js - Convincing the boss guide

nodeguide.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Node.js - Convincing the boss guide

#21

Post by neovive »

DanI-S wrote: post #12

Here's something oft-understated: As a web developer, you sit on the intersection of engineering, design and art. You're lucky enough to live at a time where there are numerous production-ready tools with which to do your job. If you choose a tool that you're excited to explore, with an active and fast-moving ecosystem, your excitement and enthusiasm will make you happier and more likely to do a better job. Someone d…

Excellent points!! Always keep an eye open towards the advantages and disadvantages of anything new. Don't immediately dismiss something because it is new, just as you wouldn't immediately start using something new. Research and learn.

Re: Node.js - Convincing the boss guide

#22

Post by jbooth »

arturadib wrote: post #20

> Bad Use Cases: CPU heavy apps I wouldn't say that Node (i.e. V8) is a bad use case for CPU-heavy apps. In math/statistics for example, V8 stacks up well against other scripting alternatives. See e.g. the benchmarks here: http://julialang.org/ Of course it's still not as fast as C++, but not terribly off either. Expect dramatic improvements here thanks to the push for making web apps faster.

In that example, V8 javascript was 400x slower than the alternatives for matrix multiplication. That's because it's not binding to the BLAS libraries like the 'real' statistical languages. Of course, node supports calling out to C APIs, but that's not an argument for javascript, dynamic languages will naturally be terrible at math compared to C.

More to the point: Node does nonblocking i/o but cpu work is in fact blocking. This means that a CPU-heavy request queues up all requests behind it, waiting to get access to the CPU. You're better off using a threaded architecture for CPU-heavy work.

Re: Node.js - Convincing the boss guide

#23

Post by tferris »

DanI-S wrote: post #12

Here's something oft-understated: As a web developer, you sit on the intersection of engineering, design and art. You're lucky enough to live at a time where there are numerous production-ready tools with which to do your job. If you choose a tool that you're excited to explore, with an active and fast-moving ecosystem, your excitement and enthusiasm will make you happier and more likely to do a better job. Someone d…

Couldn't upvote this more.

And regarding Node: it rocks, just try it and you see what eye opener you missed before.

Re: Node.js - Convincing the boss guide

#25

Post by arturadib »

jbooth wrote: post #22
arturadib wrote: post #20

> Bad Use Cases: CPU heavy apps I wouldn't say that Node (i.e. V8) is a bad use case for CPU-heavy apps. In math/statistics for example, V8 stacks up well against other scripting alternatives. See e.g. the benchmarks here: http://julialang.org/ Of course it's still not as fast as C++, but not terribly off either. Expect dramatic improvements here thanks to the push for making web apps faster.

In that example, V8 javascript was 400x slower than the alternatives for matrix multiplication. That's because it's not binding to the BLAS libraries like the 'real' statistical languages. Of course, node supports calling out to C APIs, but that's not an argument for javascript, dynamic languages will naturally be terrible at math compared to C. More to the point: Node does nonblocking i/o but cpu work is in fact blo…

That's silly. No one in their sane mind would serve web requests AND do heavy processing in the same thread - no matter what language.

In Node, you would have a process responding to web requests, and launch a separate process -- via a convenient child_process with built-in pipe communication -- for doing the heavy CPU work.

The only case where that wouldn't make sense is if you need BOTH a ton of concurrency AND heavy CPU work. In that case, threads would make sense as they would be cheaper memory-wise. But my point remains: CPU-heavy applications don't necessarily rule out Node as a feasible alternative.

PS: V8 was 40x slower, not 400, in that one benchmark result you picked.

Re: Node.js - Convincing the boss guide

#26

Post by XLcommerce »

neovive wrote: post #5
tzaman wrote: post #3

Don't use Node if you have a lot of CRUD, because you'll still have to do a lot of stuff manually. Node's ecosystem is relatively young which means you'll have to do a lot of manual labor (as opposed to something like rails and mature, production-ready gems) and stitching of components. It cat get messy rather quickly, so my advice is "the right tool for the job". These guys nailed my point pretty good: http://www.pe…

Thanks for the link. I definitely agree. I've never used Node, but didn't want to dismiss any recommendations without fully researching the technology. Perhaps building the API in Node and leaving the CRUD to our existing server-side stack is an option.

This is the route I've gone. The core CRUD part of the app is PHP, and the real-time chat and document collaboration aspect of my app is node. Works beautifully. I've had so much fun working with node for the last few days.

Re: Node.js - Convincing the boss guide

#27

Post by jbooth »

arturadib wrote: post #25
jbooth wrote: post #22

Earlier quoted context omitted.

In that example, V8 javascript was 400x slower than the alternatives for matrix multiplication. That's because it's not binding to the BLAS libraries like the 'real' statistical languages. Of course, node supports calling out to C APIs, but that's not an argument for javascript, dynamic languages will naturally be terrible at math compared to C. More to the point: Node does nonblocking i/o but cpu work is in fact blo…

That's silly. No one in their sane mind would serve web requests AND do heavy processing in the same thread - no matter what language. In Node, you would have a process responding to web requests, and launch a separate process -- via a convenient child_process with built-in pipe communication -- for doing the heavy CPU work. The only case where that wouldn't make sense is if you need BOTH a ton of concurrency AND hea…

Well, in Java I serve rpc requests and doing heavy processing from the same thread all the time, and it works great.

What would we have to do in node to get the same level of performance? We'd need a front end instance delegating requests to 8 back-end instances for each core? Writing all these bytes over internal pipes and blowing L1/L2 cache all the time as the data moves across cores? At a certain point, isn't it just way easier and more effective to have one thread spinning an accept loop and a threadpool handling the requests, all within one process bound to a port?

As I said upthread, I'm using node for a side project right now and I'm liking server-side js for a variety of reasons, but squeezing every cycle out of the CPU is not one of them.

Re: Node.js - Convincing the boss guide

#28

Post by jroseattle »

We're running a nodejs+nosql+js-heavy-client project right now. While evaluating any stack component is an important task, it is certainly more so important in this environment.

This guide is OK, but it's insufficient. If you're going to do a technical evaluation of the node/nosql/js-client stack for risk assessment, you're going to need to get much more granular than what this guide offers. This is a fine guide for a project lead, but this is somewhat useless for the system designer.

For example, in reference to "nosql+node+buzzword+bull$#!t", the advice is to use nosql when you "really" know it, otherwise stick with mysql/postgres. While the devil-you-know-vs-devil-you-dont is a fine project mitigation strategy, it's not a very good technical strategy. Maybe the guide's author assumes one would do so, but the nosql/rdbms comparison exercise is not trivial and requires you to do your homework. Understanding and contrasting the finer points of comparing nosql operations vs. relational data stores is much more useful than a blanket comment.

Like I said, it's a fine guide, but it's much more useful for those who aren't necessarily responsible for determining the stack's applicability to a given project.

Re: Node.js - Convincing the boss guide

#29

Post by SkyMarshal »

hamidpalo wrote: post #10

Why is non-blocking IO radical? Tons of libraries and frameworks offered it much before node, including twisted, Java's NIO, and the entire System.Net namespace in .NET. Other than that, surprisingly sensible advice.

Not only is node non-blocking but all of its libraries are, unlike Python, Java, and .NET. I wouldn't call that radical per se, but distinguishing yes.
Post reply on HN