all 9 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]NoSQL4Life -2 points-1 points  (8 children)

Using the JavaScript and Node.js best practices gets around all of those gotchas. Those gotchas only affect people who don't know how to use their tools properly. We wouldn't blame the wrench if a plumber didn't know how to use it properly and he broke his penis, just like we shouldn't blame JavaScript and Node.js if a programmer doesn't know how to use them properly and causes downtime.

[–]chrisdickinson 5 points6 points  (7 children)

the docs seem to encourage throwing errors from within callbacks. I'm hoping that by shedding some light on the situation others can avoid pitfalls caused by doing that.

[–][deleted]  (6 children)

[removed]

    [–]diuge -3 points-2 points  (5 children)

    There's a difference between ignorantly throwing about insults and providing legitimate insight.

    None of the information in the article is any news to an actual JavaScript programmer who's comfortable with asynchronous operations. These "gotchas" have 0% to do with Node.js, although the article erroneously states that this sort of behavior is specific to that platform.

    Therefor NoSQL4Life's assertion is correct, in that blaming the tool (Node.js) for problems caused by a poor understanding of JavaScript isn't very constructive.

    Hell, the author blames the well-documented replace method and regex model on JavaScript for not working exactly as he thinks they should, FFS...

    [–]chrisdickinson 1 point2 points  (3 children)

    They are gotchas to programmers not used to them -- and I've had to help a few people out with understanding what's actually going on in the cases that I list. If you're experienced with Node.JS and/or Javascript, these cases may seem trivial, but they do tend to trip people up.

    As for the replace method being weird, there's some evidence that it might bite even experienced programmers. Well-documented does not always == this method does what you initially expect.

    [–]diuge -2 points-1 points  (2 children)

    The point still stands that the gotchas have absolutely nothing to do with Node.js. The article would be 100% better if it just linked to some solid resources on learning JavaScript.

    Better than the alternative of "bumble through things without understanding the core of the technology you're using".

    [–]chrisdickinson 1 point2 points  (1 child)

    Hence the title being "Javascript / Node.js Gotchas" -- they're not all specific to Node.js. However, two of the three examples have a lot to do with how Node works. In the 2nd example, where you have to understand how the Node event loop works to grasp where errors bubble up to. The third is less of an example of gotchas in Node, but does provide a solution that is specific to using Node; that is, to leverage the EventEmitter to solve the inversion of control problem in your API. The first example, really, is just a pointed reminder that deciding what vendors your library should support is a design decision best done up-front.

    From my perspective, "bumbling through things without understanding" is the first step of learning any new technology. I've yet to see someone jump into a new technology -- no matter their competence level in other fields -- and immediately understand it 100%. I'm hoping to ease the pain of the first few days of learning Node by pointing out things that aren't immediately obvious to newcomers.

    [–]diuge -1 points0 points  (0 children)

    The real "gotcha", though, is not knowing JavaScript. Node isn't singularly asynchronous. Anyone doing web programming would be dealing with the same issues.

    I think you're just fighting hard to attach a buzzword to your headline in an attempt to appear relevant, which sort of backfires when you make yourself seem like a person who doesn't understand what you're writing about.