Hacker News Reader

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

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.

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-probab...

2) http://modulecounts.com/

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.

Different yes, conflicting no.

ES6 standard promises have landed in v8 (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.

And I'd observe that all three of the things I mentioned ("async", threading, static typing) are firmly in the "not" camp.

If the Node community admits these are desirable characteristics of a programming development environment, then they've lost, because they can not compete on any of those three fronts. The entire value proposition of Node was basically that those three things weren't important. If they are, Node's arrogant swagger turns into a frantic attempt to cobble together enough functionality to pretend to have the features that exist better elsewhere.

Don't think you can sell me on fundamental weaknesses in your language of choice being features, twerquie. I've got too much experience in too many environments to fall for that.

Why, it's almost as if Node is built on fundamentally 1990s scripting technology based on fundamentally 1970s event-based ideas or something, instead of being the radical revolutionary departure we all know it really is.

It is true though that many js deficiencies have turned out to be factors contributing to node's popularity. A lack of namespaces, standard library and import/require come to mind.

I'm not interested in arguing about technical superiority, I'm sure node is no where close to ideal. But, like javascript itself, it's popular, interesting, useful, and here to stay. From my perspective, for better or worse, javascript is the most important programming language of the decade.

"a) A small core API instead of a sprawling standard class library"

Using adjectives to accentuate, does not an argument make. "small/core" and "sprawling" all have loaded meanings. And if you wish to convert anyone but the already-converted sub-culture inhabitants, you should probably quantify what you mean and why it's a benefit.

I think my point is clear when you read what I wrote as a whole instead of dissecting parts. I'm allowed to editorialize a bit, am I not? I'm not a robot nor am I writing my thesis on the subject, we're just talking here.

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.

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.

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 [2] https://github.com/visionmedia/co [3] https://github.com/CrabDude/trycatch

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

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.

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

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

Instead of flippantly dismissing the comments, maybe you should think about what people are saying.

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