4 ms·

It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor dev

by yid 12y ago

It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development practices or not understanding norms in JS. JS isn't without its flaws, but can we at least put a few fallacies to rest: > callback hell There's no reason to be in callback hell if you use an asynchronous control flow library and stick to the standard style of function signatures. I love @caolan's async [1]. In particular, there's a control flow pattern called `auto` that really (IMO) demonstrates some of the power of async programming: it's a full dependency graph resolver [2]. > single-threaded There's the cluster module, but nevermind that -- you can always just use the child_process library [3] to access spawn() and fork(). Remember those? Processes are a more nautral match for distributed computing than threads anyway. > lack of strict typing Strict typing won't make you a better developer, and you can enforce some degree of type correctness with Closure compiler annotations. [1] https://github.com/caolan/async https://github.com/caolan/async [2] https://github.com/caolan/async#auto https://github.com/caolan/async#auto [3] http://nodejs.org/api/child_process.html http://nodejs.org/api/child_process.html

codystebbins 12y ago
Another upcoming method to avoid callback hell that is my personal favorite is harmony generators and yield. Reminds me so much of C# async. Two great libraries can handle it today on beta versions of node [1,2]. I have only used suspend. See this gist for comparison https://gist.github.com/codystebbins/a2c354d25ce28879bfe1 https://gist.github.com/codystebbins/a2c354d25ce28879bfe1. With generators try/catch can be used, avoiding a lot of the redundant error handling. Crabdude's library can avoid the overhead of try/catch [3]. And if developers want static typing, they should check out TypeScript. Works great with node. [1] https://github.com/jmar777/suspend https://github.com/jmar777/suspend [2] https://github.com/visionmedia/co https://github.com/visionmedia/co [3] https://github.com/CrabDude/trycatch https://github.com/CrabDude/trycatch
jebblue 12y ago
>> Strict typing won't make you a better developer It won't make you a worse developer either. Loose typing can make you a worse developer because it's easier to make mistakes that sometimes aren't caught until after it's in production.
gss77 12y ago
"There's no reason to be in callback hell if you use an asynchronous control flow library" There's no good reason to pile flawed layers on top of eachother. If you have a fully yieldable/resumable VM (e.g. Lua), you can just solve the problem properly in the first place, in a way that doesn't then require a second or third layer of workarounds to be usable.
jerf 12y ago
But... if you're going to bolt on an "async" library, bolt on threading, and bolt on strict typing, why not use something that starts with that stuff? And ends up doing it better since it was actually created with that stuff in mind, instead of aftermarket bolt-ons? Saying that those things "fix" Node amounts to an admission that you shouldn't have started with Node in the first place.
- twerquie 12y ago
  Because bolting reusable libraries together is 90% (meaningless number alert) of what we do when assembling modern applications. And in this respect, Node is perfectly suited to the job, boasting a) A small core API instead of a sprawling standard class library b) A highly composable export and require mechanism, better in some interesting ways than what exists in other systems (1) c) The fastest growing and soon to be largest community repository of packages (2) d) asynchronous by default stack and ecosystem. With those things in hand, "bolting on" is a virtue and not a disadvantage. That Node is general-purpose - you can build cross-platform desktop applications, streaming servers, web applications, console utilities, etc - and does not impose its package opinions are major factors in its success. 1) http://blog.izs.me/post/1675072029/10-cool-things-you-probably-didnt-realize-npm-could-do http://blog.izs.me/post/1675072029/10-cool-things-you-probab... 2) http://modulecounts.com/ http://modulecounts.com/
  - awj 12y ago
    Bolting reusable libraries together is great for some things, not so much for others. How much of that large package repository uses different (or worse, conflicting) solutions for abstracting async programming? Some batteries really are better off being included.
    - twerquie 12y ago
      Different yes, conflicting no. ES6 standard promises have landed in v8 (https://code.google.com/p/v8/source/browse/trunk/src/promise.js https://code.google.com/p/v8/source/browse/trunk/src/promise...) so it's only a short matter of time until the "batteries included" solution is available. But that doesn't mean people will be forced to use them.
mantrax6 12y ago
But, of course, the "if we don't like Node.JS, we just don't understand the true way(tm) of using it" card. Such narratives usually get louder and louder, until they flip and all the former supporters of X suddenly proclaim "I can't keep quiet anymore, I must speak against X". I've seen this too many times. I like Node.JS, it's a good thing it exists, but no technology is perfect and we should be capable of honestly discussing the strengths and weaknesses of a given technology. No comment on typing, if you can't bother to do basic research over whether what you say makes sense in real projects. I'll just say that in 2014 proclaiming that your multicore application architecture is spawn() and fork() can only induce laughter in the presence of proven distributed computing algorithms that don't require every developer to use a roll-your-own message passing library and protocols.
yid 12y ago
Sigh...commenting on a Node thread on Hacker News, what was I thinking?
- awj 12y ago
  Instead of flippantly dismissing the comments, maybe you should think about what people are saying.
  - yid 12y ago
    The whole point is that nothing new is being said here. Node is obviously a polarizing issue, and if you look at my comment, I was careful not to make the claim that its good for everything. "JS isn't without its flaws," I said. And yet, I see "platitudes", "if you can't bother to do basic research", "can only induce laughter", "pile flawed layers on top of each other", and "amounts to an admission that you shouldn't have started with Node in the first place". And the meaningful comments have the "reply" link disabled for me, so...
awj 12y ago
...I'm not sure you're understanding the point of those objections. > callback hell It's great that there are better options out there for handling async programming, but at the end of the day you're still using callbacks for control flow. Having to partition out application logic across I/O events sucks, and picking a model where that is the only option is going to raise some objections. Especially when you have languages like Lua that use coroutines to manage the exact same performance guarantees without the code organization headaches. > single-threaded The complaint about single-threaded evented servers is that the performance of the whole system relies on you correctly answering the "will this piece of code perform extensive computation" question at every point in your program. That's not an impossible challenge, but I don't think it's an unreasonable one to complain about. > lack of strict typing No, strict typing won't make you a better developer, but it certainly will help save you from yourself. Again, writing extensive amounts of application code in a tool that comes just short of actively hindering correctness is an exercise in frustration. You shouldn't be surprised that people object to this. I think it's great when people look at all of these issues and decide that Node is still valuable for their use case despite them. It seems like there are a lot of bandwagoneers who aren't making that kind of evaluation, and I think it's a good idea to keep hammering away on these downsides until they do.
rdtsc 12y ago
I view async style wrappers not really getting away from callback hell. Calling it async doesn't make it better. Python's Twisted has been around for ages with world class "async" and it is a pain to work with in large code base. Callbacks and async does work for demos and toy projects, which is I think one reason they got some adoption. Representing concurrency contexts as a chain of callback functions or promises/futures/yields I posit is usually worse than a green thread or actor that gets and sends messages. It doesn't mean it cant' be done but if feels like why go through that pain when there are real threads/goroutines/tasks/Erlang processes. > you can always just use the child_process library [3] to access spawn() and fork(). Remember those? Processes are a more nautral match for distributed computing than threads anyway. I can do that with regular OS processes what does Node.js give me then? I can spawn processes from C, Python, anything. > lack of strict typing Weak typing is insane. This is 2014, there is not reason to silently turn "5"+[]+5 into anything except an exception. This isn't about a better developer, this is about sanity. Now I like use dynamic typing a-la Python and Erlang. But those have strong types. Adding a 5 to a string will blow up.

by yid 12y ago

codystebbins 12y ago

Another upcoming method to avoid callback hell that is my personal favorite is harmony generators and yield. Reminds me so much of C# async. Two great libraries can handle it today on beta versions of node [1,2]. I have only used suspend. See this gist for comparison https://gist.github.com/codystebbins/a2c354d25ce28879bfe1 https://gist.github.com/codystebbins/a2c354d25ce28879bfe1. With generators try/catch can be used, avoiding a lot of the redundant error handling. Crabdude's library can avoid the overhead of try/catch [3]. And if developers want static typing, they should check out TypeScript. Works great with node. [1] https://github.com/jmar777/suspend https://github.com/jmar777/suspend [2] https://github.com/visionmedia/co https://github.com/visionmedia/co [3] https://github.com/CrabDude/trycatch https://github.com/CrabDude/trycatch

jebblue 12y ago

>> Strict typing won't make you a better developer It won't make you a worse developer either. Loose typing can make you a worse developer because it's easier to make mistakes that sometimes aren't caught until after it's in production.

gss77 12y ago

"There's no reason to be in callback hell if you use an asynchronous control flow library" There's no good reason to pile flawed layers on top of eachother. If you have a fully yieldable/resumable VM (e.g. Lua), you can just solve the problem properly in the first place, in a way that doesn't then require a second or third layer of workarounds to be usable.

jerf 12y ago

But... if you're going to bolt on an "async" library, bolt on threading, and bolt on strict typing, why not use something that starts with that stuff? And ends up doing it better since it was actually created with that stuff in mind, instead of aftermarket bolt-ons? Saying that those things "fix" Node amounts to an admission that you shouldn't have started with Node in the first place.

twerquie 12y ago
Because bolting reusable libraries together is 90% (meaningless number alert) of what we do when assembling modern applications. And in this respect, Node is perfectly suited to the job, boasting a) A small core API instead of a sprawling standard class library b) A highly composable export and require mechanism, better in some interesting ways than what exists in other systems (1) c) The fastest growing and soon to be largest community repository of packages (2) d) asynchronous by default stack and ecosystem. With those things in hand, "bolting on" is a virtue and not a disadvantage. That Node is general-purpose - you can build cross-platform desktop applications, streaming servers, web applications, console utilities, etc - and does not impose its package opinions are major factors in its success. 1) http://blog.izs.me/post/1675072029/10-cool-things-you-probably-didnt-realize-npm-could-do http://blog.izs.me/post/1675072029/10-cool-things-you-probab... 2) http://modulecounts.com/ http://modulecounts.com/
- awj 12y ago
  Bolting reusable libraries together is great for some things, not so much for others. How much of that large package repository uses different (or worse, conflicting) solutions for abstracting async programming? Some batteries really are better off being included.
  - twerquie 12y ago
    Different yes, conflicting no. ES6 standard promises have landed in v8 (https://code.google.com/p/v8/source/browse/trunk/src/promise.js https://code.google.com/p/v8/source/browse/trunk/src/promise...) so it's only a short matter of time until the "batteries included" solution is available. But that doesn't mean people will be forced to use them.

mantrax6 12y ago

But, of course, the "if we don't like Node.JS, we just don't understand the true way(tm) of using it" card. Such narratives usually get louder and louder, until they flip and all the former supporters of X suddenly proclaim "I can't keep quiet anymore, I must speak against X". I've seen this too many times. I like Node.JS, it's a good thing it exists, but no technology is perfect and we should be capable of honestly discussing the strengths and weaknesses of a given technology. No comment on typing, if you can't bother to do basic research over whether what you say makes sense in real projects. I'll just say that in 2014 proclaiming that your multicore application architecture is spawn() and fork() can only induce laughter in the presence of proven distributed computing algorithms that don't require every developer to use a roll-your-own message passing library and protocols.

yid 12y ago

Sigh...commenting on a Node thread on Hacker News, what was I thinking?

awj 12y ago
Instead of flippantly dismissing the comments, maybe you should think about what people are saying.
- yid 12y ago
  The whole point is that nothing new is being said here. Node is obviously a polarizing issue, and if you look at my comment, I was careful not to make the claim that its good for everything. "JS isn't without its flaws," I said. And yet, I see "platitudes", "if you can't bother to do basic research", "can only induce laughter", "pile flawed layers on top of each other", and "amounts to an admission that you shouldn't have started with Node in the first place". And the meaningful comments have the "reply" link disabled for me, so...

awj 12y ago

...I'm not sure you're understanding the point of those objections. > callback hell It's great that there are better options out there for handling async programming, but at the end of the day you're still using callbacks for control flow. Having to partition out application logic across I/O events sucks, and picking a model where that is the only option is going to raise some objections. Especially when you have languages like Lua that use coroutines to manage the exact same performance guarantees without the code organization headaches. > single-threaded The complaint about single-threaded evented servers is that the performance of the whole system relies on you correctly answering the "will this piece of code perform extensive computation" question at every point in your program. That's not an impossible challenge, but I don't think it's an unreasonable one to complain about. > lack of strict typing No, strict typing won't make you a better developer, but it certainly will help save you from yourself. Again, writing extensive amounts of application code in a tool that comes just short of actively hindering correctness is an exercise in frustration. You shouldn't be surprised that people object to this. I think it's great when people look at all of these issues and decide that Node is still valuable for their use case despite them. It seems like there are a lot of bandwagoneers who aren't making that kind of evaluation, and I think it's a good idea to keep hammering away on these downsides until they do.

rdtsc 12y ago

I view async style wrappers not really getting away from callback hell. Calling it async doesn't make it better. Python's Twisted has been around for ages with world class "async" and it is a pain to work with in large code base. Callbacks and async does work for demos and toy projects, which is I think one reason they got some adoption. Representing concurrency contexts as a chain of callback functions or promises/futures/yields I posit is usually worse than a green thread or actor that gets and sends messages. It doesn't mean it cant' be done but if feels like why go through that pain when there are real threads/goroutines/tasks/Erlang processes. > you can always just use the child_process library [3] to access spawn() and fork(). Remember those? Processes are a more nautral match for distributed computing than threads anyway. I can do that with regular OS processes what does Node.js give me then? I can spawn processes from C, Python, anything. > lack of strict typing Weak typing is insane. This is 2014, there is not reason to silently turn "5"+[]+5 into anything except an exception. This isn't about a better developer, this is about sanity. Now I like use dynamic typing a-la Python and Erlang. But those have strong types. Adding a 5 to a string will blow up.