Comment by travisglines | Hacker News Reader

Comment by travisglines | Hacker News Reader

As someone who has spent the last six months coding in Node.js, I completely disagree with this notion.

One of my favorite advantages of Node is in fact that it is based on javascript. When building my application I can share code between client/sever side (string formatting methods for example) and don't need to do any mental context switching when it comes to languages. I've developed in javascript for years and all that I have learned doesn't go out the window here, all I need to do is learn how to use a few libraries.

The "faults" of javascript are primarily inexperience with event looped architectures that use callbacks (people complaining about having to use callbacks and the spaghetti code messes they make), people remembering the past horrible browser implementations of it (where something would work/be fast in one browser and not another ... Internet Explorer I'm looking at you) and confusion over how prototypical languages work vs. standard OOP.

Callbacks aren't that bad and a few extra nesting levels shouldn't create chaos in your code. Since its based entirely off of one javascript implementation (V8) the cross browser stuff is gone. How it handles OOP is different, just watch these videos first and you'll be fine: http://www.yuiblog.com/blog/2007/01/24/video-crockford-tjpl/

As far as speed goes it gets huge benefits by being javascript. Every time the Google coding machine feels like making V8 a little faster, Node gets faster too.

Yes its different, no its not worse ... its better but takes some getting used to.

I think the fundamental objection fogus has is that the language does not support the programming model. For example, I can program object-orientedly in C, but that language does not help me do it. I have to do much of the work myself. So you can program in JavaScript in an event-based way using Node.js, but JavaScript itself does not help you much in doing so. It requires that you do most of the work yourself - work that is mechanical, and basically requires that you be a human compiler.

Disclaimer: I don't program in JavaScript or Node.js. So I'm talking from conceptual understanding, not experience.

It requires that you do most of the work yourself - work that is mechanical, and basically requires that you be a human compiler.

It would be a good idea to write some JavaScript before you make statements like these with so much conviction.

Fair enough, but the examples I've seen look like continuation passing style (http://en.wikipedia.org/wiki/Continuation-passing_style), which is something we know how to abstract behind language syntax and semantics. In what way am I wrong?

Programming in an "event-based way" is a huge part of writing traditional JavaScript in the browser. You're handling user events, Ajax responses, the page load itself. And JavaScript's first-class functions and closures are extremely well-suited to the task.

Ah, yes, you are correct. Then consider for the sake of discussion that I said "asynchronous."

"The "faults" of javascript are primarily inexperience with event looped architectures that use callbacks"

Maybe for a lot of people this is true, but for me the faults of javascript are ingrained language "features". Actually, I'm not the only one who thinks so, because theres a website dedicated to it[1].

[1] http://wtfjs.com/

The latest example on that blog (from Feb. 5th) examines the unexpected effects of type coercion when using double-equals for comparison. That's fine, as far as it goes, but, like most of these examples, it's a WTF that experienced JavaScript developers know how to mitigate (triple-equals) and not that big of a problem in practice. I'm trying to think of a time that JavaScript's wacky coercion rules actually bit me and I can't.

Well, the wacky coercion rules are just one of many Javascript gotchas. I agree that most of them won't affect an experienced javascript programmer, but that doesn't mean its not a language fault. For example, in C, most programmers will know to check bounds or to use strncpy instead of strcpy, but a lot of C code that has buffer overruns still slips through.

My point is that any language fault can be memorized and worked around, but that doesn't make it go away. Also, I've noticed a lot of non-experts using javascript, so if the obvious solution isn't the correct one (using == vs using === for example), then that does cause real problems.

Note that I'm not saying Javascript is an especially bad language, just that it has, in my opinion, some severe faults.

Reply on news.ycombinator.com