Learn Node.js The Troll Way | Hacker News Reader

Learn Node.js The Troll Way

nathanleclaire.com

31 pointsAshuu11 comments

> "I decided to bring a gun to a knife fight and add methods to String’s prototype."

Don't do this. Extending native prototypes in node is terrible practice since it ruins the thing node gets very right: code encapsulation. Not good advice at all.

Is it "always" correct to extend the String prototype? No.

Is it "always" correct to NOT extend the String prototype? No.

Like all things it depends. If you are writing a library for others to use then you shouldn't be extending globals for the reasons you have given. And if you do, you need a good reason and make it very clear to the user. If you are writing an application or a closed-source library, then it is usually safe to extend globals because you are in complete control. Like others have said in the String case, it makes its a lot easier to read the functions that do string manipulation.

The only absolute rule in software engineering is that there are no absolute rules.

Agreed, but it'd be different if this was aimed at seasoned developers, but it's aimed at beginners, as such, it's irresponsible.

Extending a core language prototype is never necessary. And you never know which library will break when you do this (unless you review carefully the entire code of all modules you use). So it is a bad practice, despite sometimes being ok.

I admit that extending the String prototype is less dangerous than e.g. the Object or Array prototype.

How does node get this 'very right'? Why is the 'code encapsulation' ruined now that he's monkey patched String? What should he have done instead?

I personally love monkey patching system libraries, it makes your code look pretty. I guess it's one of the guilty pleasures of a Ruby developer.

On the subject of awesome languages like Ruby, did you know that C# actually has a way of safely monkey patching system libraries? It's called 'extension methods' and it's actually the bees knees. Too bad C# has a proprietary side that makes it less desirable for business critical software, leaving us with Ruby.

He/she should have just used a regular method. Yeah it makes the code pretty, but it pollutes every library in your environment. You don't do this for the exact same reason you don't use globals. String.prototype is a global. Don't mess with it.

By not messing with globals, node allows you to safely load multiple versions of the same module and not worry about strange runtime environment changes. It probably doesn't matter in this trivial case, but node's primary win is how easy and safe it is to write and share modular code so yeah, prototype pollution is a destructive anti-pattern.

It's the kind of thing that could possibly be OK in nodejs but is not OK in the browser. My biggest problem with it (and how it goes down in Rails for that matter) is that you can inadvertently clobber variables in namespaces you don't own. Changing the prototype of String there will change it in the context of every 3rd party library that's also running. It just doesn't scale with the codebase.

> possibly be OK in nodejs but is not OK in the browser.

I think you've got that around the wrong way. It's more of a problem in node/browserify because you're typically working with very many more 3rd party libraries.

Yeah, that's fair. The bottom line is please never do it or teach noobs to do it without telling them why it's wrong.

He's not writing production code, he's writing a hack to harass his brother. I think monkey patching is just fine in such circumstances.

    if ( $(index).html().match(/^".*"$/) ) {
        return true;
    } else {
        return false;
    }

Gah!

Reply on news.ycombinator.com