views:

426

answers:

3

There are a number of great Javascript libraries\frameworks out there (jQuery, Prototype, MooTools, etc.), but they all seem to focus on DOM interaction and AJAX functionality. I haven't found any that focus on extending the built-in data types (String, Date, Number, etc.). And by "Extending" I mean methods to solve typical work-a-day problems we all have.

An example would be the .NET String.Format() method. Not only more convenient, but makes reading and trouble-shooting string concatenation better. While I have already created a String prototype method for this, I'd like to see if a good library has already been developed to address similar productivity issues before launching into a library of my own.

Prototype has a few interesting methods in this regard, but since I've already settled on jQuery for DOM work, I really don't need to duplicate functionality on every page.

Is anyone aware of a good, lean data type productivity library for Javascript?

+2  A: 

For handling dates I find very useful DateJS.

CMS
Thanks! Just downloaded and about to take a test drive. It looks very useful.
Richard B
Thanks! I was thinking about using this, but I went with writing a lighter version of only the methods I used: http://www.whatcodecraves.com/articles/2009/01/11/rails_like_javascript_date_helpers/
Jerry Cheung
+1  A: 

The Microsoft AJAX Library has quite a few handy extensions to the JavaScript base types, including String.Format():

http://www.asp.net/AJAX/Documentation/Live/ClientReference/Global/

cxfx
I downloaded the beta version long ago and didn't notice these extensions. I have used the .NET AJAX (server-side) controls... I never looked this deep into the client side library. Being a .NET developer, shame on me! Thanks for the tip!
Richard B
+2  A: 

There's a good reason the big javascript libraries steer clear of extending common object prototypes with functions which should really exist (String.trim, Array.shuffle !!)... If each library extended the String object to have a trim() function, then they'd overwrite each other - not good!

Instead, what jQuery has done is to put those functions into the jQuery object. $.trim(String), $.inArray(value, Array), etc. Not as "neat" as extending the prototype, but a lot more portable.

Remember to consider this before you go adding your own functions!

nickf
I think the better argument would be to use sane naming conventions when extending core objects. For instance, don't make String.trim do what String.capitalize should do. Then who cares if some other library overwrites it? Besides you shouldn't be mixing core libraries like that anyway.
eyelidlessness
Even considering the above comment, a library should only extend the base object when such an extension doesn't already exist. That's how I'd write a library, anyway.
Jeff Hubbard
@nickf: surely your point would have to be the overriding consideration, but it sort of negates the idea of prototypes, at least where core types are concerned. It would seem that if libraries were properly modularized (each base type in their own include file), you could avoid overwritten methods.
Richard B
well yes, but they're not written like that are they? @eyelid: trim() is a pretty obvious one, but what about Date.format() ? There are a multitude of ways to implement that, each different from the other.
nickf