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

31–40 of 85 posts

Re: Node.js - Convincing the boss guide

#31

Post by mcantelon »

jbooth wrote: post #18
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.

It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world. I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks.…

>doesn't really have any performance benefits in the multicore world

AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.

Re: Node.js - Convincing the boss guide

#32

Post by xyzzyb »

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…

I completely agree, and wrote an article on this while I was frustrated with a node.js project at work that was trying to throw node, backbone, require, mustache, mocha, and dynamoDB.

http://rakeroutes.com/blog/the-problem-with-completely-clien...

Re: Node.js - Convincing the boss guide

#33

Post by tzaman »

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

I have to disagree. I understand that you can get quickly the feeling that you have to do a lot of stuff manually with node because node packages (gems in node) are more kind of atomic and not full-blown like rails. You can quickly setup a rails-like-environment with node packages. There are different web frameworks which are a refreshing take compared to rails and provide same or better functionality. ORMs like Acti…

Prove it:

What is node equivalent of: "rails g resource User email:string password:string"? AFAIK there is none. At least not one that would take care of migrations, validation, security, logic and views.

And if I want to use postgres? Sure, there's a npm package. But it's for queries, I still need to define models and validation manually.

....

Re: Node.js - Convincing the boss guide

#34

Post by jbooth »

mcantelon wrote: post #31
jbooth wrote: post #18

Earlier quoted context omitted.

It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world. I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks.…

>doesn't really have any performance benefits in the multicore world AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.

From what I could tell, that spawns actual child processes and communicates with them over pipes. Fine from an architectural standpoint, but a penalty compared to shared memory from a performance standpoint. And it still has the problem of a single heavy CPU request on a given worker blocking all the requests behind it on that worker.

Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying if you really need to crank out performance, use java.util.concurrent, or maybe Go. They both offer event-driven i/o if you really want it, and have better threading models.

Re: Node.js - Convincing the boss guide

#35

Post by cageface »

Go seems to me to provide the benefits of Node's non-blocking IO with a much easier programming model and a much less warty language. But I haven't actually built anything real in either language yet.

Anyone with experience in both care to contrast them? Their problem domains seem to overlap quite a bit.

Re: Node.js - Convincing the boss guide

#36

Post by yesbabyyes »

hsmyers wrote: post #8

JavaScript seems to be having the same problem that other languages have developed over usage time. It becomes increasingly difficult to know what package does what and more importantly information of the pros and cons of the package. Does anyone know of a link to something similar to what I'm talking about? Say something meaningful about the top N (where N might be 10 or so) packages---what they do, the good and the…

Peteris Krumins had a nice series of Node.js modules you should know about: http://www.catonmat.net/category/nodejs-modules

Some of my favorites:

  - async -- flow control
  - stitch -- packaging client side scripts
  - express -- web framework
  - redis -- great Redis client
  - stylus -- css preprocessor
  - request -- HTTP client
I find myself following certain people, like how I'm a fan of different rappers. Usually, stuff by visionmedia, felixge, mikeal, isaacs, substack is top notch.

Re: Node.js - Convincing the boss guide

#37

Post by tzaman »

neovive wrote: post #21
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.

It's not a black/white situation here. Being the boss, I know sometimes (most of the time, to be honest) we need to stick to proven and tested stuff, as economic times are not the prettiest and clients that would pay for the extra mile don't just sit around.

What happens when you assign 2 developers on a project that they are very passionate and enthusiastic about because you allowed them to use, say, node.js.

Only to discover in a month or two that they spent 200 hours more that they would if they used something proven and tested. That's several k$ out of the window and maybe milestone not met.

Sometimes it's worth it, sometimes it's not.

Re: Node.js - Convincing the boss guide

#38

Post by gizzlon »

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…

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

Sure you could, depends on what you are doing.. In many cases it's fine that the request takes a second to complete, but blocking the entire server for 1 second is not.

Guess you define "heavy processing" a little differently, but in event driven you can't do any (blocking) processing

Re: Node.js - Convincing the boss guide

#39

Post by bmelton »

mnutt wrote: post #19
hsmyers wrote: post #8

JavaScript seems to be having the same problem that other languages have developed over usage time. It becomes increasingly difficult to know what package does what and more importantly information of the pros and cons of the package. Does anyone know of a link to something similar to what I'm talking about? Say something meaningful about the top N (where N might be 10 or so) packages---what they do, the good and the…

Check out the Node Toolbox: http://toolbox.no.de/ It doesn't seem as fleshed out as the Ruby Toolbox ( https://www.ruby-toolbox.com ) and could use a bit more editorial for your purposes, but it's a good place to start.

Thanks a ton for posting that. I'm new to Node, and it's a great help.

Of course, it'll never go anywhere until whomever is maintaining it either allows for crowdsourcing of the data or tries harder, because the first couple of packages I looked at had very poor descriptions.

Coffeescript, for example, is defined as "Unfancy JavaScript". CS is one that I happen to know about, and by that definition, I'd have never ever switched to it.

Re: Node.js - Convincing the boss guide

#40

Post by edwinnathaniel »

tferris wrote: post #23
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.

"Just Try It" is not enough for Node to be quite frank.

Some people tried it and still couldn't see what they missed. I wouldn't call them blind afterward either. If it fits your taste bud then great, if not... no biggie.

Post reply on HN