Node.js - A Giant Step Backwards • Hacker News Board

Re: Node.js - A Giant Step Backwards

#41

Post by rbranson » Fri, Aug 05, 2011, 2:59 AM UTC

benatkin wrote: post #28

rbranson wrote: post #15

This purist evented I/O fundamentalism has to stop. While evented I/O is great for a certain class of problems: building network servers that move bits around in memory and across network pipes at both ends of a logic sandwich, it is a totally asinine way to write most logic. I'd rather deal with threading's POTENTIAL shared mutable state bullshit than have to write every single piece of code that interacts with anyt…

redis is pretty badass for talking to other processes without really talking to other processes, and it's the #10 most depended-upon library on npm right now. http://search.npmjs.org/ It won't work for every problem, of course. dnode is a good way to easily talk to other node.js processes without the HTTP overhead. It can talk over HTTP too, with socket.io. node-http-proxy is useful as a load balancer, and a load bal…

Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback.

I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.

Re: Node.js - A Giant Step Backwards

#42

Post by walrus » Fri, Aug 05, 2011, 3:01 AM UTC

rmason wrote: post #20

I think it's a job for the jquery team, a node.js for the rest of us. Once they get jquery mobile out the door it would seem to be the most obvious next project.

node.js is node.js for the rest of us :) jQuery smooths out browser inconsistencies and replaces an overly verbose API (DOM). node.js has neither of these issues.

Re: Node.js - A Giant Step Backwards

#43

Post by randylahey » Fri, Aug 05, 2011, 3:04 AM UTC

gcr wrote: post #34

randylahey wrote: post #17

Earlier quoted context omitted.

It's kind of a dick move to make a inflammatory, flamebait blog post and then later admit you didn't actually know what you were talking about. Maybe you should have actually understood the technology you were working with before making knee-jerk snap judgements.

How was your first experience with node.js different than Fenn's?

Sure, everyone has to start somewhere, and to be perfectly honest, I ran into many of the same issues.

The difference is in what happened afterward. What I did then was to try to understand why Node.js did things differently and how I could accomplish my goals in an idiomatic way. I didn't try to shoe-horn in my existing mental framework for how things should work, and then throw my hands in the air when they didn't.

However, what I didn't do was immediately run to Alert the Internets about what "A Giant Step Backward" Node.js is.

Re: Node.js - A Giant Step Backwards

#44

Post by benatkin » Fri, Aug 05, 2011, 3:08 AM UTC

randylahey wrote: post #17

Fenn wrote: post #12

Earlier quoted context omitted.

I heartily agree - I may have overstated my case slightly with the "Giant Step Backwards", it just definitely seemed that way on initial experience. It also made for a better title than "Confusion, Then Indifference, Slowly Turning Into Understanding & Affinity"

It's kind of a dick move to make a inflammatory, flamebait blog post and then later admit you didn't actually know what you were talking about. Maybe you should have actually understood the technology you were working with before making knee-jerk snap judgements.

It's not an inflammatory blog post. The headline might be a little annoying to some, but not to most of us. There are negative headlines about every programming language platform.

Also it's a reminder for Node.js developers to make good use of async patterns, lest their code look silly. Besides async, which Fenn mentions in the comments, there's EventEmitters and Backbone.js for doing different styles of async programming. And there are a few other libraries that are a lot like https://github.com/caolan/async .

Re: Node.js - A Giant Step Backwards

#45

Post by benatkin » Fri, Aug 05, 2011, 3:14 AM UTC

rbranson wrote: post #41

benatkin wrote: post #28

Earlier quoted context omitted.

redis is pretty badass for talking to other processes without really talking to other processes, and it's the #10 most depended-upon library on npm right now. http://search.npmjs.org/ It won't work for every problem, of course. dnode is a good way to easily talk to other node.js processes without the HTTP overhead. It can talk over HTTP too, with socket.io. node-http-proxy is useful as a load balancer, and a load bal…

Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback. I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.

I didn't mention any of those libraries in my reply to your original comment. To help alleviate callback noise, there's https://github.com/caolan/kanso , which Fenn mentions in his blog post's comments, and there are EventEmitters, and there is Function.bind() and Backbone.js-style async, where you have methods that describe what each callback does. (Backbone is usable in Node.js but perhaps not as practical on the server as it is on the client.)

Also callbacks to me are kind of like parenthesis in Lisp. They're annoying but they're for the greater good. :)

Re: Node.js - A Giant Step Backwards

#46

Post by daakus » Fri, Aug 05, 2011, 3:27 AM UTC

Detrus wrote: post #22

The V8 team is thinking of adding yield/defer support to make programming in Node neater. There's hope yet. Meanwhile there are other choices that are about as easy, like Python libraries and Google's Go. Too bad they don't have the same zealous community support.

Marcel Laverdet has built a node extension that provides yield: https://github.com/laverdet/node-fibers

Re: Node.js - A Giant Step Backwards

#47

Post by UncleOxidant » Fri, Aug 05, 2011, 3:30 AM UTC

benatkin wrote: post #45

rbranson wrote: post #41

Earlier quoted context omitted.

Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback. I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.

I didn't mention any of those libraries in my reply to your original comment. To help alleviate callback noise, there's https://github.com/caolan/kanso , which Fenn mentions in his blog post's comments, and there are EventEmitters, and there is Function.bind() and Backbone.js-style async, where you have methods that describe what each callback does. (Backbone is usable in Node.js but perhaps not as practical on the s…

"deal with it" is a good response. personally, I'd rather write callbacks than deal with threads any day. And there are plenty of approaches to make dealing with callbacks easier (async.js is one of many).

Re: Node.js - A Giant Step Backwards

#48

Post by azakai » Fri, Aug 05, 2011, 3:45 AM UTC

Detrus wrote: post #22

The V8 team is thinking of adding yield/defer support to make programming in Node neater. There's hope yet. Meanwhile there are other choices that are about as easy, like Python libraries and Google's Go. Too bad they don't have the same zealous community support.

> The V8 team is thinking of adding yield/defer support to make programming in Node neater. There's hope yet.

There is SpiderNode, not sure what the status of it is, but it replaces V8 in node.js with SpiderMonkey. SpiderMonkey already has yield and much other new JS syntactic sugar.

http://blog.zpao.com/post/4620873765/about-that-hybrid-v8mon...

Re: Node.js - A Giant Step Backwards

#49

Post by rbranson » Fri, Aug 05, 2011, 3:47 AM UTC

UncleOxidant wrote: post #47

benatkin wrote: post #45

Earlier quoted context omitted.

I didn't mention any of those libraries in my reply to your original comment. To help alleviate callback noise, there's https://github.com/caolan/kanso , which Fenn mentions in his blog post's comments, and there are EventEmitters, and there is Function.bind() and Backbone.js-style async, where you have methods that describe what each callback does. (Backbone is usable in Node.js but perhaps not as practical on the s…

"deal with it" is a good response. personally, I'd rather write callbacks than deal with threads any day. And there are plenty of approaches to make dealing with callbacks easier (async.js is one of many).

Actually, "deal with it" is fucking lame, isn't a response at all, and is a good example of why I use the term "fundamentalism."

Is your problem with threads or shared mutable state? Web applications should be stateless and can be written as long request-response pipelines on-top of a pool of actor threads, with the only shared state existing at either ends of the pipeline, probably hidden by a framework anyways.

Re: Node.js - A Giant Step Backwards

#50

Post by chrisohara » Fri, Aug 05, 2011, 3:48 AM UTC

rbranson wrote: post #41

benatkin wrote: post #28

Earlier quoted context omitted.

redis is pretty badass for talking to other processes without really talking to other processes, and it's the #10 most depended-upon library on npm right now. http://search.npmjs.org/ It won't work for every problem, of course. dnode is a good way to easily talk to other node.js processes without the HTTP overhead. It can talk over HTTP too, with socket.io. node-http-proxy is useful as a load balancer, and a load bal…

Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback. I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.

the thinking that async code == callback spaghetti shit has to stop.

There are plenty of async idioms that make callbacks a breeze.