Rather than creating some other util global, just extend underscore.js with any additional methods you want.

JS Util solution using underscore.js

// If you don't use underscore.js, use it (http://documentcloud.github.com/underscore/)
// Then, use underscore's mixin method to extend it with all your other utility methods
// like so:
_.mixin({
    escapeHtml: function () {
        return this.replace(/&/g,'&')
            .replace(/>/g,'>')
            .replace(/</g,'&lt;')
            .replace(/"/g,'&quot;')
            .replace(/'/g,'&#39;');
    },

    otherFunc: function () {
        // etc, etc.
    }
});

// simple. but. handy.

the problem is that you are adding functionalities that aren't present on underscore.js by default and that could lead to confusion and incompatible code. modules should be self-contained and depend as less as possible on external code.

I'm just saying that since I got to this gist coming from your article about backbone.js as a good way to structure the code, and I don't think that extending an object you don't own is a good idea for scalable/maintainable applications (not that it is a big deal in most of the cases).

presentation about maintanable JavaScript (special detail to slide 16) and scalable JavaScript application

cheers.

maybe a seperate namespace for extensions would be nicer (and better to maintenence after an update) like MM mentioned:

_.ext.myname.myfunction()

_.com.mydomainname.myfunction()

@muescha, you're missing the point, my friend. The whole reason I like doing it with underscore is that it keeps your code clean. Obviously you could store your utility functions wherever you want and generally namespacing an app is a good idea. However, the whole point is I can use a simple utility function by doing something like this:

_.myFunction()

Instead of the Java class naming you suggest (which frankly, gives me a headache).

Also, underscore lets you use the OOP style so you can also call it like this:

_({my: 'object'}).myFunction(my, other, args);

Which would look downright ugly with big namespaces.

Maybe all you need is an easy way to add the OOP style to your own namespaces.

There's absolutely nothing wrong with this approach. As HenrikJoreteg already mentions, you can still keep you own code structured and namespaced anyway you like. For instance if your namespacing your code using object literals a simple line could extend methods to underscore.js for convenience - ie.

_.mixin( MY.Namespace.Utils );

or whatever.

It's also common approach to jQuerys prototype to

$.fn.extend({ // something.. });

so you can utilize

$(obj).myFunction().chaining().forInstance();

It is very easy to create chaining in JavaScript, be it for an existing object or creating it from scratch (gist), that is not a valid reason for polluting a namespace you don't own, if you want a detailed explanation read this blog post.

I really believe that extending underscore/jQuery/etc is the wrong approach in most cases, if you don't agree read Zackas post again..

You don't need to follow the Java namespacing approach to avoid collisions, if you use a module loader like RequireJS you don't even need to create global variables in most cases (not even for your helper modules) and your code can be organized on a sane structure.

PS: each Object/Class/Function should have a single responsibility and this approach defeats this principle.

__.myFunction()

+1 for __.myFunction()

BTW, I created a library with many utility functions (similar to the ones present on underscore) but instead of adding every single method inside the same "namespace" we have individual modules for each method - so you can load only what you need or a full package at once - and since it's written in the AMD format it doesn't pollute the global namespace. IMHO that is a better approach and also way more scalable since we can add more methods to the lib without worrying about file size... The era of a single global namespace is definitely over to me, AMD is the future.

This is an old post, but just an fyi that backbone uses underscore and has an escape feature. I checked the backbone source and it uses the escape function from underscore:

_.escape = function(string) {
return (''+string).replace(/&/g, '&').replace(/</g, '<').replace(/>/g, '>').replace(/"/g, '"').replace(/'/g, ''').replace(///g,'/');
};

So this mixin is no longer needed.

Also what's this nonsense from @millermedeiros on not extending objects you don't own? I understand why its horrible to extend the native DOM, but libraries like underscore and jQuery were made to be extended. In your uncompressed javascript source files you actually place the additional plugins or "mixins" under to signify that they are additions. Even as a new developer on a project, it makes complete sense.

Yap, @krunkasaurus (lol, I love the name) is right, Underscore already has _.escape and the edge version has _.unescape too.

You can also use Lo-Dash, a drop-in replacement for Underscore delivering performance, bug fixes, and additional features to make a custom build and embed it directly in your project like (BonsaiJS)[http://bonsaijs.org/].

perfect! just what I was looking for. Thanks!